Re: [DNSOP] RFC 1035 vs. mandatory NS at apex?

[Petr Špaček <[e-mail]>]

On 07. 02. 19 16:48, Bob Harold wrote:
> 
> On Thu, Feb 7, 2019 at 10:35 AM Ted Lemon <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     On Feb 7, 2019, at 10:06 AM, Petr Špaček <[e-mail]
>     <mailto:[e-mail]>> wrote:
>>     We (as developers in our office) all have had gut feeling that NS is
>>     mandatory but we could not find it in the RFCs.
> 
>     I hate to say it, but we should really make sure that this is
>     actually stated somewhere where it can reasonably be found.   If it
>     is not, we should state it.   Petr was completely sensible to think
>     it was the case but not be sure.   Saying that it is the case, and
>     why it is the case, would be helpful.   This is something that I
>     hadn’t really thought through before Petr asked the question, but
>     I’d been wondering about it too because the question comes up in the
>     DNSSD Discovery Proxy code I’m working on (I assumed the answer was
>     yes).
> 
> 
> If we write it down, perhaps we should also mention that other things
> that answer DNS queries, like load balancers, should also return proper
> SOA and NS records, not just A and AAAA records,  for the same reasons.

Let's start with this:


-------- Forwarded Message --------
Subject: [Technical Errata Reported] RFC1035 (5626)
Date: Thu,  7 Feb 2019 08:04:27 -0800 (PST)
From: RFC Errata System <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]

The following errata report has been submitted for RFC1035,
"Domain names - implementation and specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5626

--------------------------------------
Type: Technical
Reported by: Petr Špaček <[e-mail]>

Section: 5.2.

Original Text
-------------
Several other validity checks that should be performed in addition to
insuring that the file is syntactically correct:

   1. All RRs in the file should have the same class.

   2. Exactly one SOA RR should be present at the top of the zone.

   3. If delegations are present and glue information is required,
      it should be present.

   4. Information present outside of the authoritative nodes in the
      zone should be glue information, rather than the result of an
      origin or similar error.

Corrected Text
--------------
Several other validity checks that should be performed in addition to
insuring that the file is syntactically correct:

   1. All RRs in the file should have the same class.

   2. Exactly one SOA RR should be present at the top of the zone.

   3. If delegations are present and glue information is required,
      it should be present.

   4. Information present outside of the authoritative nodes in the
      zone should be glue information, rather than the result of an
      origin or similar error.

   5. At least one NS RR must be present at the top of the zone.

Notes
-----
RFC 1034 Section 4.2.1 vaguely specifies that NS RRs are expected to be
found at zone apex but it is missing in the original algorithm above.
This erratum adds explicit requirement for NS RR at zone apex.

Even more importantly this expectation was built into subsequent RFCs,
e.g. RFC 2181 which would break if NS was present only in the parent
zone but not in the child zone.

References to dnsop mailing list:
- https://mailarchive.ietf.org/arch/msg/dnsop/ipwko314FenUxrdzMl5vcick9wQ
- https://mailarchive.ietf.org/arch/msg/dnsop/JAS6TREsOh-b2J4rEAND6cds0Og

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  can log in to
change the status and edit the report, if necessary.
--------------------------------------
RFC1035 (no draft string recorded)
--------------------------------------
Title               : Domain names - implementation and specification
Publication Date    : November 1987
Author(s)           : P.V. Mockapetris
Category            : INTERNET STANDARD
Source              : Legacy
Area                : Legacy
Stream              : IETF
Verifying Party     : IESG

-- 
Petr Špaček  @  CZ.NIC