On Mon, May 28, 2018 at 2:13 PM Mukund Sivaraman <m...@mukund.org> 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. > 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. On Mon, May 28, 2018 at 3:45 PM Paul Vixie <p...@redbarn.org> wrote: > Mukund Sivaraman wrote: > > There is no ambiguity in RFC 1034/1035, and implementations that return > > NXDOMAIN for empty non-terminals are broken against RFC 1034. > > 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. > 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
