As a what-one-stub-resolver-does data point... The resolver I'm most familiar with validates that all the CNAME records form a single chain from the query name, and that all answer records of the query type match the final name at the end of the CNAME chain. If that is not true, as in the case of this example, the entire DNS response is rejected. If there are any answer records with a type other than CNAME or the query type, they are simply ignored.
On Thu, Jan 11, 2024 at 12:36 PM Bellebaum, Thomas < thomas.belleb...@aisec.fraunhofer.de> wrote: > Hello, > > We have been looking at some DNS resolvers and encountered a question: > > When a DNS response contains (in the answer section) records which were > not requested, how should the resolver react to those and what should > it return to the requesting client? > > For example: > > QUESTION: > example.com IN A > ANSWER: > example.com IN CNAME www.example.com > www.example.com IN A 3600 1.2.3.4 > google.com IN A 3600 5.6.7.8 > > We have noticed that even with DNSSEC enabled and all records in the > response being valid and signed, some resolvers return all records in > the answer section to the client. Note that recursive resolvers (as > well as network attackers on connections without integrity protection) > can combine records from different requests to synthesize such an > answer. > > Is the client responsible for identifying the requested RRSet or should > the resolver only return the records matching the request? > E.g. in the example above, should the client return all records in the > answer section or just the 1.2.3.4 A record? > > Some clues: > > - It is mentioned in RFC 1034 that the resolver should > communicate aliases (e.g. CNAMEs) to the client. > - Even when records not belonging to a chain of CNAME records are > removed from the answer section, simply filtering for the record type > may not be sufficient for the client (E.g. consider a QTYPE of CNAME > where during the resolution other CNAMEs are synthesized from DNAME > records.) > - DNSSEC would in some cases require checking NSEC/NSEC3 records while > following a chain of CNAME records. This can only happen in a resolver. > > Thanks in advance for any responses, > > Thomas Bellebaum > > -- > M.Sc. Thomas Bellebaum > Applied Privacy Technologies > Fraunhofer Institute for Applied and Integrated Security AISEC > > Lichtenbergstraße 11, 85748 Garching near Munich (Germany) > Tel. +49 89 32299 86 1039 <+49%2089%2032299861039> > thomas.belleb...@aisec.fraunhofer.de > https://www.aisec.fraunhofer.de > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
