[rssac-caucus] NSID support on the root-servers

[Terry Manderson]

> On 17 Oct 2016, at 6:28 AM, Warren Kumari <warren at kumari.net> wrote:
> 
> On Sun, Oct 16, 2016 at 2:04 PM, Terry Manderson <terry at terrym.net> wrote:
>> For #2, there is an argument that hints at a concern (at a point in time) of "am I in the catchment of a instance that I believe to be geographically close and then a little more protected from any disaster type events?"
>> 
> 
> I think that that is #1, isn't it? The knowledge of what you are
> talking to is the interesting bit, not how that knowledge is
> carried...


I didn't read that from your description of #1.. but if it is - super..

> 
>> Longer term logging of these NSID piggy backed queries could be informative (post event or time based analysis) to shifts routing and connectivity events.
>> 
>> Setting aside, for now, that "geographically" does not automatically equate to "topologically", but there are some approximations _AND_ modulo the reality that the 'clients' which issue these queries in this sense are probably not resolvers as caching/recursive resolvers tend to not ad NSID option on the fly.
> 
> Parsing out the "where am I talking to?" by adding NSID option into
> some subset of a normal query stream and then having special handling
> for pulling out the response seems like more faff than it is worth --

I certainly wasn't suggesting that one should.. That sounds a bit "bad idea fairy".

The observation I made is that doing below comes from you, and not the recursive resolver. so while your laptop emitted query might end up at 
syd01.blah, your recursive resolver might be talking to lax01.blah or even not (rfc7706 ;)

i.e. young players should wear all safety equipment.

> being lazy, I'd much rather simply emit a "dig CH TXT hostname.bind
> @f.root-servers.net" or "dig SOA invalid @f.root-servers.net +nsid"
> and store the result.
> 

yep..

T