1 Independent Submission J. Abley
2 Request for Comments: 7108 Dyn, Inc.
3 Category: Informational T. Manderson
4 ISSN: 2070-1721 ICANN
5 January 2014
6
7
8 A Summary of Various Mechanisms Deployed at L-Root for the
9 Identification of Anycast Nodes
10
11 Abstract
12
13 Anycast is a deployment technique commonly employed for
14 authoritative-only servers in the Domain Name System (DNS). L-Root,
15 one of the thirteen root servers, is deployed in this fashion.
16
17 Various techniques have been used to map deployed anycast
18 infrastructure externally, i.e., without reference to inside
19 knowledge about where and how such infrastructure has been deployed.
20 Motivations for performing such measurement exercises include
21 operational troubleshooting and infrastructure risk assessment. In
22 the specific case of L-Root, the ability to measure and map anycast
23 infrastructure using the techniques mentioned in this document is
24 provided for reasons of operational transparency.
25
26 This document describes all facilities deployed at L-Root to
27 facilitate mapping of its infrastructure and serves as documentation
28 for L-Root as a measurable service.
29
30 Status of This Memo
31
32 This document is not an Internet Standards Track specification; it is
33 published for informational purposes.
34
35 This is a contribution to the RFC Series, independently of any other
36 RFC stream. The RFC Editor has chosen to publish this document at
37 its discretion and makes no statement about its value for
38 implementation or deployment. Documents approved for publication by
39 the RFC Editor are not a candidate for any level of Internet
40 Standard; see Section 2 of RFC 5741.
41
42 Information about the current status of this document, any errata,
43 and how to provide feedback on it may be obtained at
44 http://www.rfc-editor.org/info/rfc7108.
45
46
47
48
49
50
51
52 Abley & Manderson Informational [Page 1]
53 RFC 7108 L-Root Anycast Node Identification January 2014
54
55
56 Copyright Notice
57
58 Copyright (c) 2014 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document.
67
68 Table of Contents
69
70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
71 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
72 3. Naming Scheme for L-Root Nodes . . . . . . . . . . . . . . . 3
73 4. Identification of L-Root Nodes . . . . . . . . . . . . . . . 3
74 4.1. Use of NSID . . . . . . . . . . . . . . . . . . . . . . . 4
75 4.2. Use of HOSTNAME.BIND/CH/TXT . . . . . . . . . . . . . . . 5
76 4.3. Use of ID.SERVER/CH/TXT . . . . . . . . . . . . . . . . . 6
77 4.4. Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and .../IN/A . 6
78 4.5. Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT . . . . . . . . . 8
79 5. Provisioning of IDENTITY.L.ROOT-SERVERS.ORG . . . . . . . . . 9
80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
83 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
84 8.2. Informative References . . . . . . . . . . . . . . . . . 11
85
86 1. Introduction
87
88 The Domain Name System (DNS) is described in [RFC1034] and [RFC1035].
89 L-Root, one of the thirteen root servers, is deployed using anycast
90 [RFC4786]; its service addresses, published in the A and AAAA
91 Resource Record (RR) Sets for "L.ROOT-SERVERS.NET", are made
92 available from a substantial number of semi-autonomous servers
93 deployed throughout the Internet. A list of locations served by
94 L-Root can be found at [ROOT-SERVERS].
95
96 Various techniques have been used to map deployed anycast
97 infrastructure externally, i.e., without reference to inside
98 knowledge about where and how such infrastructure has been deployed.
99 Motivations for performing such measurement exercises include
100 operational troubleshooting and infrastructure risk assessment. In
101 the specific case of L-Root, the ability to measure and map anycast
102 infrastructure using the techniques mentioned in this document is
103 provided for reasons of operational transparency.
104
105
106
107 Abley & Manderson Informational [Page 2]
108 RFC 7108 L-Root Anycast Node Identification January 2014
109
110
111 This document describes all facilities currently provided at L-Root
112 to aid node identification.
113
114 2. Conventions Used in This Document
115
116 This document contains several examples of commands typed at a Unix
117 (or Unix-like) command line to illustrate use of the various
118 mechanisms available to identify L-Root nodes. Such examples are
119 presented in this document with lines typed by the user preceded by
120 the "%" prompt character; a bare "%" character indicates the end of
121 the output resulting from the command.
122
123 In some cases, the output shown in examples is too long to be
124 represented directly in the text. In those cases, a backslash
125 character ("\") is used to indicate continuation.
126
127 3. Naming Scheme for L-Root Nodes
128
129 Individual L-Root nodes have structured hostnames that are
130 constructed as follows:
131
132 <IATA Code><NN>.L.ROOT-SERVERS.ORG
133
134 where
135
136 o <IATA Code> is chosen from the list of three-character airport
137 codes published by the International Air Transport Association
138 (IATA) in the IATA Airline Coding Directory [ACD]; and
139
140 o <NN> is a two-digit numeric code used to distinguish between two
141 different nodes in the vicinity of the same airport.
142
143 Where multiple airports exist in the vicinity of a single L-Root
144 node, one is arbitrarily chosen.
145
146 More granular location data published for L-Root nodes (e.g., see
147 Section 4.4) is derived from the location of the airport, not the
148 actual location of the node.
149
150 4. Identification of L-Root Nodes
151
152 L-Root service is provided using a single IPv4 address (199.7.83.42)
153 and a single IPv6 address (2001:500:3::42). Note that it is
154 preferable to refer to the service using its DNS name (L.ROOT-
155 SERVERS.NET) rather than literal addresses, since addresses can
156 change from time to time.
157
158
159
160
161
162 Abley & Manderson Informational [Page 3]
163 RFC 7108 L-Root Anycast Node Identification January 2014
164
165
166 At the time of writing, there are 273 separate name server elements
167 ("nodes") deployed in 143 locations: together, these nodes provide
168 L-Root service. A DNS query sent to an L-Root service address will
169 be routed towards exactly one of those nodes for processing, and the
170 corresponding DNS response will be originated from the same node.
171 Queries from different clients may be routed to different nodes.
172 Successive queries from the same client may also be routed to
173 different nodes.
174
175 The following sections provide a summary of all mechanisms provided
176 by L-Root to allow a client to identify which L-Root node is being
177 used.
178
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
179 Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT
180 (Section 4.3), or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L
181 .ROOT-SERVERS/IN/A (Section 4.4) to identify a node for the purposes
182 of reporting a problem is frequently reasonable, but it should be
183 acknowledged that there is potential for re-routing between
184 successive queries: an observed problem might relate to one node,
185 whilst a subsequent query using one of those three techniques could
186 be answered by a different node. Use of the Name Server Identifier
187 (NSID) option on the precise queries that yield problematic responses
188 can obviate this possibility (see Section 4.1).
189
190 4.1. Use of NSID
191
192 L-Root supports the use of the Name Server Identifier (NSID) option
193 [RFC5001] to return the identity of an L-Root node along with the
194 response to a DNS query. The NSID payload of such responses is the
195 fully qualified hostname of the responding L-Root node.
196
197 The NSID option allows the identification of a node sending a
198 specific, requested response to the client. This is of particular
199 use if (for example) there is a desire to identify unequivocally what
200 node is responding with a particularly troublesome response; the
201 output of the diagnostic tool "dig" with NSID requested provides the
202 problem response with the node identification, and its output in that
203 case could form the basis of a useful trouble report.
204
205 NSID is specified as an EDNS(0) option [RFC6891]. Clients that do
206 not support EDNS(0) signaling (or depend on other systems that do not
207 support EDNS0) may find this mechanism unavailable.
208
209 The NSID option can be specified using the widely used diagnostic
210 tool "dig" using the "+nsid" option, as shown below. Note that long
211 lines have been truncated for the purposes of this document ("\" at
212 the end of a line indicates continuation).
213
214
215
216
217 Abley & Manderson Informational [Page 4]
218 RFC 7108 L-Root Anycast Node Identification January 2014
219
220
221 % dig -4 @L.ROOT-SERVERS.NET . SOA +nsid \
222 +norec +noall +comments
223 ; <<>> DiG 9.6.-ESV-R3 <<>> -4 @L.ROOT-SERVERS.NET . SOA +nsid \
224 +norec +noall +comments
225 ; (1 server found)
226 ;; global options: +cmd
227 ;; Got answer:
228 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14913
229 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 23
230
231 ;; OPT PSEUDOSECTION:
232 ; EDNS: version: 0, flags:; udp: 4096
233 ; NSID: 79 74 7a 30 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 \
234 2e 6f 72 67 (y) (t) (z) (0) (1) (.) (l) (.) (r) (o) (o) (t) (-) \
235 (s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g)
236 %
237
238 % dig -6 @L.ROOT-SERVERS.NET . SOA +nsid \
239 +norec +noall +comments
240 ; <<>> DiG 9.6.-ESV-R3 <<>> -6 @L.ROOT-SERVERS.NET . SOA +nsid \
241 +norec +noall +comments
242 ; (1 server found)
243 ;; global options: +cmd
244 ;; Got answer:
245 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33374
246 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 23
247
248 ;; OPT PSEUDOSECTION:
249 ; EDNS: version: 0, flags:; udp: 4096
250 ; NSID: 79 74 7a 30 31 2e 6c 2e 72 6f 6f 74 2d 73 65 72 76 65 72 73 \
251 2e 6f 72 67 (y) (t) (z) (0) (1) (.) (l) (.) (r) (o) (o) (t) (-) \
252 (s) (e) (r) (v) (e) (r) (s) (.) (o) (r) (g)
253 %
254
255 4.2. Use of HOSTNAME.BIND/CH/TXT
256
257 L-Root supports the use of HOSTNAME.BIND/CH/TXT queries to return the
258 identity of an L-Root node. The TXT RDATA returned is the fully
259 qualified hostname of the responding L-Root node.
260
261 The HOSTNAME.BIND/CH/TXT convention is described in [RFC4892].
262
263
264
265
266
267
268
269
270
271
272 Abley & Manderson Informational [Page 5]
273 RFC 7108 L-Root Anycast Node Identification January 2014
274
275
276 % dig -4 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short
277 "ytz01.l.root-servers.org"
278 %
279
280 % dig -6 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short
281 "ytz01.l.root-servers.org"
282 %
283
284 4.3. Use of ID.SERVER/CH/TXT
285
286 L-Root supports the use of ID.SERVER/CH/TXT queries to return the
287 identity of an L-Root node. The TXT RDATA returned is the fully
288 qualified hostname of the responding L-Root node.
289
290 ID.SERVER/CH/TXT functions identically (apart from the QNAME) to
291 HOSTNAME.BIND/CH/TXT, as discussed in Section 4.2. The discussion
292 there relating to the possibility of re-routing between successive
293 queries also follows for ID.SERVER/CH/TXT.
294
295 The ID.SERVER/CH/TXT convention is described in [RFC4892].
296
297 % dig -4 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short
298 "ytz01.l.root-servers.org"
299 %
300
301 % dig -6 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short
302 "ytz01.l.root-servers.org"
303 %
304
305 4.4. Use of IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT and .../IN/A
306
307 The operator of L-Root has distributed a separate DNS service in
308 parallel with L-Root, operating on precisely the same set of nodes
309 but listening on addresses that are different from the L-Root service
310 addresses. Measurements of this separate service should give results
311 that are representative of L-Root. Further discussion of this
312 service can be found in Section 5.
313
314 The fully qualified DNS name IDENTITY.L.ROOT-SERVERS.ORG (note the
315 use of ORG, not NET) has associated TXT and A RR Sets that are unique
316 to the responding node. Clients are hence able to issue queries for
317 IDENTITY.L.ROOT-SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/IN/
318 TXT and use the results both to identify individual nodes and to
319 distinguish between responses generated by different nodes.
320
321
322
323
324
325
326
327 Abley & Manderson Informational [Page 6]
328 RFC 7108 L-Root Anycast Node Identification January 2014
329
330
331 The TXT record returned in the response to such queries is structured
332 as follows:
333
334 1. The fully qualified hostname of the node responding to the query;
335
336 2. The city in which the node is located;
337
338 3. The region in which the node is located, if applicable;
339
340 4. The economy in which the node is located (in most cases, the name
341 of a country); and
342
343 5. The Internet Corporation for Assigned Names and Numbers (ICANN)
344 region in which the node is located. A list of ICANN regions at
345 the time of writing can be found at <http://meetings.icann.org/
346 regions>.
347
348 The A record returned in the response to such queries is guaranteed
349 to be unique to the responding node. The A RRType was chosen in an
350 effort to make the use of this mechanism as widely available to
351 client environments as possible, and the ability to map a hostname to
352 an IPv4 address seemed more likely to be widespread than the mapping
353 of a hostname to any other value. It should be noted that the
354 availability of this mechanism to any particular client is orthogonal
355 to the local availability of IPv4 or IPv6 transport.
356
357 In this case, because identity data is published using IN-class
358 resource records, it is not necessary to send queries directly
359 towards L-Root in order to obtain results. Responses can be obtained
360 through recursive servers, the responses in those cases being the
361 identity of L-Root as observed through the recursive server used
362 rather than the "closest" L-Root node to the client. This
363 facilitates some degree of remote troubleshooting, since a query for
364 IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L.ROOT-SERVERS.ORG/IN/
365 A directed a remote recursive resolver can help illustrate which
366 L-Root node is being used by that server (or was used when the cache
367 was populated).
368
369 A related caching effect is that responses to IDENTITY.L.ROOT-
370 SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT may be cached
371 at different times, and may hence persist in a cache for overlapping
372 periods of time. One possible visible effect is that the responses
373 to IDENTITY.L.ROOT-SERVERS.ORG/IN/A and IDENTITY.L.ROOT-SERVERS.ORG/
374 IN/TXT as presented from a cache may appear to be incoherent (i.e.,
375 refer to different nodes) despite queries against of the cache
376 happening (near) simultaneously. Caches may also discard the
377 published Times to Live (TTLs) in responses from the authoritative
378
379
380
381
382 Abley & Manderson Informational [Page 7]
383 RFC 7108 L-Root Anycast Node Identification January 2014
384
385
386 server and replace them with longer TTLs, as a matter of local
387 policy. Interpretation of responses for these queries from caches
388 should therefore be carried out with these possible effects in mind.
389
390 It has been observed that IDENTITY.L.ROOT-SERVERS.ORG/IN/A queries
391 offer a useful mechanism for troubleshooting DNS problems with non-
392 technical users, since such users can often be walked through the
393 process of looking up an A record (e.g., as a side effect of
394 utilities such as ping) far easier than they can be instructed on how
395 to use DNS-specific tools such as dig.
396
397 % dig IDENTITY.L.ROOT-SERVERS.ORG TXT +short
398 "ytz01.l.root-servers.org" "Toronto" "Ontario" "Canada" "NorthAmerica"
399 %
400
401 % dig IDENTITY.L.ROOT-SERVERS.ORG A +short
402 67.215.199.91
403 %
404
405 4.5. Use of NODES.L.ROOT-SERVERS.ORG/IN/TXT
406
407 The fully qualified DNS name NODES.L.ROOT-SERVERS.ORG (note again the
408 use of ORG, not NET) provides multiple TXT RRs, one per node, and
409 represents the effective concatenation of all possible responses to
410 the query IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT.
411
412 Note that in the example below we have forced dig to send the query
413 over TCP, since we expect the response to be too large for UDP
414 transport to accommodate. Note also that the list shown is truncated
415 for clarity, and can be expected to change from time to time as new
416 L-Root nodes are provisioned and old ones decommissioned.
417
418 % dig NODES.L.ROOT-SERVERS.ORG TXT +short +tcp | head -10
419 "abj01.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "Africa"
420 "abj02.l.root-servers.org" "Abidjan" "" "Cote d'Ivoire" "Africa"
421 "akl01.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"
422 "akl41.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"
423 "akl42.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"
424 "akl43.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"
425 "akl44.l.root-servers.org" "Mangere" "" "New Zealand" "AsiaPacific"
426 "ams01.l.root-servers.org" "Haarlemmermeer" "" "Netherlands" "Europe"
427 "anc01.l.root-servers.org" "Anchorage" "Alaska" "United States" \
428 "NorthAmerica"
429 %
430
431
432
433
434
435
436
437 Abley & Manderson Informational [Page 8]
438 RFC 7108 L-Root Anycast Node Identification January 2014
439
440
441 5. Provisioning of IDENTITY.L.ROOT-SERVERS.ORG
442
443 Individual L-Root nodes run a dedicated, separate authority-only DNS
444 server process that serves the IDENTITY.L.ROOT-SERVERS.ORG zone. The
445 contents of that zone are unique to every node; hence, each
446 responding node will generate a node-specific response.
447
448 The contents of the IDENTITY.L.ROOT-SERVERS.ORG zone are hence
449 deliberately incoherent, the apparent zone contents depending on the
450 node responding to the corresponding query.
451
452 The IDENTITY.L.ROOT-SERVERS.ORG zone is delegated to the single name
453 server BEACON.L.ROOT-SERVERS.ORG, numbered on IPv4 and IPv6 addresses
454 that are covered by the same routing advertisements that cover the
455 L-Root service addresses. Reachability of BEACON.L.ROOT-SERVERS.ORG
456 is hence well-aligned with the reachability of L.ROOT-SERVERS.NET;
457 therefore, measurement of the IDENTITY service ought to give similar
458 results to measurement of the L-Root service.
459
460 It is considered best practice always to delegate a DNS zone to more
461 than one name server [RFC2182]; however, as described, the IDENTITY.L
462 .ROOT-SERVERS.ORG zone is delegated to just one server. Ordinarily,
463 this would present a risk of failure if that single server is not
464 available; however, given the purpose of the delegation in this case
465 and that the expected mitigation of a failure in a single node is the
466 routing of a query to a different node, delegation to a single server
467 in this particular use-case is effective.
468
469 At the time of writing, the ROOT-SERVERS.ORG zone is not signed with
470 DNSSEC. When DNSSEC is deployed in that zone, the L.ROOT-SERVERS.ORG
471 zone will also be signed. This will facilitate secure responses for
472 queries for BEACON.L.ROOT-SERVERS.ORG and NODES.L.ROOT-SERVERS.ORG.
473
474 Secure responses for IDENTITY.L.ROOT-SERVERS.ORG are unlikely to
475 become available even with the deployment of DNSSEC in the parent,
476 since the implementation of the IDENTITY.L.ROOT-SERVERS.ORG service
477 involves widely distributed static zone data. Management of key
478 materials distributed to every L-Root node would be impractical to
479 audit, and signatures returned in secure responses would be
480 correspondingly of low value.
481
482 6. Security Considerations
483
484 Some operators of anycast services choose not to disclose locations
485 (or even numbers) of nodes, citing security concerns. The operator
486 of L-Root considers that none of the published information described
487 in this document is truly secret, since any service element that
488 provides service to the Internet can never truly be obscured from
489
490
491
492 Abley & Manderson Informational [Page 9]
493 RFC 7108 L-Root Anycast Node Identification January 2014
494
495
496 view. Given that location information can be found regardless of any
497 conscious, deliberate disclosure, and since easy access to this
498 information has diagnostic value, the operator of L-Root has adopted
499 a policy of operational transparency.
500
501 The information presented in this document presents no new threat to
502 the Internet.
503
504 7. Acknowledgements
505
506 The aspects of the L-Root service that were deployed to facilitate
507 IN-class mapping were discussed and implemented as part of an
508 informal collaboration with Xun Fan, John Heidemann, and Ramesh
509 Govidan, whose contributions are acknowledged. The motivation to
510 facilitate mapping of L-Root as an anycast service using IN-class
511 queries was inspired by [Fan2013].
512
513 Helpful reviews and comments from Gaurab Upadhaya, Hugo Salgado,
514 Brian Dixon, Bob Harold, Paul Hoffman, Jakob Schlyter, Andrew
515 Sullivan, Bruce Campbell, S. Moonesamy, and Stephane Bortzmeyer on
516 earlier versions of this document were very much appreciated.
517
518 8. References
519
520 8.1. Normative References
521
522 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
523 STD 13, RFC 1034, November 1987.
524
525 [RFC1035] Mockapetris, P., "Domain names - implementation and
526 specification", STD 13, RFC 1035, November 1987.
527
528 [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
529 and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
530 July 1997.
531
532 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
533 Services", BCP 126, RFC 4786, December 2006.
534
535 [RFC4892] Woolf, S. and D. Conrad, "Requirements for a Mechanism
536 Identifying a Name Server Instance", RFC 4892, June 2007.
537
538 [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option",
539 RFC 5001, August 2007.
540
541 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
542 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
543
544
545
546
547 Abley & Manderson Informational [Page 10]
548 RFC 7108 L-Root Anycast Node Identification January 2014
549
550
551 8.2. Informative References
552
553 [ACD] International Air Transport Association (IATA), "Airline
554 Coding Directory (ACD)", 2013,
555 <http://www.iata.org/publications/Pages/coding.aspx>.
556
557 [Fan2013] Fan, X., Heidemann, J., and R. Govidan, "Evaluating
558 Anycast in the Domain Name System", Proceedings of the
559 IEEE Infocom Turin, Italy, April 2013.
560
561 [ROOT-SERVERS]
562 "root-servers.org", <http://www.root-servers.org>.
563
564 Authors' Addresses
565
566 Joe Abley
567 Dyn, Inc.
568 470 Moore Street
569 London, ON N6C 2C2
570 Canada
571
572 Phone: +1 519 670 9327
573 EMail: jabley@dyn.com
574
575
576 Terry Manderson
577 ICANN
578 12025 Waterfront Drive
579 Suite 300
580 Los Angeles, CA 90094-2536
581 USA
582
583 EMail: terry.manderson@icann.org
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602 Abley & Manderson Informational [Page 11]
603
Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT (Section 4.3), or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L .ROOT-SERVERS/IN/A (Section 4.4)
Using HOSTNAME.BIND/CH/TXT (Section 4.2), ID.SERVER/CH/TXT (Section 4.3), or IDENTITY.L.ROOT-SERVERS.ORG/IN/TXT or IDENTITY.L .ROOT-SERVERS.ORG/IN/A (Section 4.4)