Subject: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-anycast-mapping-02.txt

From: Joe Abley <[email-masked]>
Date: Mon, 24 Jun 2013 12:32:27 -0400

Hi all,

You may recall a little draft I threw together some time back to document facilities available to identify anycast nodes of the L-Root service.

There was sufficient enthusiasm expressed during earlier iterations that I proposed to the independent stream editor that this document be moved forward in that direction. Nevil graciously agreed, and this -02 is the result of a review solicited by Nevil from Paul Hoffman (thanks, Paul!)

Nevil needs additional reviewers. If you have a spare ten minutes to read through this revision and send feedback to Nevil (or to this list, and I'll forward) that'd be great.

Thanks,

Joe

Begin forwarded message:

> From: "[email-masked]" <[email-masked]>
> Subject: New Version Notification for draft-jabley-dnsop-anycast-mapping-02.txt
> Date: 24 June 2013 12:22:42 EDT
> To: Joe Abley <[email-masked]>
> 
> 
> A new version of I-D, draft-jabley-dnsop-anycast-mapping-02.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
> 
> Filename:	 draft-jabley-dnsop-anycast-mapping
> Revision:	 02
> Title:		 A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes
> Creation date:	 2013-06-24
> Group:		 Individual Submission
> Number of pages: 18
> URL:             http://www.ietf.org/internet-drafts/draft-jabley-dnsop-anycast-mapping-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-jabley-dnsop-anycast-mapping
> Htmlized:        http://tools.ietf.org/html/draft-jabley-dnsop-anycast-mapping-02
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsop-anycast-mapping-02
> 
> Abstract:
>  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.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Jun 2013 09:56:23 -0700

+1 to getting others to review this. Takes a few minutes, helps the RFC process

In looking at the diffs, I still have the question I had earlier about NSID. I give the following command three times quickly:
   dig -4 @L.ROOT-SERVERS.NET . SOA +nsid +norec +noall +comments
I get three different answers (lax16..., lax09..., lax13...).

This is similar to the variance I see when doing
   dig -4 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short
and
   dig -4 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short
However:
   dig IDENTITY.L.ROOT-SERVERS.ORG TXT +short
gives me the same answer each time I give it.

So, I'm still confused about the paragraph just before section 4.1.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Mon, 24 Jun 2013 13:15:41 -0400

> So, I'm still confused about the paragraph just before section 4.1.

That paragraph addresses the case of:

 (a) send query, get problematic response
 (b) do HOSTNAME.BIND (or similar) query to identify what node I'm talking to

It's entirely possible that the responding node for (a) will be different from the responding name for (b), in which case the node identity wouldn't correspond with the node that seemed to be giving a problematic response.

If instead you do:

  (a) send query with NSID, get problematic response

then the identity of the node exposed by the use of NSID corresponds exactly to the node that supplied the problematic response, in all cases, guaranteed.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Jun 2013 10:23:03 -0700

> then the identity of the node exposed by the use of NSID corresponds exactly to the node that supplied the problematic response, in all cases, guaranteed.

Ah, got it. I missed the linkage of "add NSID to the troublesome query". Proposal:
Current:
Use of the NSID option can obviate this possibility
Proposed:
Adding the NSID option to the query that causes the problematic response can obviate this possibility

---

From: Joe Abley <[email-masked]>
Date: Mon, 24 Jun 2013 13:24:49 -0400

> Adding the NSID option to the query that causes the problematic response can obviate this possibility

Very happy to queue that for -03, thanks for the review (again :-)

Joe

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Jun 2013 14:24:37 -0400 (EDT)

> Nevil needs additional reviewers. If you have a spare ten minutes to read through this revision and send feedback to Nevil (or to this list, and I'll forward) that'd be great.

textual:

 	"L-Root, one of the thirteen root servers, is deployed in this fashion."

This could be misread to mean only L-root is deployed with anycast

    Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT
    (Section 4.3) or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or .../IN/A
    (Section 4.4) to identify a node for the purposes of reporting a
    problem is frequently reasonable, but it should be acknowledged that
    there is potential for re-routing between successive queries: an
    observed problem might relate to one node, whilst a subsequent query
    using one of those three techniques could be answered by a different
    node.  Use of the NSID option can obviate this possibility (see
    Section 4.1).

This section is confusing, especially since the previous paragraph sets
things up to be followed by a list of methods, not a sentence of a list
of methods and their usage. It should probably be moved towards the end
of section 4. Or moved up one paragraph. It would also be useful to
state that the listed methods below each have their pros and conns, and
that _that_ is the reason all of them are done (some of this can only be
indirectly concluded, and could be stated more explicitly, like:

- This method works through recursive DNS
- This method could fail because some DNS software does not allow the CHAOS class
- This method is currently not supported on most authoritative DS servers

Or perhaps state earlier in the document why more then one
method for identifying name servers is deployed.

Note while doing some testing I accidentally did:

 	dig +nsid org @l.root-servers.org

which just gave me a timeout error. It worked using the IP. Only then
did I notice my brain had caught IDENTITY.L.ROOT-SERVERS.ORG and used
"root-servers.org" instead of "root-servers.net" for the query. 
Perhaps bring up the text "(note the use of ORG, not NET)" to an earlier
point in the draft? :)

Paul