> On 25 Jul 2024, at 05:49, Martin Schanzenbach <schan...@gnu.org> wrote: > > > > On Thu, 2024-07-25 at 14:39 +0200, Philip Homburg wrote: >>> As hinted to in the CVE description, Thomas asked here where this >>> behaviour is defined exactly and did not receive a response that >>> fits this issue: >>> https://mailarchive.ietf.org/arch/msg/dnsop/X7ul3Updo4XP0EYdExuZ6pkp-Gk/ >>> >>> Yes, of course a stub resolver will have to sift through the CNAMEs >>> (especially if DNSSEC validation is supposed to be done). But >>> where is the filtering between QNAME and received answers >>> explicitly >>> defined, exactly? >> >> By and large, the IETF defines network protocols. The IETF is not >> good >> a defining APIs for network functions. And it is not part of its core >> mission. >> >> So what happens after a stub resolver receives a response is mostly >> undefined. Low level C APIs were done in the past by the IEEE (POSIX) >> and more >> recent by the Open Group. >> >> For example RFC 3493 is not an IETF standard, but the functions >> described, >> such as getaddrinfo, are part of the Single Unix Specification. >> >>> I am pointing out that there is a root cause >>> for this CVE/bug and it may not be simple oversight. It very well >>> may be a gap in specification or missing security considerations >>> that could hit any future implementer of (stub) resolvers. >> >> The gap is that there is no good standards organisation for APIs >> related to >> internet protocols. That is unfortunate. It is not clear to me who >> would >> have enough cloud to create one. > > Are you trying to say that the behaviour of a validating stub resolver > is not in scope of the work on DNS(SEC)? > Because I was pretty sure it is. > See Thomas' post before on how separating validation from result > filtering (following the CNAME-chain) would be tricky to do outside of > the validating stub resolver (or only with significant overhead and re- > validation) for any implementation.
DNSSEC was designed to be done in the client. Recursive servers return records that are needed to get from the original QNAME to the answer. Stub resolvers are expected to be able follow CNAME/DNAME and HTTPS/SVCB chains if those are the query type. If you request DNSSEC records you will also get back RRSIGs, NSEC and/or NSEC3 records which prove the none existence of the type or QNAME name. This is just RFC 1034, RFC 4034 and a couple of others in action. Now an application may call a library routine to perform this work on its behalf. gethostbyname and getaddrinfo are examples of these. Other applications directly parse the raw DNS message, MTAs typically fall into this class. If the libraries are DNSSEC aware then they should fail if the answers they are returning are unable to be validated as secure or insecure. For some applications the library routine can also return whether the answer was secure or insecure. The application or the library may make additional DNS requests to be able to validate the original response. These requests will typically be DNSKEY and DS queries. The difference between a stub resolver and a iterative resolver is who follows the referrals. Mark > BR > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
