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

From: Petr Špaček <[email-masked]>
Date: Thu, 7 Feb 2019 13:16:01 +0100

Hello dnsop,

here is a quiz for experienced RFC archeologists:

https://tools.ietf.org/html/rfc1035#section-5.2
section 5.2. Use of master files to define zones
does not mention NS at apex at all, but it does explicitly mention SOA
at apex. Can it be interpreted as if NS at apex is not mandatory?

Funnily enough
https://tools.ietf.org/html/rfc1035#section-5.3
has an example which as NS at apex, but it is not clear from the text above.

Is it mandatory or not? Should I submit erratum for RFC 1035?

Thank you for clarification.

-- 
Petr Špaček  @  CZ.NIC

---

From: Petr Špaček <[email-masked]>
Date: Thu, 7 Feb 2019 13:44:45 +0100

On 07. 02. 19 13:39, Ted Lemon wrote:
> Why would NS at the apex be mandatory?   What breaks if it’s not there?
> 
> (Playing the devil’s advocate—I’m also curious about this, but I think the answer is that nothing breaks.)

When looking at it from resolver perspective, what is the resolver
supposed to do with query "zone. NS" if there is no authoritative NS set
in the zone? Return NOERROR+NODATA?

Returning non-authoritative NS set in ANSWER section sounds wrong to me.

-- 
Petr Špaček  @  CZ.NIC

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Feb 2019 07:52:33 -0500

> in the zone? Return NOERROR+NODATA?

It should reply with no error and no data.   But this is okay, because you never need to ask this question in order to resolve a name.   If you are looking up an NS record with intent to use it, it’s going to be in the parent zone, where you are looking for a delegation.

The real question is whether the NS record needs to be validated.   If it does, then it needs to be signed, and so it needs to appear in the zone.   But that’s what the DS record is for, right?   :)

---

From: Petr Špaček <[email-masked]>
Date: Thu, 7 Feb 2019 14:00:46 +0100

On 07. 02. 19 13:52, Ted Lemon wrote:
> On Feb 7, 2019, at 7:44 AM, Petr Špaček <[email-masked]
> <mailto:[email-masked]>> wrote:
> It should reply with no error and no data.   But this is okay, because
> you never need to ask this question in order to resolve a name.   If you
> are looking up an NS record with intent to use it, it’s going to be in
> the parent zone, where you are looking for a delegation.

I feel something bad will happen if parent and child zone is on the same
auth server and resolver is using query name minimization...
(This configuration *does* exist in wild as we know from debugging Knot
Resolver - we do query name minimization by default.)

My gut feeling is that it should be mandatory but I would like to hear
from other implementers what assumptions they have in code.

Petr Špaček  @  CZ.NIC

> The real question is whether the NS record needs to be validated.   If
> it does, then it needs to be signed, and so it needs to appear in the
> zone.   But that’s what the DS record is for, right?   :)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Feb 2019 08:10:09 -0500

> Resolver - we do query name minimization by default.)

Interesting!   What goes wrong?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 8 Feb 2019 00:10:44 +1100

> On 7 Feb 2019, at 11:16 pm, Petr Špaček <[email-masked]> wrote:
> 
> Hello dnsop,
> 

No.  Go read RFC 1034.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 7 Feb 2019 08:53:54 -0500

The "apex" terminology didn't come into vogue until later. Prior to that,
people talked about the "top" of a zone.

RFC 1034 Section 4.2.1 lays this out:

"In the data that makes up a zone, NS RRs are found at the top node of the
zone (and are authoritative)".

Admittedly "are found" doesn't sound to modern ears (or look to modern
eyes) like a mandatory requirement. That's another thing that's changed
over the years: RFC 2026 was yet to be published, which tightened up the
requirement levels and how to signal them textually. When looking at
pre-RFC-2026 RFC's, one has to exercise some judgement of whether verbiage
describing "typical" or "normal" situations is actually normative, perhaps
even mandatory..

                             - Kevin

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Feb 2019 14:16:02 +0000

> the parent zone, where you are looking for a delegation.

But in this scenario things soon go wrong, because RFC 2181 says the
NODATA reply replaces the delegation records in the resolver's cache. This
means that if a client explicitly asks for the NS records of a zone that
lacks them, resolution for other records in the zone will subsequently
fail.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Tyne: West, backing south, 5 to 7. Slight or moderate, occasionally rough
later. Showers. Good occasionally moderate.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Feb 2019 09:40:24 -0500

> lacks them, resolution for other records in the zone will subsequently

Ah, there you have it.   So then it _is_ required.   Kevin’s point also points in that direction.

Is there somewhere in a later spec where this is stated explicitly, then?

---

From: Petr Špaček <[email-masked]>
Date: Thu, 7 Feb 2019 16:06:16 +0100

Thank you Kevin and Tony!

We (as developers in our office) all have had gut feeling that NS is
mandatory but we could not find it in the RFCs.

Thank you for your time!
Petr Špaček  @  CZ.NIC

On 07. 02. 19 14:53, Kevin Darcy wrote:
> The "apex" terminology didn't come into vogue until later. Prior to
> that, people talked about the "top" of a zone.
> 
> "In the data that makes up a zone, NS RRs are found at the top node of
> the zone (and are authoritative)".
> 
> pre-RFC-2026 RFC's, one has to exercise some judgement of whether
> verbiage describing "typical" or "normal" situations is actually
> normative, perhaps even mandatory..
> 
>                                                                        
>                                  - Kevin
> 
> On Thu, Feb 7, 2019 at 7:16 AM Petr Špaček <[email-masked]
>     has an example which as NS at apex, but it is not clear from the
>     text above..
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Feb 2019 10:35:32 -0500

> 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).

---

From: Bob Harold <[email-masked]>
Date: Thu, 7 Feb 2019 10:48:19 -0500

On Thu, Feb 7, 2019 at 10:35 AM Ted Lemon <[email-masked]> wrote:

> 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.

-- 
Bob Harold

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Feb 2019 10:55:11 -0500

On Feb 7, 2019, at 10:48 AM, Bob Harold <[email-masked]> wrote:
> 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.

Are they currently returning no error/no data?

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 7 Feb 2019 21:33:50 +0530

> Is there somewhere in a later spec where this is stated explicitly, then?

Though RFC 1034/1035 are a point for DNS that obsoleted some preceding
RFCs and other documentation and they are quite comprehensive, there are
things that they have missed. Something that comes to mind is the
definition of hostnames. Remember that DNS evolved to RFC 1034/1035. It
didn't begin there, so if something is not clear, there are documents
preceding it which may be obsolete but can contain useful information
and justification.

For this topic of NS at apex, there is some mention of it in RFC 883:

      Note that there is one special case that requires consideration
      when a name server is implemented.  A node that contains a SOA RR
      denoting a start of zone will also have NS records that identify
      the name servers that are expected to have a copy of the zone.

(The word "will" cannot be strictly assumed to have RFC 2119 meaning,
 but it's clear that it's expected.)

There's mention of it in RFC 882 where it says an NS record is necessary
because an authority for the zone is expected to answer for a query for
NS information of the zone.

If all else fails in explaining something, there's also the old saying -
"Do what BIND does". :-)

		Mukund

---

From: Petr Špaček <[email-masked]>
Date: Thu, 7 Feb 2019 17:05:37 +0100

On 07. 02. 19 16:48, Bob Harold wrote:
> 
> On Thu, Feb 7, 2019 at 10:35 AM Ted Lemon <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     On Feb 7, 2019, at 10:06 AM, Petr Špaček <[email-masked]
>     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 <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]

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 <[email-masked]>

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

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 7 Feb 2019 21:36:52 +0530

> Is it mandatory or not? Should I submit erratum for RFC 1035?

Please do so. If something that's widely accepted is not clearly stated,
documenting it would be helpful both to implementors and also to point
as reference when checking for correctness.

		Mukund

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Feb 2019 11:08:27 -0500

On Feb 7, 2019, at 11:05 AM, Marius Olafsson <[email-masked]> wrote:
> "The authoritative servers for a zone are enumerated in the NS records
>   for the origin of the zone, which, along with a Start of Authority
>   (SOA) record are the mandatory records in every zone."

Problem solved.   :)

---

From: Marius Olafsson <[email-masked]>
Date: Thu, 7 Feb 2019 16:05:11 +0000

> 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).

How about RFC2181 section 6.1

--
Marius Olafsson
University of Iceland

---

From: "Peter van Dijk" <[email-masked]>
Date: Thu, 07 Feb 2019 17:12:18 +0100

On 7 Feb 2019, at 16:55, Ted Lemon wrote:

>> 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.
>

Yes, many do. Others do not respond at all (i.e., timeout).

Case in point: https://github.com/dns-violations/dnsflagday/issues/73

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Feb 2019 16:59:46 +0000

> mandatory but we could not find it in the RFCs.

There's this bit in RFC 1034 which discusses zone cuts and says the NS
RRset above and below the cut should be exactly the same. DNS admins are
generally too relaxed about allowing them to become inconsistent.

: The RRs that describe cuts around the bottom of the zone are NS RRs that
: name the servers for the subzones.  Since the cuts are between nodes,
: these RRs are NOT part of the authoritative data of the zone, and should
: be exactly the same as the corresponding RRs in the top node of the
: subzone.  Since name servers are always associated with zone boundaries,
: NS RRs are only found at nodes which are the top node of some zone.  In
: the data that makes up a zone, NS RRs are found at the top node of the
: zone (and are authoritative) and at cuts around the bottom of the zone
: (where they are not authoritative), but never in between.

See also RFC 1912 section 2.8:

   Make sure your parent domain has the same NS records for your zone as
   you do.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dogger: West, backing southwest, 6 to gale 8. Moderate or rough, occasionally
very rough. Occasional rain. Good occasionally poor.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 8 Feb 2019 08:28:54 +0900

> Subject: [Technical Errata Reported] RFC1035 (5626)

I don't think errata is necessary.

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

At least two.

						Masataka Ohta

---

From: Warren Kumari <[email-masked]>
Date: Thu, 7 Feb 2019 18:36:48 -0500

[ Top-post ]

So, I've been staring at the Errata which Petr submitted, and trying to
work out what to do.

I'd like to mark it as either Verified, but the errata process cannot be
used for fixing issues with the protocol itself, or adding additional
restrictions which may cause compatibility issues (otherwise we wouldn't be
able to have the fun of -bis documents :-)) -- so, what I'm trying to
figure out is if this was something where the was consensus  *when RFC1035
was published* (and just missed when writing the list), or if it is a
new(er) restriction.

I agree that it should be checked, but I really want to be able to point at
something in 1034 / 1035 which says this.
Tony's below is close, but not quite there yet - it says they should be the
same, but not that it is an error in the zone file (the section is "5.2.
Use of master files to define zones") if they are not. So, can y'all help
me find evidence *from this timeframe* that shows that this was viewed as
true at that time?

Otherwise, I should be able to make it "Hold for Document Update":
"Changes that modify the working of a protocol to something that might be
different from the intended consensus when the document was approved should
be either Hold for Document Update or Rejected. Deciding between these two
depends on judgment. Changes that are clearly modifications to the intended
consensus, or involve large textual changes, should be Rejected. In unclear
situations, small changes can be Hold for Document Update. "

W

On Thu, Feb 7, 2019 at 12:00 PM Tony Finch <[email-masked]> wrote:

> very rough. Occasional rain. Good occasionally
> poor._______________________________________________
> DNSOP mailing list
> [email-masked]

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Mark Andrews <[email-masked]>
Date: Fri, 8 Feb 2019 10:42:03 +1100

> On 8 Feb 2019, at 10:28 am, Masataka Ohta <[email-masked]> wrote:
> 
> Petr Spacek wrote:
> 

Neither do I.

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

And address records for the name servers at top of zone MUST exist. 
if the names are in zone.  Similarly GLUE records must exist for
delegating NS records if they are below bottom of zone.  There
are a whole heap of checks that can be performed when you load
a zone.

That list was clearly not intended to be exhaustive.  Constructing
and getting consensus over a exhaustive list is likely to take
months.

Mark

---

From: Tony Finch <[email-masked]>
Date: Fri, 8 Feb 2019 00:54:19 +0000

> On 7 Feb 2019, at 23:36, Warren Kumari <[email-masked]> wrote:
> 
> I agree that it should be checked, but I really want to be able to point at something in 1034 / 1035 which says this. 
> Tony's below is close, but not quite there yet - it says they should be the same, but not that it is an error in the zone file (the section is "5.2. Use of master files to define zones") if they are not. So, can y'all help me find evidence *from this timeframe* that shows that this was viewed as true at that time?
> 

RFC 1033:

> NS records for a domain exist in both the zone that delegates the domain, and in the domain itself. 

This says they can’t be missing from the domain itself.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Warren Kumari <[email-masked]>
Date: Thu, 7 Feb 2019 20:09:12 -0500

> and getting consensus over a exhaustive list is likely to take

Ok, fair.
I'll do "Hold for Document Update":
"Hold for Document Update - The erratum is not a necessary update to the
RFC. However, any future update of the document might consider this
erratum, and determine whether it is correct and merits including in the
update. "

If people read the errata they will see it listed.
W

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Feb 2019 20:53:34 -0500

Ohta-san,

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

With respect, I think the protocol requirement is at least one, not at least two.

I think best current practice is to avoid single-points of failure with the set of servers used to provide authoritative answers, and I agree that in many cases this is codified in user interfaces and registry policy as requiring two NS RRs. However, there is no shortage of such multiple RRs that refer to a single subnet or even a single instance of a nameserver process (so "at least two" is sometimes insufficient), and its perfectly possible to use anycast or both A and AAAA RRs attached to a single nameserver name that provide useful much more useful diversity than those degenerate two-NS implementations (so "just one" could in some circumstances be adequate).

RFC 7108 describes the implementation of a method that includes a single point-of-failure by design (see discussion of IDENTITY.L.ROOT-SERVERS. <http://identity.l.root-servers.org/>ORG in section 5).

In short, this is an operational question with multiple answers and I don't like the idea of formalising an over-simplistic restriction in the protocol specification.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Fri, 8 Feb 2019 13:06:10 +1100

> On 8 Feb 2019, at 12:53 pm, Joe Abley <[email-masked]> wrote:
> 
> Ohta-san,
> 

A single anycast server DOES NOT and never can provide diversity from the client’s perspective.
Additionally multiple servers in the same /24 (IPv4) or same /48 (IPv6) should be treated as a
single server for diversity testing as these are accepted longest accepted prefixes.

> RFC 7108 describes the implementation of a method that includes a single point-of-failure by design (see discussion of IDENTITY.L.ROOT-SERVERS.ORG in section 5).
>

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Feb 2019 21:16:48 -0500

> single server for diversity testing as these are accepted longest accepted prefixes.

That depends on what you mean by "server" and how things are provisioned. It's not 1981 and there are many valid approaches for the removal of the outer feline layers.

I'll suggest that while recommendations and guidance about formulating a risk analysis are valuable outputs for this working group, absolute and broad statements are bet viewed with suspicion. No individual, no matter how well-informed and well-intentioned, can possibly know with certainty the complete situation of every relying party.

I think it's best for this working group to stick to what it's good at.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 8 Feb 2019 13:12:14 +0900

> single server for diversity testing as these are accepted longest accepted prefixes.

This WG should conclude that IPv6-style anycast is useless and
tell IESG obsolete it.

>> In short, this is an operational question with multiple answers and I don't like the idea of formalising an over-simplistic restriction in the protocol specification.

How do you do IPv6 anycast with L servers?

							Masataka Ohta

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Feb 2019 20:17:11 -0800

> How do you do IPv6 anycast with L servers?

That question seems a bit tangential, but in any case the simple
answer is I don't. You might ask the people who operate the ICANN root
server if you want a more useful answer; I haven't been in that team
since 2013).

Joe

---

From: Normen Kowalewski <[email-masked]>
Date: Fri, 8 Feb 2019 10:27:55 +0100

Hi Tony, Ted,

seem to not be  a DNSOP specific thing: Obviously the inherent understanding of what consensus is at the time of creation of the textual representation of that consensus may be still ambiguous at time of writing to some, however may also become ambiguous over time, in part because over time ALL originators of a text might no longer be reachable for questions, and also there may be no snippets of text that could be cited from WG mailing lists.

Feels to me like something is needed as a tool to augment this, something that can more formally represent what the consensus requirements and definitions indeed are. IMHO to grow the set of representations of DNS in form of a suite of RFC7950 YANG based models could help for many such clarification cases, completely independent from the general usefulness of gaining an interoperable representation of DNS related data. 

BR, 
Normen

> On 7. Feb 2019, at 15:40, Ted Lemon <[email-masked]> wrote:
> 
> On Feb 7, 2019, at 9:16 AM, Tony Finch <[email-masked] <mailto:[email-masked]>> wrote:

---

From: S Moonesamy <[email-masked]>
Date: Fri, 08 Feb 2019 09:06:20 -0800

Hi Peter,
>Is it mandatory or not? Should I submit erratum for RFC 1035?

RFC 1035 assumes that the reader is familiar with 
RFC 1034.  Section 5.2 of RFC 1035 discusses 
about validity checks to be performed on the 
master files used to define zones.  I would read 
Section 4.2 of RFC 1034 to understand the 
technical considerations, e.g. is a NS needed or 
not.  The examples in RFC 1035 are "primarily 
pedagogical".  I suggest taking into 
consideration that RFC 1035 is part of STD 13 for errata processing.

Regards,
S. Moonesamy