idnits 2.17.1 draft-jabley-dnsop-anycast-mapping-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 25, 2013) is 3767 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft Dyn, Inc. 4 Intended status: Informational T. Manderson 5 Expires: May 29, 2014 ICANN 6 November 25, 2013 8 A Summary of Various Mechanisms Deployed at L-Root for the 9 Identification of Anycast Nodes 10 draft-jabley-dnsop-anycast-mapping-04 12 Abstract 14 Anycast is a deployment technique commonly employed for 15 authoritative-only servers in the Domain Name System (DNS). L-Root, 16 one of the thirteen root servers, is deployed in this fashion. 18 Various techniques have been used to map deployed anycast 19 infrastructure externally, i.e. without reference to inside knowledge 20 about where and how such infrastructure has been deployed. 21 Motivations for performing such measurement exercises include 22 operational troubleshooting and infrastructure risk assessment. In 23 the specific case of L-Root, the ability to measure and map anycast 24 infrastructure using the techniques mentioned in this document is 25 provided for reasons of operational transparency. 27 This document describes all facilities deployed at L-Root to 28 facilitate mapping of its infrastructure and serves as documentation 29 for L-Root as a measurable service. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 29, 2014. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in this Document . . . . . . . . . . . . . . 4 66 3. Naming Scheme for L-Root Nodes . . . . . . . . . . . . . . . . 5 67 4. Identification of L-Root Nodes . . . . . . . . . . . . . . . . 6 68 4.1. Use of NSID . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. Use of HOSTNAME.BIND/CH/TXT . . . . . . . . . . . . . . . 7 70 4.3. Use of ID.SERVER/CH/TXT . . . . . . . . . . . . . . . . . 8 71 4.4. Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and .../IN/A . . 8 72 4.5. Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT . . . . . . . . . . 10 73 5. Provisioning of IDENTITY.L.ROOT-SERVERS.ORG . . . . . . . . . 11 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 80 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . . 17 81 A.1. Change History . . . . . . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 The Domain Name System (DNS) is described in [RFC1034] and [RFC1035]. 87 L-Root, one of the thirteen root servers, is deployed using anycast 88 [RFC4786]; its service addresses, published in the A and AAAA 89 Resource Record (RR) Sets for "L.ROOT-SERVERS.NET", are made 90 available from a substantial number of semi-autonomous servers 91 deployed throughout the Internet. A list of locations served by 92 L-Root can be found at . 94 Various techniques have been used to map deployed anycast 95 infrastructure externally, i.e. without reference to inside knowledge 96 about where and how such infrastructure has been deployed. 97 Motivations for performing such measurement exercises include 98 operational troubleshooting and infrastructure risk assessment. In 99 the specific case of L-Root, the ability to measure and map anycast 100 infrastructure using the techniques mentioned in this document is 101 provided for reasons of operational transparency. 103 This document describes all facilities currently provided at L-Root 104 to aid node identification. 106 2. Conventions Used in this Document 108 This document contains several examples of commands typed at a Unix 109 (or Unix-like) command line to illustrate use of the various 110 mechanisms available to identify L-Root nodes. Such examples are 111 presented in this document with lines typed by the user preceded by 112 the "%" prompt character; a bare "%" character indicates the end of 113 the output resulting from the command. 115 In some cases the output shown in examples is too long to be 116 represented directly in the text. In those cases a backslash 117 character ("\") is used to indicate continuation. 119 3. Naming Scheme for L-Root Nodes 121 Individual L-Root nodes have structured hostnames that are 122 constructed as follows: 124 .L.ROOT-SERVERS.ORG 126 where 128 o is chosen from the list of three-character airport 129 codes published by the International Air Transport Association 130 (IATA) in the IATA Airline Coding Directory [1]; and 132 o is a two-digit numeric code used to distinguish between two 133 different locations in the vicinity of the same airport. 135 Where multiple airports exist in the vicinity of a single L-Root 136 node, one is arbitrarily chosen. 138 More granular location data published for L-Root nodes (e.g. see 139 Section 4.4) is derived from the location of the airport, not the 140 actual location of the node. 142 4. Identification of L-Root Nodes 144 L-Root service is provided using a single IPv4 address (199.7.83.42) 145 and a single IPv6 address (2001:500:3::42). It should be noted that 146 it is preferable to refer to the service using its DNS name (L.ROOT- 147 SERVERS.NET) rather than literal addresses, since addresses can 148 change from time to time. 150 At the time of writing there are 273 separate name server elements 151 ("nodes") deployed in 143 locations which together provide L-Root 152 service. A DNS query sent to an L-Root service address will be 153 routed towards exactly one of those nodes for processing, and the 154 corresponding DNS response will be originated from the same node. 155 Queries from different clients may be routed to different nodes. 156 Successive queries from the same client may also be routed to 157 different nodes. 159 The following sections provide a summary of all mechanisms provided 160 by L-Root to allow a client to identify which L-Root node is being 161 used. 163 Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT 164 (Section 4.3) or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or .../IN/A 165 (Section 4.4) to identify a node for the purposes of reporting a 166 problem is frequently reasonable, but it should be acknowledged that 167 there is potential for re-routing between successive queries: an 168 observed problem might relate to one node, whilst a subsequent query 169 using one of those three techniques could be answered by a different 170 node. Use of the NSID option on the precise queries that yield 171 problematic responses can obviate this possibility (see Section 4.1). 173 4.1. Use of NSID 175 L-Root supports the use of the Name Server Identifier (NSID) Option 176 [RFC5001] to return the identity of an L-Root node along with the 177 response to a DNS query. The NSID payload of such responses is the 178 fully-qualified hostname of the responding L-Root node. 180 The NSID option allows the identification of a node sending a 181 specific, requested response to the client. This is of particular 182 use if (for example) there is a desire to identify unequivocally what 183 node is responding with a particularly troublesome response; the 184 output of the diagnostic tool dig with NSID requested provides the 185 problem response with the node identification, and its output in that 186 case could form the basis of a useful trouble report. 188 NSID is specified as an EDNS0 option [RFC6891]. Clients that do not 189 support EDNS0 signalling (or depend on other systems that do not 190 support EDNS0) may find this mechanism unavailable. 192 The NSID option can be specified using the widely-used diagnostic 193 tool "dig" using the "+nsid" option, as shown below. Note that long 194 lines have been truncated for the purposes of this document ("\" at 195 the end of a line indicates continuation). 197 % dig -4 @L.ROOT-SERVERS.NET . SOA +nsid \ 198 +norec +noall +comments 199 ; <<>> DiG 9.6.-ESV-R3 <<>> -4 @L.ROOT-SERVERS.NET . SOA +nsid \ 200 +norec +noall +comments 201 ; (1 server found) 202 ;; global options: +cmd 203 ;; Got answer: 204 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14913 205 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 23 207 ;; OPT PSEUDOSECTION: 208 ; EDNS: version: 0, flags:; udp: 4096 209 ; NSID: 79 74 7a 30 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 \ 210 2e 6f 72 67 (y) (t) (z) (0) (1) (.) (l) (.) (r) (o) (o) (t) (-) \ 211 (s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g) 212 % 214 % dig -6 @L.ROOT-SERVERS.NET . SOA +nsid \ 215 +norec +noall +comments 216 ; <<>> DiG 9.6.-ESV-R3 <<>> -6 @L.ROOT-SERVERS.NET . SOA +nsid \ 217 +norec +noall +comments 218 ; (1 server found) 219 ;; global options: +cmd 220 ;; Got answer: 221 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33374 222 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 23 224 ;; OPT PSEUDOSECTION: 225 ; EDNS: version: 0, flags:; udp: 4096 226 ; NSID: 79 74 7a 30 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 \ 227 2e 6f 72 67 (y) (t) (z) (0) (1) (.) (l) (.) (r) (o) (o) (t) (-) \ 228 (s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g) 229 % 231 4.2. Use of HOSTNAME.BIND/CH/TXT 233 L-Root supports the use of HOSTNAME.BIND/CH/TXT queries to return the 234 identity of an L-Root node. The TXT RDATA returned is the fully- 235 qualified hostname of the responding L-Root node. 237 The HOSTNAME.BIND/CH/TXT convention is described in [RFC4892]. 239 % dig -4 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short 240 "ytz01.l.root-servers.org" 241 % 243 % dig -6 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short 244 "ytz01.l.root-servers.org" 245 % 247 4.3. Use of ID.SERVER/CH/TXT 249 L-Root supports the use of ID.SERVER/CH/TXT queries to return the 250 identity of an L-Root node. The TXT RDATA returned is the fully- 251 qualified hostname of the responding L-Root node. 253 ID.SERVER/CH/TXT functions identically (apart from the QNAME) to 254 HOSTNAME.BIND/CH/TXT, as discussed in Section 4.2. The discussion 255 there relating to the possibility of re-routing between successive 256 queries also follows for ID.SERVER/CH/TXT. 258 The ID.SERVER/CH/TXT convention is described in [RFC4892]. 260 % dig -4 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short 261 "ytz01.l.root-servers.org" 262 % 264 % dig -6 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short 265 "ytz01.l.root-servers.org" 266 % 268 4.4. Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and .../IN/A 270 The operator of L-Root has distributed a separate DNS service in 271 parallel with L-Root, operating on precisely the same set of nodes 272 but listening on addresses which are different from the L-Root 273 service addresses. Measurements of this separate service should give 274 results which are representative of L-Root. Further discussion of 275 this service can be found in Section 5. 277 The fully-qualified DNS name IDENTITY.L.ROOT-SERVERS.ORG (note the 278 use of ORG, not NET) has associated TXT and A RR Sets which are 279 unique to the responding node. Clients are hence able to issue 280 queries for IDENTITY.L.ROOT-SERVERS.ORG/IN/A and IDENTITY.L.ROOT- 281 SERVERS.ORG/IN/TXT and use the results both to identify individual 282 nodes and to distinguish between responses generated by different 283 nodes. 285 The TXT record returned in the response to such queries is structured 286 as follows: 288 1. The fully-qualified host name of the node responding to the 289 query; 291 2. The city in which the node is located; 293 3. The region in which the node is located, if applicable; 295 4. The economy in which the node is located (in most cases, tne name 296 of a country); and 298 5. The ICANN region in which the node is located. A list of ICANN 299 regions at the time of writing can be found at 300 . 302 The A record returned in the response to such queries is guaranteed 303 to be unique to the responding node. The A RRType was chosen in an 304 effort to make the use of this mechanism as widely-available to 305 client environments as possible, and the ability to map a hostname to 306 an IPv4 address seemed more likely to be widespread than the mapping 307 of a hostname to any other value. It should be noted that the 308 availability of this mechanism to any particular client is orthogonal 309 to the local availability of IPv4 or IPv6 transport. 311 Since in this case identity data is published using IN-class resource 312 records, it is not necessary to send queries directly towards L-Root 313 in order to obtain results. Responses can be obtained through 314 recursive servers, the responses in those cases being the identity of 315 L-Root as observed through the recursive server used rather than the 316 "closest" L-Root node to the client. This facilitates some degree of 317 remote troubleshooting, since a query for IDENTITY.L.ROOT- 318 SERVERS.ORG/IN/TXT or .../IN/A directed a remote recursive resolver 319 can help illustrate which L-Root node is being used by that server 320 (or was used when the cache was populated). 322 A related caching effect is that responses to IDENTITY.L.ROOT- 323 SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT may be cached 324 at different times, and may hence persist in a cache for overlapping 325 periods of time. One possible visible effect is that the responses 326 to .../IN/A and .../IN/TXT as presented from a cache may appear to be 327 incoherent (i.e. refer to different nodes) despite queries against of 328 the cache happening (near) simultaneously. Caches may also discard 329 the published TTLs in responses from the authoritative server and 330 replace them with longer TTLs, as a matter of local policy. 331 Interpretation of responses for these queries from caches should 332 therefore be carried out with these possible effects in mind. 334 It has been observed that IDENTITY.L.ROOT-SERVERS.ORG/IN/A queries 335 offer a useful mechanism for troubleshooting DNS problems with non- 336 technical users, since such users can often be walked through the 337 process of looking up an A record (e.g. as a side effect of utilities 338 such as ping) far easier than they can be instructed on how use DNS- 339 specific tools such as dig. 341 % dig IDENTITY.L.ROOT-SERVERS.ORG TXT +short 342 "ytz01.l.root-servers.org" "Toronto" "Ontario" "Canada" "NorthAmerica" 343 % 345 % dig IDENTITY.L.ROOT-SERVERS.ORG A +short 346 67.215.199.91 347 % 349 4.5. Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT 351 The fully-qualified DNS name NODES.L.ROOT-SERVERS.ORG (note again the 352 use of ORG, not NET) provides multiple TXT RRs, one per node, and 353 represents the effective concatenation of all possible responses to 354 the query IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT. 356 Note that in the example below we have forced dig to send the query 357 over TCP, since we expect the response to be too large for UDP 358 transport to accommodate. Note also that the list shown is truncated 359 for clarity, and can be expected to change from time to time as new 360 L-Root nodes are provisioned and old ones decommissioned. 362 % dig NODES.L.ROOT-SERVERS.ORG TXT +short +tcp | head -10 363 "abj01.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "Africa" 364 "abj02.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "Africa" 365 "akl01.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific" 366 "akl41.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific" 367 "akl42.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific" 368 "akl43.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific" 369 "akl44.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific" 370 "ams01.l.root-servers.org" "Haarlemmermeer" "" "Netherlands" "Europe" 371 "anc01.l.root-servers.org" "Anchorage" "Alaska" "United States" \ 372 "NorthAmerica" 373 % 375 5. Provisioning of IDENTITY.L.ROOT-SERVERS.ORG 377 Individual L-Root nodes run a dedicated, separate authority-only DNS 378 server process which serves the IDENTITY.L.ROOT-SERVERS.ORG zone. 379 The contents of that zone are unique to every node, and hence each 380 responding node will generate a node-specific response. 382 The contents of the IDENTITY.L.ROOT-SERVERS.ORG zone are hence 383 deliberately incoherent, the apparent zone contents depending on the 384 node responding to the corresponding query. 386 The IDENTITY.L.ROOT-SERVERS.ORG zone is delegated to the single name 387 server BEACON.L.ROOT-SERVERS.ORG, numbered on IPv4 and IPv6 addresses 388 that are covered by the same routing advertisements that cover the 389 L-Root service addresses. Reachability of BEACON.L.ROOT-SERVERS.ORG 390 is hence well-aligned with the reachability of L.ROOT-SERVERS.NET, 391 and hence measurement of the IDENTITY service ought to give similar 392 results to measurement of the L-Root service. 394 It is considered best practice always to delegate a DNS zone to more 395 than one name server [RFC2182]; however, as described, the 396 IDENTITY.L.ROOT-SERVERS.ORG zone is delegated to just one server. 397 Ordinarily this would present a risk of failure if that single server 398 is not available; however, given the purpose of the delegation in 399 this case and that the expected mitigation of a failure in a single 400 node is the routing of a query to a different node, delegation to a 401 single server in this particular use-case is effective. 403 The L.ROOT-SERVERS.ORG zone is signed using DNSSEC, and hence secure 404 responses for BEACON.L.ROOT-SERVERS.ORG and NODES.L.ROOT-SERVERS.ORG 405 are available. IDENTITY.L.ROOT-SERVERS.ORG is an insecure delegation 406 from the L.ROOT-SERVERS.ORG zone, however, following the operational 407 preference to serve static data from each node for that zone, and the 408 disinclination to distribute key materials and zone signing machinery 409 to every node. 411 6. Security Considerations 413 Some operators of anycast services choose not to disclose locations 414 (or even numbers) of nodes, citing security concerns. The operator 415 of L-Root considers that none of the published information described 416 in this document is truly secret, since any service element which 417 provides service to the Internet can never truly be obscured from 418 view. Given that location information can be found regardless of any 419 conscious, deliberate disclosure, and since easy access to this 420 information has diagnostic value, the operator of L-Root has adopted 421 a policy of operational transparency. 423 The information presented in this document presents no new threat to 424 the Internet. 426 7. IANA Considerations 428 This document makes no request of the IANA. 430 8. Acknowledgements 432 The aspects of the L-Root service that were deployed to facilitate 433 IN-class mapping were discussed and implemented as part of an 434 informal collaboration with Xun Fan, John Heidemann and Ramesh 435 Govidan, whose contributions are acknowledged. The motivation to 436 faciitate mapping of L-Root as an anycast service using IN-class 437 queries was inspired by [Fan2013]. 439 Helpful reviews and comments from Gaurab Upadhaya, Hugo Salgado, 440 Brian Dixon, Bob Harold, Paul Hoffman, Jakob Schlyter, Andrew 441 Sullivan, Bruce Campbell and S. Moonesamy on earlier versions of this 442 document were very much appreciated. 444 9. References 446 9.1. Normative References 448 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 449 STD 13, RFC 1034, November 1987. 451 [RFC1035] Mockapetris, P., "Domain names - implementation and 452 specification", STD 13, RFC 1035, November 1987. 454 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection 455 and Operation of Secondary DNS Servers", BCP 16, RFC 2182, 456 July 1997. 458 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 459 Services", BCP 126, RFC 4786, December 2006. 461 [RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism 462 Identifying a Name Server Instance", RFC 4892, June 2007. 464 [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", 465 RFC 5001, August 2007. 467 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 468 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 470 9.2. Informative References 472 [Fan2013] Fan, X., Heidemann, J., and R. Govidan, "Evaluating 473 Anycast in the Domain Name System", Proceedings of the 474 IEEE Infocom Turin, Italy, April 2013. 476 URIs 478 [1] 480 Appendix A. Editorial Notes 482 This section (and sub-sections) to be removed prior to publication. 484 A.1. Change History 486 00 Initial idea, circulated for the purposes of entertainment. 488 01 Added some commentary of use-cases of NSID vs various/CH/TXT. 489 Moved discussion of IN-class queries from the NODES section to the 490 IDENTITY section. Added a note about DNSSEC for IDENTITY, NODES. 491 Updated acknowledgements section. 493 02 Clarified re-routing impact on HOSTNAME.BIND, ID.SERVER, 494 LOCATION.L queries vs. NSID as not just applying to HOSTNAME.BIND. 495 Fixed typos and absurd malapropisms. Cleaned up prompts in 496 command-line examples and added text to clarify how such examples 497 should be interpreted. 499 03 Added reference to [RFC2182] at the suggestion of Andrew Sullivan. 500 Made edits to Section 4 in response to comments from Bruce 501 Campbell. Incorporated changes following review from SM. 503 04 Added Terry as an author; changed Joe's affiliation. 505 Authors' Addresses 507 Joe Abley 508 Dyn, Inc. 509 470 Moore Street 510 London, ON N6C 2C2 511 Canada 513 Phone: +1 519 670 9327 514 Email: jabley@dyn.com 516 Terry Manderson 517 ICANN 518 12025 Waterfront Drive 519 Suite 300 520 Los Angeles, CA 90094-2536 521 USA 523 Email: terry.manderson@icann.org