On 29/10/2013 11:45, Jim Reid wrote:
On 29 Oct 2013, at 09:24, Calvin Browne <[email protected]> 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.
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
