On Mon, Jun 22, 2026 at 1:14 PM Olafur Gudmundsson <[email protected]> wrote:
> RFC8020 is about how a resolver should treat NXDOMAIN it does not say > when it can expect an Authority to return NXDOMAIN so this is > orthogonal usage cases. The main motivation if I recall correctly for > starting the work on RFC 8020 was to deal with ENT names correctly, > i.e. it is a valid name thus do not return NXDOMAIN for it. That was one of the motivations (triggered by the discovery that a non-trivial number of CDNs got responses to ENTs wrong, when qname minimization was being developed). But it was not the only one. The larger more general motivation was to unambiguously explain the nature of NXDOMAIN responses (in a way that no previous spec had done), and also to allow resolvers to cache non-existence of the entire subtree rooted at the name eliciting NXDOMAIN, not just at that particular name. That NXDOMAIN means that no names/records exist under it has always been implied by various aspects of the DNS specs, but not (to my knowledge) stated clearly enough prior to 8020. For example a signed NSEC or NSEC3 record that covers a non-existence name also proves that all names under it also don't exist. (Yes, this is true even for the hashed names in NSEC3, as NSEC3 only proves that the shortest non-existent ancestor of the name in the zone doesn't exist, by dint of this very property). > I will argue even further: an Authority can decide while responding to > a specific query what kind of negative answer it returns: Literal or > “Lie” For most of its existence DNS Working groups in the IETF have > avoided the rathole of treatment of answers by end user. Yes, I agree, in general. I guess the controversy here was that compact denial of existence pushed the extent of the "Lie" further by eliminating the NXDOMAIN signal entirely, which has been deemed important to many security and analytical tools. I agree that the NODATA/NXDOMAIN distinction is less useful for end user responses. Shumon.
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
