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

[John Heidemann]

On Sun, 16 Oct 2016 16:32:56 -0400, Warren Kumari wrote: 
>On Sun, Oct 16, 2016 at 4:28 PM, 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...
>>
>>> 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 --
>> 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.
>>
>
>... actually, just after sending this I thought "This feels familiar"
>-- so I looked around and discovered, lurking on a machine:
>root at ron:~# more ~/src/code/scripts/monitoring/which_root_instances.sh
>#!/bin/bash
>
>for letter in a b c d e f g h i j l k m ;
>do
>    echo "$(date) - $letter - $(dig CH TXT hostname.bind
>@$letter.root-servers.net | grep 'TXT' | grep -v ';' | grep
>'hostname.bind' | awk '{print $5}')"
>done
>
>Which I used to invoke with:
>#*/5 * * * * /home/wkumari/src/code/scripts/monitoring/which_root_instances.sh
>>> /tank/data/scratch/which_root_instances
>
>This was a while back to try and debug some weird routing issue... It
>was really useful -- but I still maintain that the interesting /
>important bit is that the data is avaialble, the method (NSID vs CH
>TXT) is less important...

FWIW, RIPE Atlas does exactly that query, except they do it for you, every 4 minutes, and
from 9000 places.

But I was trying to figure out if the method matters (NSID vs CH TXT).
Is there any practical technical advantage NSID has over CH TXT.
(Context: to determine if we should have NSID for the anycast latency
work I described at DNS-OARC.)

Suzanne Woolf suggested that NSID wins because you can BOTH answer
another query (say, SOA) AND find out the server that replied to you.
This statement *is* in the abstract of rfc-5001, but because it doesn't
say why CH TXT cannot do provide query reply and site in one bundle,
it's easy to miss.

For mapping catchments, though, this advantage doesn't matter at all.
The only information you want is the site; you have no other query to
make.

And, at least for now, a practical argument against NSID is that it is
not supported  across all Root Letters.

(* Caveat: Let's just stipulate that NSID is attractive is because it is
the New Hotness, and clearly CH TXT is Old And Busted.  And least as
evidenced by the larger RFC number and absence of an
implementation-specific qname.)

   -John Heidemann