Re: [DNSOP] NXDOMAINs as in RFC 1034

[Mukund Sivaraman <[e-mail]>]

On Mon, May 28, 2018 at 11:42:36PM +0530, Mukund Sivaraman wrote:
> Something that keeps coming up recently in private discussions is that
> there's supposedly an ambiguity in RFC 1034/1035 about NXDOMAINs, that
> is practically observed in broken authoritatives on the internet when
> implementing RFC 7816 (qname minimization), and that it was only
> clarified in RFC 8020 (NXDOMAIN: there really is nothing
> underneath). I'm sorry I didn't pay attention when RFC 8020 was being
> discussed, and the RFC itself is nice to have.
> 
> There really is no ambiguity in RFC 1034/1035 about NXDOMAINs.  RFC 1034
> doesn't introduce the DNS as a collection of names; names only come
> afterwards. The domain name space is introduced as a tree structure
> composed of nodes. Each node has an associated label of 1-63 octets
> except the root that has a 0 length label. Only then, is a domain name
> defined as the concatenation of labels from a node to the
> root. Everything in the global DNS is this domain name space. There are
> nodes, not names, and names are identifiers for the nodes. A name can't
> be "present" without the corresponding node existing in the domain name
> space.  Due to the tree, it follows that for some node to exist, its
> ancestor nodes on the path to the root must exist. For a domain name to
> exist, all its superdomain names must exist. Hence if a domain name
> (node identifier) does not exist, there can be nothing under it.
> 
> There is no ambiguity in RFC 1034/1035, and implementations that return
> NXDOMAIN for empty non-terminals are broken against RFC 1034.

This is not about the caching of NXDOMAINs btw.. I am talking about the
behavior of authoritative servers that return NXDOMAINs for ENTs.

		Mukund