Subject: [DNSOP] NXDOMAINs as in RFC 1034

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 28 May 2018 23:42:36 +0530

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.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 29 May 2018 00:00:31 +0530

> 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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 May 2018 21:44:52 +0200

Mukund Sivaraman wrote:
> ...

while i agree with this (+1), we can look also to 4034/4035, in which an 
NSEC[3] proof treats an ENT as existing. so that's a second way to imply 
what 8020 is explicit about. there was never a time, at any stage of the 
evolution of the DNS specification, when NXD was correct for ENT.

-- 
P Vixie

---

From: Shumon Huque <[email-masked]>
Date: Mon, 28 May 2018 21:46:08 -0400

> NXDOMAIN for empty non-terminals are broken against RFC 1034.

Yes, I agree with all of this. As you say, the tree structure of the domain
name
space implies the very interpretation of NXDOMAIN that RFC 8020 attempted
to clarify more explicitly.

As for ambiguities in RFC 1034, the text in 8020 that mentions this issue:

  "This is due to an ambiguity in
   [RFC1034] that failed to distinguish Empty Non-Terminal (ENT) names
   ([RFC7719]) from nonexistent names (Section 3.1)."

came directly from Vixie et. al's resimprove draft (Section 3), which was
RFC 8020's
starting point. Personally, I did not find any ambiguities in RFC 1034 with
respect
to how DNS servers should respond to empty non-terminals, but clearly a
number
of implementations did not do the right thing, so the topic likely did
deserve some
clarification. Also, if I recall correctly, RFC 1034 does not explicitly
mention empty
non-terminals - they did not have a definitional term at that time although
the concept
was surely known.

> evolution of the DNS specification, when NXD was correct for ENT.

Yes, if there was any ambiguity in RFC 1034/1035 regarding NXDOMAIN,
arguably the DNSSEC specs  (and not RFC 8020) were the first to clarify the
issue definitively. I'll additionally mention that authenticated denial
proofs in
DNSSEC do not work at all without the interpretation of NXDOMAIN described
in RFC 8020. For example, the NSEC[3] record that proves that domain name
X does not exist, also proves that no descendant of X exists either (they
all fall
in the same NSEC[3] span. To add another finer detail, an NSEC3
authenticated
denial statement, proves that the "next closer name" does not exist, which
in the
general case, is some ancestor of the qname. That is enough to prove that
the
qname below it does not exist.

-- 
Shumon Huque

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 29 May 2018 11:15:03 +0530

Hi Shumon

> non-terminals - they did not have a definitional term at that time although

RFC 1034 states in 3.1 "The domain system makes no distinctions between
the uses of the interior nodes and leaves, and this memo uses the term
"node" to refer to both."

Then, it states in 3.6 "A domain name identifies a node.  Each node has
a set of resource information, which may be empty."

(Note that names are not the item considered here, nodes are.)

The above describes that any leaf and/or interior nodes may be empty.
It does not mention the word "terminal" which is a more modern DNS word,
but it's clear that it refers to leaf nodes, and ENTs are empty interior
nodes. They have to exist for them to be interior nodes.

I agree clarification is good, and so RFC 8020++.. however note the
point Vixie makes - NXDOMAINs for ENTs have never been correct in the
DNS. RFC 8020 clarifies it, but the implementations which return
NXDOMAINs are broken against RFC 1034 onwards.

		Mukund

---

From: Paul Vixie <[email-masked]>
Date: Tue, 29 May 2018 07:48:47 +0200

Mukund Sivaraman wrote:
> ...
>
> Then, [RFC 1034] states in 3.6 "A domain name identifies a node.  Each node has

bizarrely, there has never been an argument about an empty terminal 
("leaf") node, because there's no zone file syntax to represent same. 
either way, i think 1034 meant "which may, if interior, be empty."

-- 
P Vixie

---

From: Shumon Huque <[email-masked]>
Date: Tue, 29 May 2018 06:19:43 -0400

> "node" to refer to both."

Right.

> a set of resource information, which may be empty."

Ah, great. I couldn't remember whether 1034 described this explicitly.
Thanks
for quoting the relevant sentences. My point was that 1034 did not use the
term "Empty Non Terminal", although as you point out here, it clearly
describes
the concept (an interior node with no resource information, and that this
node
exists).

> NXDOMAINs are broken against RFC 1034 onwards.

Yes, agreed completely.

Shumon.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 29 May 2018 08:56:54 -0700

Shumon Huque wrote:
> ...
>
> Ah, great. I couldn't remember whether 1034 described this
> explicitly. Thanks for quoting the relevant sentences. My point was
> that 1034 did not use the term "Empty Non Terminal", although as you
> point out here, it clearly describes the concept (an interior node
> with no resource information, and that this node exists).

i coined the term "empty non-terminal" because i wanted to be understood 
by an audience who was never going to study RFC 1034 in sufficient 
detail to know what an "empty interior node" was. i now wish i had said 
"empty non-leaf", since "leaf" as used by RFC 1034 would have been 
easier to understand than "terminal".

-- 
P Vixie