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
signature.asc
Description: Message signed with OpenPGP using GPGMail
