F.ROOT-SERVERS.NET moved to Beijing?

Mon Oct 3 21:10:47 UTC 2011

On 2011-10-03, at 13:39, Danny McPherson wrote:

> On Oct 3, 2011, at 1:09 PM, Christopher Morrow wrote:
> 
>> Given that in the ISC case the hostname.bind query can tell you at
>> least the region + instance#, it seems plausible that some system of
>> systems could track current/changes in the mappings, no? and either
>> auto-action some 'fix' (SHUT DOWN THE IAD INSTANCE IT's ROGUE!) or at
>> least log and notify a hi-priority operations fixer.
> 
> That sort of capability at the application layer certainly seems 
> prudent to me, noting that it does assume you have a measurement 
> node within the catchment in question and are measuring at a high 
> enough frequency to detect objective incidents.

In principle there seems like no reason that a DNS client sending queries to authority-only servers couldn't decide to include the NSID option and log changes in declared server identity between subsequent queries (or take some other configured action).

We support 5001 on L-Root (which runs NSD), for what that's worth, as well as HOSTNAME.BIND/CH/TXT, VERSION.BIND/CH/TXT, ID.SERVER/CH/TXT and VERSION.SERVER/CH/TXT, but those require separate queries. I appreciate NSID support is not universal, but perhaps that's ok in the sense of "better than nothing".

> I'm a fan of both routing system && consumer-esque monitoring, and 
> do believe that a discriminator in the routing system associated with 
> globally anycasted prefixes makes this simpler - for both detection, 
> and possibly even reactive or preventative controls IF necessary.  A 
> unique origin AS is not the only place you can do this in the routing 
> system, as I'm sure some will observe, but it seems an ideal location
> to me.

Whether it's the right-most entry in the AS_PATH or a bigger substring, you still need more measurement points than you have if you want to catch every leak.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111003/a8886b8c/attachment.sig>