> 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. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
