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 <[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.
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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
