> > 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
