> On 16 Jan 2026, at 22:22, Philip Homburg <[email protected]> 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.
There is no such requirements. You may be thinking of setting AD=1 where the validating resolver is asserting that every RRset in the ANSWER and AUTHORITY sections of the response it is producing has been validated as secure. Note AD=1 is only supposed to be accepted if you trust the resolver and can verify that the answer as not been tampered with. > 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. > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
