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

[S Moonesamy]

Hi Peter,
At 04:16 AM 07-02-2019, Petr Špacek wrote:

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?


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 


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Normen Kowalewski]

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  wrote:
> 
> On Feb 7, 2019, at 9:16 AM, Tony Finch mailto:d...@dotat.at>> 
> wrote:
>> 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.
> 
> 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?
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On Feb 7, 2019, at 23:12, Masataka Ohta
 wrote:

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Masataka Ohta]

Mark Andrews wrote:


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.


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


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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 7 Feb 2019, at 21:06, Mark Andrews  wrote:

> On 8 Feb 2019, at 12:53 pm, Joe Abley  wrote:
> 
>> Ohta-san,
>> 
>> On 7 Feb 2019, at 18:28, Masataka Ohta  
>> wrote:
>> 
>>> Petr Spacek wrote:
>>> 
   5. At least one NS RR must be present at the top of the zone.
>>> 
>>> At least two.
>> 
>> 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  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).
> 
> 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.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 8 Feb 2019, at 12:53 pm, Joe Abley  wrote:
> 
> Ohta-san,
> 
> On 7 Feb 2019, at 18:28, Masataka Ohta  
> wrote:
> 
>> Petr Spacek wrote:
>> 
>>>5. At least one NS RR must be present at the top of the zone.
>> 
>> At least two.
> 
> 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  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).

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).
> 
> 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
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

Ohta-san,

On 7 Feb 2019, at 18:28, Masataka Ohta  wrote:

> Petr Spacek wrote:
> 
>>5. At least one NS RR must be present at the top of the zone.
> 
> At least two.

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  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. 
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___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Thu, Feb 7, 2019 at 6:42 PM Mark Andrews  wrote:

>
>
> > On 8 Feb 2019, at 10:28 am, Masataka Ohta <
> mo...@necom830.hpcl.titech.ac.jp> wrote:
> >
> > Petr Spacek wrote:
> >
> >> Subject: [Technical Errata Reported] RFC1035 (5626)
> >
> > I don't think errata is necessary.
>
> Neither do I.
>
> >>5. At least one NS RR must be present at the top of the zone.
> >
> > At least two.
>
> 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.
>

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



>
> Mark
>
> >   Masataka Ohta
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 8 Feb 2019, at 10:28 am, Masataka Ohta  
> wrote:
> 
> Petr Spacek wrote:
> 
>> Subject: [Technical Errata Reported] RFC1035 (5626)
> 
> I don't think errata is necessary.

Neither do I.

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

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

>   Masataka Ohta
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

[ 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  wrote:

> Petr Špaček  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.
>
> 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.finchhttp://dotat.at/
> Dogger: West, backing southwest, 6 to gale 8. Moderate or rough,
> occasionally
> very rough. Occasional rain. Good occasionally
> poor.___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Masataka Ohta]

Petr Spacek wrote:


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Petr Špaček  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.

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.finchhttp://dotat.at/
Dogger: West, backing southwest, 6 to gale 8. Moderate or rough, occasionally
very rough. Occasional rain. Good occasionally poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter van Dijk]

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


On Feb 7, 2019, at 10:48 AM, Bob Harold  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  records,  for the same 
reasons.


Are they currently returning no error/no data?


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/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Marius Olafsson]

> 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

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

--
Marius Olafsson
University of Iceland

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Feb 7, 2019, at 11:05 AM, Marius Olafsson  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.   :)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mukund Sivaraman]

On Thu, Feb 07, 2019 at 01:16:01PM +0100, Petr Špaček wrote:
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

On 07. 02. 19 16:48, Bob Harold wrote:
> 
> On Thu, Feb 7, 2019 at 10:35 AM Ted Lemon  > wrote:
> 
> On Feb 7, 2019, at 10:06 AM, Petr Špaček  > 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  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 
To: i...@ietf.org
CC: petr.spa...@nic.cz, rfc-edi...@rfc-editor.org

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 

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mukund Sivaraman]

On Thu, Feb 07, 2019 at 09:40:24AM -0500, Ted Lemon wrote:
> On Feb 7, 2019, at 9:16 AM, Tony Finch  wrote:
> > 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.
> 
> 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?

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Feb 7, 2019, at 10:48 AM, Bob Harold  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  records,  for the same reasons.

Are they currently returning no error/no data?


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bob Harold]

On Thu, Feb 7, 2019 at 10:35 AM Ted Lemon  wrote:

> On Feb 7, 2019, at 10:06 AM, Petr Špaček  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  records,  for the same reasons.

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Feb 7, 2019, at 10:06 AM, Petr Špaček  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).

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

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.
> 
> 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
> 
> On Thu, Feb 7, 2019 at 7:16 AM Petr Špaček  > wrote:
> 
> 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
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Feb 7, 2019, at 9:16 AM, Tony Finch  wrote:
> 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.

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?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Ted Lemon  wrote:
> On Feb 7, 2019, at 7:44 AM, Petr Špaček  wrote:
> > 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?
>
> 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.

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.finchhttp://dotat.at/
Tyne: West, backing south, 5 to 7. Slight or moderate, occasionally rough
later. Showers. Good occasionally moderate.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Kevin Darcy]

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

On Thu, Feb 7, 2019 at 7:16 AM Petr Špaček  wrote:

> 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
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 7 Feb 2019, at 11:16 pm, Petr Špaček  wrote:
> 
> 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?

No.  Go read RFC 1034.

> 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
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

On 07. 02. 19 13:52, Ted Lemon wrote:
> On Feb 7, 2019, at 7:44 AM, Petr Špaček  > wrote:
>> 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?
> 
> 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?   :)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ted Lemon]

On Feb 7, 2019, at 7:44 AM, Petr Špaček  wrote:
> 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?

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?   :)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Petr Špaček]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop