On Sun, Oct 16, 2016 at 1:16 PM, Terry Manderson <terry@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@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@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@nic.cz https://nic.cz/ -------------------------------------------- _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus

_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus

_______________________________________________ rssac-caucus mailing list rssac-caucus@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

On Sun, Oct 16, 2016 at 2:04 PM, Terry Manderson <terry@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. W

Cheers Terry

...

On 17 Oct 2016, at 3:44 AM, Warren Kumari <warren@kumari.net> wrote:

On Sun, Oct 16, 2016 at 1:16 PM, Terry Manderson <terry@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@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@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@nic.cz https://nic.cz/ -------------------------------------------- _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus

_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus

_______________________________________________ rssac-caucus mailing list rssac-caucus@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

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

On Sun, 16 Oct 2016 16:32:56 -0400, Warren Kumari wrote:

On Sun, Oct 16, 2016 at 4:28 PM, Warren Kumari <warren@kumari.net> wrote:

...

On Sun, Oct 16, 2016 at 2:04 PM, Terry Manderson <terry@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@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

On Tue, 18 Oct 2016 06:58:01 +0200, =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= wrote:

John,

----- Original Message -----

...

From: "John Heidemann" <johnh@isi.edu> To: "Warren Kumari" <warren@kumari.net> Cc: "rssac-caucus" <rssac-caucus@icann.org> Sent: Tuesday, 18 October, 2016 01:47:35 Subject: Re: [rssac-caucus] NSID support on the root-servers

[...]

...

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.

No, the strong reason for NSID is exactly what you said in previous argument. You want to know how the particular instance of DNS server replied to you. Consecutive queries with f.e. "IN SOA" and "CH TXT" doesn't guarantee you that due to the nature of anycast routing.

I get it, for people want some other record AND what server it came from. My point was that there are some problems that don't need both.

...

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

I don't agree, that's a practical argument to _get_ it supported across all Root letters.

My statement was unclear. I meant, a practical argument against NSID for catchment mapping is incomplete support.

...

(* 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.)

"New Hotness" as in 9+ years? I understand a certain conservatism across root servers deployment, but at the same time the Root servers should be a "showcase" of DNS technology. And it's 9+ years (August 2007) since NSID become RFC.

Sorry if not clear, the text in the caveat was partly a movie reference. What I meant by that paragraph was: yes, I agree that NSID is The Right Thing and in principle should be more widely supported. I'm not opposed to RSSAC taking that question on. (Oh, and by the way, while we're talking about who should support it if you want it to superseed CH TXT, one might want to appraoch RIPE Atlas to start collecting it as a standard dataset.) The overall point of my message was that I wanted to understand what the technical advantage of NSID was. For the subproblem where one's only goal is that a RIPE Atlas probe finds its catchement, I don't see that it has any technical advantage over CH TXT. But I think we both agree on its advantage when wants a query AND the site. And I think we both agree that NSID is a good thing and should be more widely supported. -John

On 17 Oct 2016, at 6:28 AM, Warren Kumari <warren@kumari.net> wrote:

On Sun, Oct 16, 2016 at 2:04 PM, Terry Manderson <terry@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

I'm not sure. Steve or Andrew do you, or could you, maintain a to-do list for pending future updates to RSSAC documents? DW

On Oct 16, 2016, at 1:56 PM, Shane Kerr <shane@time-travellers.org> wrote:

Duane,

I agree. Is there an issue list somewhere that tracks such things?

Cheers,

-- Shane

At 2016-10-16 16:53:20 +0000 "Wessels, Duane" <dwessels@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@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@nic.cz https://nic.cz/ -------------------------------------------- _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus

_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus

I’ll start a list and remind people to discuss NSID when we next revisit RSSAC001. Thanks, Andrew

On Oct 16, 2016, at 15:51, Wessels, Duane <dwessels@verisign.com> wrote:

I'm not sure. Steve or Andrew do you, or could you, maintain a to-do list for pending future updates to RSSAC documents?

DW

...

On Oct 16, 2016, at 1:56 PM, Shane Kerr <shane@time-travellers.org> wrote:

Duane,

I agree. Is there an issue list somewhere that tracks such things?

Cheers,

-- Shane

At 2016-10-16 16:53:20 +0000 "Wessels, Duane" <dwessels@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@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@nic.cz https://nic.cz/ -------------------------------------------- _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus

_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus

_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus