On 16. 01. 26 12:22, Philip Homburg wrote:
Can stubs just ignore CNAMEs and just extract addresses from A and
AAAA records found in the answer section?
Assuming that the internal stub interfaces eventually discard CNAME
data anyway, that would actually result in a simplified implementation.
The current code with CNAME matching allows the upstream server to
include unrelated addresses in the answer section that will be
ignored. Retaining this behavior, while relaxing the CNAME ordering,
requires quite a bit of extra complexity in stubs.
There is a problem with that if the stub relies on a DNSSEC validating proxy
(or if the stub has a DNSSEC validator that just implements the specs.)
As far as I know, DNSSEC requires the validator to validate every RRset in
the answer and authority sections. It also requires the validator to
verify that there is proof of NXDOMAIN or NODATA. However, there doesn't
seem any requirement that the validator removes unwanted data.
That means that an attacker can insert extra RRsets and the stub resolver
believes it is secure because it is behind a DNSSEC validator. So at
the moment, the only option for the sub resolver is to follow the CNAME
chain.
I agree extra RRs are allowed, but I think they must be authentic. So
the worst attacker can do is to add RRs which are 'DNSSEC secure' into
the answer.
(To make it absolutely clear: Content of Additional section is not
DNSSEC validated, so picking up RRs from there is risky.)
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
