> 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
Tangent #1: I think this example represents an invalid configuration for the example.com zone. This is because you cannot have a CNAME record at a given name and other records at the same name. In this case, example.com would need to be a separate zone, so SOA and NS records are required at the example.com name, and adding a CNAME record at that name would create an invalid configuration. Now, I realize this is just an example, and you could have used a different name than "example.com" for the owner name of the CNAME record. Tangent #2: IMHO, this looks suspiciously like a malicious recursive resolver, trying to sneak in a different IPv4 address than the real one for the google.com name either into your application or local resolver cache (if such a thing exists). Tangent #3: Doesn't the TTL come before the class in the master file format? :) > 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. As long as these records are required to resolve the CNAME chain, that ought to be perfectly valid, no? Would you have expected something else? On the other hand, adding in an RRset unrelated to the resolution of the original query name is not "valid", irrespective of the DNSSEC signature status of that extraneous RRset. > 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. Right, so the addition of the google.com / A RRset could in theory be done by a machine-in-the-middle. > 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? Without being able to cite chapter and verse of a relevant RFC, I would say that the client (stub resolver?) ought to toss RRsets which are unrelated to the resolution of the original queried-for name. > Some clues: > > - It is mentioned in RFC 1034 that the resolver should > communicate aliases (e.g. CNAMEs) to the client. As is done here by the recursor, ref. QUESTION: example.com IN A ANSWER: example.com IN CNAME www.example.com www.example.com IN A 1.2.3.4 > - 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.) Hm, yes, but if you query for a CNAME record, and this CNAME again points to a name which has either a DNAME-generated or static CNAME, the correct recursive resolver behaviour is to just return the first CNAME record in the chain, as that matches with the queried name and query type. I think basically the same applies if the first-level CNAME is DNAME-generated: return just this CNAME record. > - DNSSEC would in some cases require checking NSEC/NSEC3 > records while following a chain of CNAME records. This can > only happen in a resolver. In a validating recursive resolver, yes. I have not seen many validating stub resolvers, which is possibly part of the reason why we're discussing this... Best regards, - Håvard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
