[dns-operations] All NSs for a TLD being in the TLD itself

[Einar Lönn]

On Oct 29, 2013, at 12:21 PM, Calvin Browne wrote:

> On 29/10/2013 11:45, Jim Reid wrote:
>> On 29 Oct 2013, at 09:24, Calvin Browne <calvin at orange-tree.alt.za> wrote:
>> 
>>> I'm going to point out that .se went down because of a problem right at this point relativly recently.
>> IIRC, that problem had nothing to do with whether the TLD's NS RRset was in the zone or not. Something went wrong with zone file generation and that RRset got corrupted somehow. [When the authoritative NS RRset gets mangled, it doesn't matter if the targets of those NS records are inside or outside the zone.] Things still worked (sort of). The delegation info at the root was unchanged and valid. Resolvers got referrals to the authoritative .se name servers even though those servers might not have had NS records in the .se zone itself.
>> 
> From memory - a script bungled the generation of the ns.se zone.
> Having NS's outside of this zone would have meant a less catastrophic 
> failure.

Incorrect. "ns.se" is not a zone and cannot be delegated, it's locked for delegation and is *only* used for the in-bailiwick names of NS-records for .SE. This it what I earlier referred to as "in-zone dependancy", for .SE there are *no* dependancies whatsoever so "ns.se" cannot break - because it's not a zone.

> the .ng case was similar, the administrator passed away, and the zone 
> all the .ng NSes were in
> wasn't renewed, so it was suspended and .ng dissappeared. This incident 
> went unreported AFAIK,
> even though .ng was down for two or so days.

This is what worried me about having *any* "real" zones where names of TLD-level name servers reside; if the names themselves are delegated you're suddenly opening up a whole bunch of potential dangers IMHO. And, of course, especially outside your own name space for reason mentioned earlier.

> *my personal analysis* is that both these incidents would have been 
> prevented by having NS's in
> zones outside the registry's direct control.

As I said, for the *exact* problem we faced this would have helped. We're however much more paranoid about features such as ORIGIN now so I strongly doubt it will happen again. ;)

> So *I* understand when people say this naming scheme appears brittle, 
> and *I* get the same feeling.
> 
> [of course - there are other factors that come into play - reply sizes, 
> managing external relationships,
> and even IANA gluing policies which make updates to tld's more cumberson 
> when a NS set is in
> different zones]
> 
> --Calvin
> 
> PS - the .se stuff was in 2009 - so I used 'relatively recently' 
> incorrectly - apologies.

I understand why different organizations have different solutions; as you've all found out our method of naming is quite sensitive to features such as $ORIGIN. However; our solution is very nice with DNSSEC as every single record is signed and it's also very robust to "outside tampering". If there was a silver bullet for naming I think everyone would have that specfic schema, afaik there is none - and to be honest, perhaps this is good for the Internet, diversity never killed anyone, right? ;)


	/Regards, Einar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4057 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131029/14e8107a/attachment.bin>