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

[Calvin Browne]

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.

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.

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

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.