[ 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 <d...@dotat.at> wrote: > Petr Špaček <petr.spa...@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 <d...@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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
