[rssac-caucus] NSID or other identifying support by rootops?
Greetings again. In a definitely non-exhaustive survey, it appears that F, H, K, and L respond to the EDN0 NSID (RFC 5001) query. 1) Are there others that do so, at least on some of their hosts? 2) Are there rootops who do per-host identification in some other way? 3) Is this an appropriate topic for the RSSAC Caucus? --Paul Hoffman
On Mon, Sep 21, 2015 at 2:58 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
Greetings again. In a definitely non-exhaustive survey, it appears that F, H, K, and L respond to the EDN0 NSID (RFC 5001) query.
1) Are there others that do so, at least on some of their hosts?
2) Are there rootops who do per-host identification in some other way?
3) Is this an appropriate topic for the RSSAC Caucus?
I think one of the questions is "should rootops expose this information" ? I can see 2 sides: 1: it makes debugging easier ("My latency to f.root-servers.net just went from 22ms to 143ms?! Oh, I'm now hitting the node in Timbuktu... ", "The I root node in Uzbekistan is returning 123.123.123.1 for queries that contain www.facebook.com... hmmmm...." ) 2: it *may* make attackers lives easier -- could attackers try select bots that all hit a specific node to disrupt in a specific area? Personally I think that the information should be made available, but I'm not really sure, nor do I know if this is something that RSSAC should have a view on or if it should be left to each operator. I'm wondering if this has already been discussed in RSSAC? I don't remember seeing it on the Caucus list... W
--Paul Hoffman
_______________________________________________ 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
Paul Hoffman writes:
Greetings again. In a definitely non-exhaustive survey, it appears that F, H, K, and L respond to the EDN0 NSID (RFC 5001) query.
1) Are there others that do so, at least on some of their hosts?
I think at least I does.
2) Are there rootops who do per-host identification in some other way?
I seem to remember that K answers the usual CHAOS hostname.bind queries, other might do as well. And vaguely remembers others to do so.
3) Is this an appropriate topic for the RSSAC Caucus?
I'm not sure where you hint at. Is there something to discuss here? jaap
On 9/21/15, 12:27 PM, "rssac-caucus-bounces@icann.org on behalf of Jaap Akkerhuis" <rssac-caucus-bounces@icann.org on behalf of jaap@NLnetLabs.nl> wrote:
Paul Hoffman writes:
Greetings again. In a definitely non-exhaustive survey, it appears that F, H, K, and L respond to the EDN0 NSID (RFC 5001) query.
1) Are there others that do so, at least on some of their hosts?
I think at least I does.
Ah, I see that now from a different location.
2) Are there rootops who do per-host identification in some other way?
I seem to remember that K answers the usual CHAOS hostname.bind queries, other might do as well. And vaguely remembers others to do so.
It doesn't seem to be interesting if a rootop does both the standard way (NSID) and some non-standard way. It would be interesting if a rootop only does it in a non-standard way.
3) Is this an appropriate topic for the RSSAC Caucus?
I'm not sure where you hint at. Is there something to discuss here?
I'm not hinting at anything; I am really wondering if this is an appropriate topic for the Caucus. If people here find identification important for rootops to do, the Caucus can put together a recommendation. If people here don't find it important, than there's no need for discussion. --Paul Hoffman
El 9/21/2015 a las 3:03 PM, Paul Hoffman escribió:
On 9/21/15, 12:27 PM, "rssac-caucus-bounces@icann.org on behalf of Jaap Akkerhuis" <rssac-caucus-bounces@icann.org on behalf of jaap@NLnetLabs.nl> wrote:
Paul Hoffman writes:
Greetings again. In a definitely non-exhaustive survey, it appears that F, H, K, and L respond to the EDN0 NSID (RFC 5001) query.
1) Are there others that do so, at least on some of their hosts? I think at least I does. Ah, I see that now from a different location.
2) Are there rootops who do per-host identification in some other way? I seem to remember that K answers the usual CHAOS hostname.bind queries, other might do as well. And vaguely remembers others to do so. It doesn't seem to be interesting if a rootop does both the standard way (NSID) and some non-standard way. It would be interesting if a rootop only does it in a non-standard way.
3) Is this an appropriate topic for the RSSAC Caucus? I'm not sure where you hint at. Is there something to discuss here? I'm not hinting at anything; I am really wondering if this is an appropriate topic for the Caucus.
IMHO I think it does.
If people here find identification important for rootops to do, the Caucus can put together a recommendation. If people here don't find it important, than there's no need for discussion.
--Paul Hoffman
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
On Mon, 21 Sep 2015 19:33:53 -0000, Paul Hoffman wrote:
On 9/21/15, 12:27 PM, "rssac-caucus-bounces@icann.org on behalf of Jaap Akkerhuis" <rssac-caucus-bounces@icann.org on behalf of jaap@NLnetLabs.nl> wrote:
Paul Hoffman writes:
Greetings again. In a definitely non-exhaustive survey, it appears that F, H, K, and L respond to the EDN0 NSID (RFC 5001) query.
1) Are there others that do so, at least on some of their hosts?
I think at least I does.
Ah, I see that now from a different location.
2) Are there rootops who do per-host identification in some other way?
I seem to remember that K answers the usual CHAOS hostname.bind queries, other might do as well. And vaguely remembers others to do so.
It doesn't seem to be interesting if a rootop does both the standard way (NSID) and some non-standard way. It would be interesting if a rootop only does it in a non-standard way.
The following paper looked at using CHAOS queries and other techniques (traceroute, etc.) to locate anycast instances: Xun Fan, John Heidemann, and Ramesh Govindan. Evaluating Anycast in the Domain Name System. In _Proceedings of the IEEE Infocom_. Turin, Italy, IEEE. April, 2013. <http://www.isi.edu/~johnh/PAPERS/Fan13a.html>. I went back to look about rfc5001---the paper says "RFC-5001 is not yet widely supported". The work in the paper ran 2011 to 2012, FWIW.
3) Is this an appropriate topic for the RSSAC Caucus?
I'm not sure where you hint at. Is there something to discuss here?
I'm not hinting at anything; I am really wondering if this is an appropriate topic for the Caucus. If people here find identification important for rootops to do, the Caucus can put together a recommendation. If people here don't find it important, than there's no need for discussion.
The topic is about DNS and so is relevant, but... about "put together a recommendation": A recommendation about what, exactly? Framing some problem (even if that framing evolves) seems important before embarking on some course of activity. -John Heidemann
Hi all, On 21/09/15 21:33, Paul Hoffman wrote:
On 9/21/15, 12:27 PM, "rssac-caucus-bounces@icann.org on behalf of Jaap Akkerhuis" <rssac-caucus-bounces@icann.org on behalf of jaap@NLnetLabs.nl> wrote:
Greetings again. In a definitely non-exhaustive survey, it appears that F, H, K, and L respond to the EDN0 NSID (RFC 5001) query.
1) Are there others that do so, at least on some of their hosts? I think at least I does. Ah, I see that now from a different location.
Quick plug for more locations to see things from :) https://atlas.ripe.net/results/maps/root-instances/ Very interesting to browse around. Those maps are a great example of the 'utility' of the per-node information. (PS those maps are for hostname.bind/id.server, not NSID, because hostname.bind seems more supported than NSID)
2) Are there rootops who do per-host identification in some other way? I seem to remember that K answers the usual CHAOS hostname.bind queries,
K answers NSID, hostname.bind and id.server Cheers, Colin -- Colin Petrie Systems Engineer RIPE NCC
On 22/09/2015 19:36, Colin Petrie wrote:
Quick plug for more locations to see things from :) https://atlas.ripe.net/results/maps/root-instances/
Very interesting to browse around. Those maps are a great example of the 'utility' of the per-node information.
Absolutely!
(PS those maps are for hostname.bind/id.server, not NSID, because hostname.bind seems more supported than NSID)
Yes - I'm using the underlying hostname.bind info collected by RIPE Atlas to look at F-root placement and peering arrangements (current and future), as presented at IEPG, and at the forthcoming DNS-OARC and NANOG meetings. Ray
On Sep 22, 2015, at 2:36 PM, Colin Petrie <cpetrie@ripe.net<mailto:cpetrie@ripe.net>> wrote: (PS those maps are for hostname.bind/id.server, not NSID, because hostname.bind seems more supported than NSID) The problem with RFC 5001 (NSID) is that it explicitly did not define the payload of the option. If every root op did their own thing, it is going to make it pretty hard to do a cross the board solution. D currently uses id.server as well. I could see us also using NSID, but probably using private (and potentially encrypted) data. I see NSID as more of a trouble shooting tool within a given RSO and not necessarily for the general public.
On 22/09/15 23:22, Bruce E. Crabill wrote:
The problem with RFC 5001 (NSID) is that it explicitly did not define the payload of the option. If every root op did their own thing, it is going to make it pretty hard to do a cross the board solution. D currently uses id.server as well.
As far as I can see, hostname.bind is already across the board on the root name servers.
I could see us also using NSID, but probably using private (and potentially encrypted) data. I see NSID as more of a trouble shooting tool within a given RSO and not necessarily for the general public.
Indeed, this is generally true for any DNS operator. Currently it looks like some operators put the node name into the NSID but that's probably just habit and for consistency with the hostname.bind :) I'm sure there are much more imaginative uses for NSID (many of which are detailed in RFC5001). I'd love to know if anyone sees or uses NSIDs in the wild that are actually binary data rather than obviously textual. (And no I haven't gone digging through the Atlas data yet for that ;-) - just wondering if anyone already has seen such things) Cheers Colin -- Colin Petrie Systems Engineer RIPE NCC
On Wed, 23 Sep 2015, Colin Petrie wrote:
I'm sure there are much more imaginative uses for NSID (many of which are detailed in RFC5001). I'd love to know if anyone sees or uses NSIDs in the wild that are actually binary data rather than obviously textual.
Queued up for my next AS112 surveys. :-) wfms
On Mon, 21 Sep 2015, Paul Hoffman wrote:
Greetings again. In a definitely non-exhaustive survey, it appears that F, H, K, and L respond to the EDN0 NSID (RFC 5001) query.
1) Are there others that do so, at least on some of their hosts?
I can definitively say that according to my little NSID-seeking bot, yes, but.
2) Are there rootops who do per-host identification in some other way?
It depends.
3) Is this an appropriate topic for the RSSAC Caucus?
Possibly.
On 21 Sep 2015, at 14:58, Paul Hoffman wrote:
Greetings again. In a definitely non-exhaustive survey, it appears that F, H, K, and L respond to the EDN0 NSID (RFC 5001) query.
We wrote down what L does: A new Request for Comments is now available in online RFC libraries. RFC 7108 Title: A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes Author: J. Abley, T. Manderson Status: Informational Stream: Independent Date: January 2014 Mailbox: jabley at dyn.com, terry.manderson at icann.org Pages: 11 Characters: 24125 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-jabley-dnsop-anycast-mapping-04.txt URL: http://www.rfc-editor.org/rfc/rfc7108.txt Anycast is a deployment technique commonly employed for authoritative-only servers in the Domain Name System (DNS). L-Root, one of the thirteen root servers, is deployed in this fashion. Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed. Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency. This document describes all facilities deployed at L-Root to facilitate mapping of its infrastructure and serves as documentation for L-Root as a measurable service.
participants (10)
-
Alejandro Acosta -
Bruce E. Crabill -
Colin Petrie -
Jaap Akkerhuis -
Joe Abley -
John Heidemann -
Paul Hoffman -
Ray Bellis -
Warren Kumari -
William Sotomayor