Ed, I'm having trouble understanding your specific concerns.
There is a clear semantic difference between NXDOMAIN and NOERROR/NODATA. The first indicates that the name does not exist (and could not have been synthesized by a wildcard). The second indicates that the name exists (or was synthesized by a wildcard), but has no data associated with the specific record type that was queried, and has either data associated with other types, or in the case of empty non-terminals, has descendent names that own data. This distinction may not be particularly relevant to an enduser application directly, but it certainly is for name resolution APIs and resolvers they use. For example non-existence of a name will suppress subsequent queries for other types (e.g. in the dual stack behavior of getaddrinfo() and cousins), and resolvers implementing aggressive negative caching will further use the type bitmap in the NSEC record to determine what data types exist or not. By eliminating the NXDOMAIN signal, Compact DoE has a direct impact on such things, which is one of the things we are trying to repair in the spec. Shumon. On Wed, Aug 9, 2023 at 12:46 PM Edward Lewis <edward.le...@icann.org> wrote: > >Note however that Cloudflare quite deliberately implemented this > differential behavior (to preserve NXDOMAIN visibility for pre DNSSEC > clients I suspect). Some other implementations of Compact DoE return a > uniform (NOERROR) RCODE for either case. > > > > The trouble I have, thinking about the difference between NXDOMAIN, > NoError/NoData, and empty non-terminals is wondering about the impact of > the difference between them. > > > > The reason that existence of a name is (redefined) in “The Role of > Wildcards in the Domain Name System” (RFC 4592) is that, in classical DNS, > the only time whether a name existed or didn’t came during the process of > synthesizing a response. Whenever a query for a “name, class, type” > discovered there was no matching data, it didn’t really matter whether it > was the inability to match a name or, when a name matched, an inability to > match a data set, unless it became a question for whether an answer could > be synthesized. Within the protocol, and hence as a DNS protocol engineer, > the difference between NXDOMAIN and NoError/NoData doesn’t seem terribly > important. > > > > I ought to stop and observe that I am reluctant to say whether a name > exists or not, instead I qualify a name as having descendants or associated > data. The reason is that a non-existent name may still return a response > for data while an existing name may not return a response for data, and > this confuses the issue. A non-existent name (no descendent, no data) may > be matched by a source of synthesis (wildcard) and appear to the querier > has having an answer and therefore, in some sense “existing.” Meanwhile an > empty non-terminal may appear to not exist to a querier because it has no > data to return. This is what makes this topic really confusing. What’s > sufficient for the DNS protocol is at odds with how other protocols rely > upon the data in the DNS. > > > > When I mentioned “classical DNS” I meant to exclude the “minimal queries” > approach. (I haven’t given minimal queries much thought.). For now, I’ll > assume that this adequately handled elsewhere and skip this. > > > > What I’m driving at is this is a case where, if we solve for the needs of > the DNS protocol, problems with other applications may arise. For the most > part, if there is no data to match a query, it doesn’t matter if it is > NXDOMAIN or NoError/NoData to the DNS. The question is how does it matter > for other applications, especially if Compact Denial of Existence changes > the way things are now - in any direction - will it upset other > applications? >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
