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

[Terry Manderson]

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?"

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.

Cheers
Terry

> On 17 Oct 2016, at 3:44 AM, Warren Kumari <warren at kumari.net> wrote:
> 
> On Sun, Oct 16, 2016 at 1:16 PM, Terry Manderson <terry at terrym.net> wrote:
>> I agree,
>> 
>> I think not only considering if it is worthwhile but also evaluating if providing a definition as to what the root letter's use of NSID means has any utility.
>> 
>> Of the CH TXT entries, some are obvious, some are not (and of course does that matter).
> 
> So, I think that there are 2 aspects to this:
> 1: It is useful for "the public" to be able to query an instance and
> be able to know (roughly) where their queries are being answered from
> and
> 2: Does it matter how the information is carried?
> 
> 
> #1 seems useful for people like network administrators to be able to
> better debug (and / or report) things like performance issues. It
> doesn't seem like a bad idea to suggest that (see Duanes' below)
> 
> 
> #2 I'm not so sure about -- NSID lets you piggyback the "who are you"
> question on a "normal" query, but it seems like it would have to be a
> pathological issue / case if the CH TXT queries were being routed
> differently to the e.g SOA queries. If you had some crazy per-packet
> load balancing I *guess* you could have this occur, but, well,
> basically everything now does hash-based.
> 
> dig CH TXT hostname.bind @f.root-servers.net +nsid
> 
> ; <<>> DiG 9.10.4-P3 <<>> CH TXT hostname.bind @f.root-servers.net +nsid
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62266
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; NSID: 67 72 75 31 62 2e 66 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 2e
> 6f 72 67 ("gru1b.f.root-servers.org")
> ;; QUESTION SECTION:
> ;hostname.bind.                 CH      TXT
> 
> ;; ANSWER SECTION:
> hostname.bind.          0       CH      TXT     "gru1b.f.root-servers.org"
> 
> ;; AUTHORITY SECTION:
> hostname.bind.          0       CH      NS      hostname.bind.
> 
> ;; Query time: 137 msec
> ;; SERVER: 2001:500:2f::f#53(2001:500:2f::f)
> ;; WHEN: Sun Oct 16 13:37:04 EDT 2016
> ;; MSG SIZE  rcvd: 121
> 
> 
> W
> 
> 
> 
>> 
>> Cheers
>> Terry
>> 
>> 
>>> On 17 Oct 2016, at 2:53 AM, Wessels, Duane <dwessels at verisign.com> wrote:
>>> 
>>> This sounds like a good item for "Service Expectations of Root Servers" (RSSAC001) the next time that document gets updated.
>>> 
>>> DW
>>> 
>>> 
>>>> On Oct 16, 2016, at 11:30 AM, Ondřej Surý <ondrej.sury at nic.cz> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I just did a quick test (after seeing yet another
>>>> "we are using CH TXT") for NSID support at root
>>>> level and only 6 out of 13 of letters did support
>>>> NSID.
>>>> 
>>>> Is this something worth enough for RSSAC to look
>>>> into?  Ideally it would be great to have NSID
>>>> support at all root-server instances.
>>>> 
>>>> Cheers,
>>>> --
>>>> Ondřej Surý -- Technical Fellow
>>>> --------------------------------------------
>>>> CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
>>>> Milesovska 5, 130 00 Praha 3, Czech Republic
>>>> mailto:ondrej.sury at nic.cz    https://nic.cz/
>>>> --------------------------------------------
>>>> _______________________________________________
>>>> rssac-caucus mailing list
>>>> rssac-caucus at icann.org
>>>> https://mm.icann.org/mailman/listinfo/rssac-caucus
>>> 
>>> _______________________________________________
>>> rssac-caucus mailing list
>>> rssac-caucus at icann.org
>>> https://mm.icann.org/mailman/listinfo/rssac-caucus
>> 
>> _______________________________________________
>> rssac-caucus mailing list
>> rssac-caucus at icann.org
>> https://mm.icann.org/mailman/listinfo/rssac-caucus
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf