Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records
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.comIN 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
Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records
On 11. 01. 24 18:34, Bellebaum, Thomas 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.comIN A 3600 5.6.7.8 Tangentially related is very recent (two weeks old!) experiment which looked at handling unsolicited RRs in the AUTHORITY section. See https://chat.dns-oarc.net/community/pl/iyw9znj4wbgdfbbwwz1jjezt6o and the discussion following it. In case you don't have DNS-OARC chat login yet see https://www.dns-oarc.net/oarc/services/chat HTH. -- Petr Špaček Internet Systems Consortium ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records
On Jan 17, 2024, at 05:15, Bellebaum, Thomas wrote: > > 1. Caching of unrequested RRs would actually be fine, if they are > properly signed. At worst, a resolver would cache irrelevant records. This is not entirely true. By tailoring someone’s cache you might be able to track them. There is definitely a privacy aspect here. > 2. It is the usage of irrelevant records by the application which is > causing the problem. You could reproduce this problem without any > caches involved. They could become relevant later on when they are already in the cache ? Eg the google.con example ? The user later on browses google.com. This is not an application using “irrelevant records” Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records
> That's cache poisoning. Search for "Eugene Kashpureff" to learn all > about it. There is a relation in the sense that checking RRs for relevance to the query is mentioned as a partial defense against cache poisoning in RFC 3833, section 2.3. Note however some differences: 1. Caching of unrequested RRs would actually be fine, if they are properly signed. At worst, a resolver would cache irrelevant records. 2. It is the usage of irrelevant records by the application which is causing the problem. You could reproduce this problem without any caches involved. The confusion seems to arise in RFC 1034, section 5.3.3, which states: > a. if the response answers the question or contains a name >error, cache the data as well as returning it back to >the client. But what exactly "the data" is (or, going with RFC 3833, how "relevance" is determined), does not seem to be specified anywhere, at least not in rigorous algorithmical form. Best regards, - Thomas smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records
It appears that Bellebaum, Thomas said: >> 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. > >That is what we would have expected, and what seems to be implemented >in many popular DNS resolvers. Some of them do not even look at >unrelated records and simply follow the CNAME chain to the requested >RRs. > >We figured there must either have been universal silent agreement on >this in the WG or this must have come up at some point (possibly while >working on DNSSEC?). That's cache poisoning. Search for "Eugene Kashpureff" to learn all about it. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records
> > 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. That is what we would have expected, and what seems to be implemented in many popular DNS resolvers. Some of them do not even look at unrelated records and simply follow the CNAME chain to the requested RRs. We figured there must either have been universal silent agreement on this in the WG or this must have come up at some point (possibly while working on DNSSEC?). Yet we were unable to spot any (security or other) considerations in the RFCs discussing this. I apologize should I have overlooked something. In this case, can anyone in this list please point out the correct reference? :) > I have not seen many validating stub resolvers, which is possibly > part of the reason why we're discussing this... Right, most validating stub resolvers seem to be capable of iterative resolution as well, but the functionality has been implemented sporadically (e.g. bind9's `delv` or `unbound-host -r -D`). As someone who has tried to implement this as well, a bit of guidance would be helpful in the future, but this is best discussed in a separate thread. Note that this issue can technically come up in recursive resolution as well, as according to RFC 1034, section 4.3.2, point 5, the nameserver uses a local resolver to determine a "result" to answer a query. I would interpret this as the nameserver acting as a client to the local resolver and copying any data received from it into the answer section, thus leaving a potential stub resolver (or its client) with the task of tossing out unrelated records. Best regards, - Thomas -- 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 thomas.belleb...@aisec.fraunhofer.de https://www.aisec.fraunhofer.de smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Resolver behaviour in the presence of unrequested answer records
> 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.comIN 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
[DNSOP] Resolver behaviour in the presence of unrequested answer records
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.comIN 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 thomas.belleb...@aisec.fraunhofer.de https://www.aisec.fraunhofer.de ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
