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

[ 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 <dot@dotat.at> wrote:

> Petr Špaček <petr.spacek@nic.cz> 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.finch  <dot@dotat.at>  http://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