idnits 2.17.1 draft-ietf-dnsop-rfc6304bis-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 35 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 14 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 9 instances of lines with non-RFC3849-compliant IPv6 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 (July 31, 2014) is 3551 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'THIS DOCUMENT' is mentioned on line 835, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-as112-dname-03 ** Obsolete normative reference: RFC 2870 (Obsoleted by RFC 7720) -- Obsolete informational reference (is this intentional?): RFC 6304 (Obsoleted by RFC 7534) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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 Obsoletes: 6304 (if approved) W. Maton 5 Intended status: Informational OttIX 6 Expires: February 1, 2015 July 31, 2014 8 AS112 Nameserver Operations 9 draft-ietf-dnsop-rfc6304bis-04 11 Abstract 13 Many sites connected to the Internet make use of IPv4 addresses that 14 are not globally-unique. Examples are the addresses designated in 15 RFC 1918 for private use within individual sites. 17 Devices in such environments may occasionally originate Domain Name 18 System (DNS) queries (so-called "reverse lookups") corresponding to 19 those private-use addresses. Since the addresses concerned have only 20 local significance, it is good practice for site administrators to 21 ensure that such queries are answered locally. However, it is not 22 uncommon for such queries to follow the normal delegation path in the 23 public DNS instead of being answered within the site. 25 It is not possible for public DNS servers to give useful answers to 26 such queries. In addition, due to the wide deployment of private-use 27 addresses and the continuing growth of the Internet, the volume of 28 such queries is large and growing. The AS112 project aims to provide 29 a distributed sink for such queries in order to reduce the load on 30 the corresponding authoritative servers. The AS112 project is named 31 after the Autonomous System Number (ASN) that was assigned to it. 33 RFC6304 described the steps required to install a new AS112 node, and 34 offered advice relating to such a node's operation. This document 35 updates that advice to facilitate the addition and removal of zones 36 for which query traffic will be sunk at AS112 nodes, using DNAME, 37 whilst still supporting direct delegations to AS112 name servers. 39 This document obsoletes RFC6304. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on February 1, 2015. 58 Copyright Notice 60 Copyright (c) 2014 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. NOTE TO RFC EDITOR AND REVIEWERS . . . . . . . . . . . . . . . 4 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 6 78 3.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.1.1. Direct Delegation . . . . . . . . . . . . . . . . . . 6 80 3.1.2. DNAME Redirection . . . . . . . . . . . . . . . . . . 6 81 3.2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 3.3. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 7 83 4. Installation of a New Node . . . . . . . . . . . . . . . . . . 8 84 4.1. Useful Background Knowledge . . . . . . . . . . . . . . . 8 85 4.2. Topological Location . . . . . . . . . . . . . . . . . . . 8 86 4.3. Operating System and Host Considerations . . . . . . . . . 8 87 4.4. Routing Software . . . . . . . . . . . . . . . . . . . . . 9 88 4.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 11 89 4.6. Testing a Newly-Installed Node . . . . . . . . . . . . . . 16 90 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 5.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 17 92 5.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 5.3. Statistics and Measurement . . . . . . . . . . . . . . . . 17 94 6. Communications . . . . . . . . . . . . . . . . . . . . . . . . 18 95 7. On the Future of AS112 Nodes . . . . . . . . . . . . . . . . . 19 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 97 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 8.2. IANA Actions . . . . . . . . . . . . . . . . . . . . . . . 20 99 8.2.1. IPv6 Transport for Direct Delegation AS112 Servers . . 20 100 8.2.2. Registration in the Special-Purpose AS Numbers 101 Registry . . . . . . . . . . . . . . . . . . . . . . . 20 102 8.2.3. Registration in the IANA IPv4 Special-Purpose 103 Address Registry . . . . . . . . . . . . . . . . . . . 21 104 8.2.4. Registration in the IANA IPv6 Special-Purpose 105 Address Registry . . . . . . . . . . . . . . . . . . . 21 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 107 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 109 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25 110 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 111 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 28 112 Appendix B. Revision History and Venue . . . . . . . . . . . . . 29 113 B.1. draft-jabley-dnsop-rfc6304bis-00 . . . . . . . . . . . . . 29 114 B.2. draft-ietf-dnsop-rfc6304bis-00 . . . . . . . . . . . . . . 29 115 B.3. draft-ietf-dnsop-rfc6304bis-01 . . . . . . . . . . . . . . 29 116 B.4. draft-ietf-dnsop-rfc6304bis-02 . . . . . . . . . . . . . . 29 117 B.5. draft-ietf-dnsop-rfc6304bis-03 . . . . . . . . . . . . . . 29 118 B.6. draft-ietf-dnsop-rfc6304bis-04 . . . . . . . . . . . . . . 29 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 121 1. NOTE TO RFC EDITOR AND REVIEWERS 123 This document uses the phrases "TBA-prefix-v4" and "TBA-prefix-v6" in 124 anticipation of the address assignments requested in the IANA 125 Considerations section of [I-D.ietf-dnsop-as112-dname]. 127 "TBA-address-v4" refers to the address within TBA-prefix-v4 assigned 128 to the name server BLACKHOLE.AS112.ARPA. Similarly, "TBA-address-v6" 129 refers to the corresponding address within TBA-prefix-v6. 131 All of "TBA-prefix-v4", "TBA-address-v4", "TBA-prefix-v6" and "TBA- 132 address-v6" in this document should be replaced with their assigned 133 values prior to publication. 135 The delegation of the AS112.ARPA zone is specified (and requested) in 136 [I-D.ietf-dnsop-as112-dname]. 138 See Appendix B for an abridged revision history, and discussion of an 139 appropriate venue for discussion. 141 This section should be removed prior to publication. 143 2. Introduction 145 Many sites connected to the Internet make use of IPv4 addresses that 146 are not globally unique. Examples are the addresses designated in 147 [RFC1918] for private use within individual sites. 149 Devices in such environments may occasionally originate Domain Name 150 System (DNS) [RFC1034] queries (so-called "reverse lookups") 151 corresponding to those private-use addresses. Since the addresses 152 concerned have only local significance, it is good practice for site 153 administrators to ensure that such queries are answered locally 154 [RFC6303]. However, it is not uncommon for such queries to follow 155 the normal delegation path in the public DNS instead of being 156 answered within the site. 158 It is not possible for public DNS servers to give useful answers to 159 such queries. In addition, due to the wide deployment of private-use 160 addresses and the continuing growth of the Internet, the volume of 161 such queries is large and growing. The AS112 project aims to provide 162 a distributed sink for such queries in order to reduce the load on 163 the IN-ADDR.ARPA authoritative servers [RFC5855]. 165 The AS112 project encompasses a loosely coordinated collection of 166 independently operated name servers. Each name server functions as a 167 single node in an AS112 anycast cloud [RFC4786], and is configured to 168 answer authoritatively for a particular set of nominated zones. 170 The AS112 project is named after the Autonomous System Number (ASN) 171 that was assigned to it (see Appendix A). 173 3. AS112 DNS Service 175 3.1. Approach 177 3.1.1. Direct Delegation 179 [RFC6304] describes an approach whereby zones whose traffic should be 180 directed towards an AS112 sink should be directly delegated to AS112 181 name servers. Correspondingly, each AS112 node is manually 182 configured to answer appropriately for those zones. 184 The guidance in this document preserves this capability for the zones 185 that were originally delegated in this fashion. AS112 nodes that 186 were implemented in accordance with the guidance in [RFC6304] will 187 continue to provide service for those zones. 189 3.1.2. DNAME Redirection 191 [I-D.ietf-dnsop-as112-dname] describes a different approach whereby 192 queries towards specific zones are redirected to an empty zone also 193 hosted on AS112 servers, using DNAME [RFC6672]. 195 The guidance in this document introduces this capability, allowing 196 any zone administrator to sink query traffic in AS112 infrastructure 197 without requiring changes to any AS112 node. 199 3.2. Zones 201 To support Direct Delegation AS112 service, AS112 name servers answer 202 authoritatively for the following zones, corresponding to [RFC1918] 203 private-use netblocks: 205 o 10.IN-ADDR.ARPA 207 o 16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ..., 31.172.IN-ADDR.ARPA 209 o 168.192.IN-ADDR.ARPA 211 and the following zone, corresponding to the "link local" netblock 212 169.254.0.0/16 described in [RFC6890]: 214 o 254.169.IN-ADDR.ARPA 216 To support DNAME Redirection AS112 service, AS112 name servers answer 217 authoritatively for the following zone, as specified in 218 [I-D.ietf-dnsop-as112-dname]: 220 o EMPTY.AS112.ARPA 222 To aid identification of AS112 anycast nodes, each node also answers 223 authoritatively for the following zones: 225 o HOSTNAME.AS112.NET 227 o HOSTNAME.AS112.ARPA 229 See Section 4.5 for the recommended contents of all these zones. 231 3.3. Nameservers 233 To support Direct Delegation AS112 service, the relevant zones listed 234 in Section 3.2 are delegated to the two name servers BLACKHOLE- 235 1.IANA.ORG (192.175.48.6, 2620:4f:8000::6) and BLACKHOLE-2.IANA.ORG 236 (192.175.48.42, 2620:4f:8000::42). 238 Additionally, the server PRISONER.IANA.ORG (192.175.48.1, 2620:4f: 239 8000::1) is listed in the MNAME field of the SOA records of the IN- 240 ADDR.ARPA zones served by AS112 name servers. PRISONER.IANA.ORG 241 receives mainly dynamic update queries. 243 The addresses of all these name servers are covered by the single 244 IPv4 prefix 192.175.48.0/24 and the IPv6 prefix 2620:4f:8000::/48. 245 To date, IPv6 transport for these nameservers has only been available 246 for pre-production testing. Direction to the IANA to add AAAA RRSets 247 for the owner names of these name servers can be found in Section 8. 249 To support DNAME Redirection AS112 service, the single zone 250 EMPTY.AS112.ARPA is delegated to the single name server 251 BLACKHOLE.AS112.ARPA (TBA-address-v4, TBA-address-v6). The addresses 252 of that name server are covered by the single IPv4 prefix 253 TBA-prefix-v4, and the single IPv6 prefix TBA-prefix-v6. 255 4. Installation of a New Node 257 4.1. Useful Background Knowledge 259 Installation of an AS112 node is relatively straightforward. 260 However, experience in the following general areas may prove useful: 262 o inter-domain routing with BGP [RFC4271]; 264 o DNS authoritative server operations; 266 o anycast [RFC4786] distribution of DNS services. 268 4.2. Topological Location 270 AS112 nodes may be located anywhere on the Internet. For nodes that 271 are intended to provide a public service to the Internet community 272 (as opposed to private use), it may well be advantageous to choose a 273 location that is easily (and cheaply) reachable by multiple 274 providers, such as an Internet exchange point. 276 AS112 nodes may advertise their service prefix to BGP peers for local 277 use (analogous to a conventional peering relationship between two 278 providers) or for global use (analogous to a customer relationship 279 with one or more providers). 281 It is good operational practice to notify the community of users that 282 may fall within the reach of a new AS112 node before it is installed. 283 At an Internet Exchange, local mailing lists usually exist to 284 facilitate such announcements. For nodes that are intended to be 285 globally reachable, coordination with other AS112 operators is highly 286 recommended. See also Section 6. 288 4.3. Operating System and Host Considerations 290 Examples in this document are based on UNIX and UNIX-like operating 291 systems, but other operating systems exist which are suitable for use 292 in construction of an AS112 node. 294 The chosen platform should include support for either cloned loopback 295 interfaces, or the capability to bind multiple addresses to a single 296 loopback interface. The addresses of the name servers listed in 297 Section 3.3 will be configured on these interfaces in order that the 298 DNS software can respond to queries properly. 300 A host that is configured to act as an AS112 anycast node should be 301 dedicated to that purpose, and should not be used to simultaneously 302 provide other services. This guidance is provided due to the 303 unpredictable (and occasionally high) traffic levels that AS112 nodes 304 have been seen to attract. 306 System startup scripts should be arranged such that the various 307 AS112-related components start automatically following a system 308 reboot. The order in which interfaces are configured and software 309 components started should be arranged such that routing software 310 startup follows DNS software startup, and DNS software startup 311 follows loopback interface configuration. 313 Wrapper scripts or other arrangements should be employed to ensure 314 that the anycast service prefix for AS112 is not advertised while 315 either the anycast addresses are not configured, or while the DNS 316 software is not running. 318 4.4. Routing Software 320 AS112 nodes signal the availability of AS112 name servers to the 321 Internet using BGP [RFC4271]: each AS112 node is a BGP speaker, and 322 announces the prefixes 192.175.48.0/24 and 2620:4f:8000::/48 to the 323 Internet with origin AS 112 (see also Section 3.3). 325 The examples in this document are based on the Quagga Routing 326 Suite [1] running on Linux, but other software packages exist which 327 also provide suitable BGP support for AS112 nodes. 329 The "bgpd.conf" file is used by Quagga's bgpd daemon, which provides 330 BGP protocol support. The router id in this example is 203.0.113.1; 331 the AS112 node peers with external peers 192.0.2.1, 192.0.2.2, 2001: 332 db8::1 and 2001:db8::2. Note the local AS number 112, and the 333 origination of the prefixes 192.175.48.0/24 and 2620:4f:8000::/48 to 334 support Direct Delegation AS112 service; the IPv4 prefix 335 TBA-prefix-v4 and the IPv6 prefix TBA-prefix-v6 support DNAME 336 Redirection. 338 For clarity, an IPv4-only AS112 node need not configure any of the 339 IPv6 elements that follow; similarly, an IPv6-only AS112 node need 340 not configure any of the IPv4 elements. Such single-stack hosts can 341 still contribute usefully to IPv4 and IPv6 AS112 services, however, 342 and single-stack operation is not discouraged. 344 ! bgpd.conf 345 ! 346 hostname as112-bgpd 347 password 348 enable password 349 ! 350 ! Note that all AS112 nodes use the local Autonomous System Number 351 ! 112, and originate the IPv4 prefixes 192.175.48.0/24 and 352 ! TBA-prefix-v4 and the IPv6 prefixes 2620:4f:8000::/48 and 353 ! TBA-prefix-v6. 354 ! 355 ! All other addresses shown below are illustrative, and 356 ! actual numbers will depend on local circumstances. 357 ! 358 ! IPv4-only or IPv6-only AS112 nodes should omit advertisements 359 ! for address families they do not support. 360 ! 361 router bgp 112 362 bgp router-id 203.0.113.1 363 neighbor 192.0.2.1 remote-as 64496 364 neighbor 192.0.2.1 next-hop-self 365 neighbor 192.0.2.1 prefix-list AS112-v4 out 366 neighbor 192.0.2.1 filter-list 1 out 367 ! 368 neighbor 192.0.2.2 remote-as 64497 369 neighbor 192.0.2.2 next-hop-self 370 neighbor 192.0.2.2 prefix-list AS112-v4 out 371 neighbor 192.0.2.2 filter-list 1 out 372 ! 373 neighbor 2001:db8::1 remote-as 64498 374 neighbor 2001:db8::1 next-hop-self 375 neighbor 2001:db8::1 prefix-list AS112-v6 out 376 neighbor 2001:db8::1 filter-list 1 out 377 ! 378 neighbor 2001:db8::2 remote-as 64499 379 neighbor 2001:db8::2 next-hop-self 380 neighbor 2001:db8::2 prefix-list AS112-v6 out 381 neighbor 2001:db8::2 filter-list 1 out 382 ! 383 network 192.175.48.0/24 384 network TBA-prefix-v4 385 ! 386 address-family ipv6 unicast 387 network 2620:4f:8000::/48 388 network TBA-prefix-v6 389 exit-address-family 390 ! 391 ip prefix-list AS112-v4 permit 192.175.48.0/24 392 ip prefix-list AS112-v4 permit TBA-prefix-v4 393 ! 394 ipv6 prefix-list AS112-v6 permit 2620:4f:8000::/48 395 ipv6 prefix-list AS112-v6 permit TBA-prefix-v6 396 ! 397 ip as-path access-list 1 permit ^$ 398 The configuration above includes two restrictions on what the AS112 399 should advertise to its BGP neighbours: a prefix filter that permits 400 only the service prefixes, and an AS_PATH filter that matches only 401 locally-originated routes. Together, these measures prevent the node 402 from becoming a transit point for its adjacent ASes. 404 The "zebra.conf" file is required to provide integration between 405 protocol daemons (bgpd, in this case) and the kernel. 407 ! zebra.conf 408 ! 409 hostname as112 410 password 411 enable password 412 ! 413 interface lo 414 ! 415 interface eth0 416 ! 418 4.5. DNS Software 420 Although the queries received by AS112 nodes are definitively 421 misdirected, it is important that they be answered in a manner that 422 is accurate and consistent. For this reason AS112 nodes operate as 423 fully-functional and standards-compliant DNS authoritative servers 424 [RFC1034], and hence require appropriate DNS software. 426 Examples in this document are based on ISC BIND9 [2], but other DNS 427 software exists which is suitable for use in construction of an AS112 428 node. 430 The following is a sample BIND9 "named.conf" file for a dedicated 431 AS112 server. Note that the name server is configured to act as an 432 authoritative-only server (i.e. recursion is disabled). The name 433 server is also configured to listen on the various AS112 anycast name 434 server addresses, as well as its local addresses. 436 // named.conf 438 // global options 440 options { 441 listen-on { 442 127.0.0.1; // localhost 444 // the following address is node-dependent, and should be set to 445 // something appropriate for the new AS112 node 446 203.0.113.1; // local address (globally-unique, unicast) 448 // the following addresses are used to support Direct Delegation 449 // AS112 service, and are the same for all AS112 nodes 451 192.175.48.1; // PRISONER.IANA.ORG (anycast) 452 192.175.48.6; // BLACKHOLE-1.IANA.ORG (anycast) 453 192.175.48.42; // BLACKHOLE-2.IANA.ORG (anycast) 455 // the following address is used to support DNAME Redirection 456 // AS112 service, and is the same for all AS112 nodes 458 TBA-address-v4; // BLACKHOLE.AS112.ARPA (anycast) 459 }; 461 listen-on-v6 { 462 ::1; // localhost 464 // the following addresses are used to support Direct Delegation 465 // AS112 service, and are the same for all AS112 nodes 467 2620:4f:8000::1; // PRISONER.IANA.ORG (anycast) 468 2620:4f:8000::6; // BLACKHOLE-1.IANA.ORG (anycast) 469 2620:4f:8000::42; // BLACKHOLE-2.IANA.ORG (anycast) 471 // the following address is used to support DNAME Redirection 472 // AS112 service, and is the same for all AS112 nodes 474 TBA-address-v6; // BLACKHOLE.AS112.ARPA (anycast) 475 }; 477 directory "/var/named"; 478 recursion no; // authoritative-only server 479 }; 481 // log queries, so that when people call us about unexpected 482 // answers to queries they didn't realise they had sent, we 483 // have something to talk about. Note that activating this 484 // naively has the potential to create high CPU load and consume 485 // enormous amounts of disk space. 487 logging { 488 channel "querylog" { 489 file "/var/log/query.log" versions 2 size 500m; 490 print-time yes; 491 }; 492 category queries { querylog; }; 493 }; 494 // Direct Delegation AS112 Service 496 // RFC 1918 498 zone "10.in-addr.arpa" { type master; file "db.dd-empty"; }; 499 zone "16.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 500 zone "17.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 501 zone "18.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 502 zone "19.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 503 zone "20.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 504 zone "21.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 505 zone "22.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 506 zone "23.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 507 zone "24.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 508 zone "25.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 509 zone "26.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 510 zone "27.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 511 zone "28.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 512 zone "29.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 513 zone "30.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 514 zone "31.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 515 zone "168.192.in-addr.arpa" { type master; file "db.dd-empty"; }; 517 // RFC 6890 519 zone "254.169.in-addr.arpa" { type master; file "db.dd-empty"; }; 521 // DNAME Redirection AS112 Service 523 zone "empty.as112.arpa" { type master; file "db.dr-empty"; }; 525 // also answer authoritatively for the HOSTNAME.AS112.NET and 526 // HOSTNAME.AS112.ARPA zones, which contain data of operational 527 // relevance 529 zone "hostname.as112.net" { 530 type master; 531 file "db.hostname.as112.net"; 532 }; 534 zone "hostname.as112.arpa" { 535 type master; 536 file "db.hostname.as112.arpa"; 537 }; 539 The "db.dd-empty" file follows, below. This is the source data used 540 to populate all the IN-ADDR.ARPA zones listed in Section 3.2 that 541 support Direct Delegation AS112 service. Note that the RNAME 542 specified in the SOA record corresponds to 543 hostmaster@root-servers.org, a suitable e-mail address for technical 544 queries about these zones. 546 ; db.dd-empty 547 ; 548 ; Empty zone for Direct Delegation AS112 service. 549 ; 550 $TTL 1W 551 @ IN SOA PRISONER.IANA.ORG. HOSTMASTER.ROOT-SERVERS.ORG. ( 552 1 ; serial number 553 1W ; refresh 554 1M ; retry 555 1W ; expire 556 1W ) ; negative caching TTL 557 ; 558 NS BLACKHOLE-1.IANA.ORG. 559 NS BLACKHOLE-2.IANA.ORG. 560 ; 561 ; There should be no other resource records included in this zone. 562 ; 563 ; Records that relate to RFC 1918-numbered resources within the 564 ; site hosting this AS112 node should not be hosted on this 565 ; name server. 567 The "db.dr-empty" file follows, below. This is the source data used 568 to populate the EMPTY.AS112.ARPA zone that supports DNAME Redirection 569 AS112 service. Note that the RNAME specified in the SOA record 570 corresponds to noc@dns.icann.org, a suitable e-mail address for 571 technical queries about this zone. 573 ; db.dr-empty 574 ; 575 ; Empty zone for Direct Delegation AS112 service. 576 ; 577 $TTL 1W 578 @ IN SOA BLACKHOLE.AS112.ARPA. NOC.DNS.ICANN.ORG. ( 579 1 ; serial number 580 1W ; refresh 581 1M ; retry 582 1W ; expire 583 1W ) ; negative caching TTL 584 ; 585 NS BLACKHOLE.AS112.ARPA. 586 ; 587 ; There should be no other resource records included in this zone. 588 ; 589 ; Records that relate to RFC 1918-numbered resources within the 590 ; site hosting this AS112 node should not be hosted on this 591 ; name server. 593 The "db.hostname.as112.net" and "db.hostname.as112.arpa" files 594 follow, below. These zones contain various resource records that 595 provide operational data to users for troubleshooting or measurement 596 purposes, and should be edited to suit local circumstances. Note 597 that the responses to the queries "HOSTNAME.AS112.NET IN TXT" and 598 "HOSTNAME.AS112.ARPA IN TXT" should fit within a 512 octet DNS/UDP 599 datagram: i.e. it should be available over UDP transport without 600 requiring EDNS0 support by the client. 602 The optional LOC record [RFC1876] included in each zone apex provides 603 information about the geospatial location of the node. 605 ; db.hostname.as112.net 606 ; 607 $TTL 1W 608 @ SOA SERVER.EXAMPLE.NET. ADMIN.EXAMPLE.NET. ( 609 1 ; serial number 610 1W ; refresh 611 1M ; retry 612 1W ; expire 613 1W ) ; negative caching TTL 614 ; 615 NS BLACKHOLE-1.IANA.ORG. 616 NS BLACKHOLE-2.IANA.ORG. 617 ; 618 TXT "Name of Facility or similar" "City, Country" 619 TXT "See http://www.as112.net/ for more information." 620 ; 621 LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m 623 ; db.hostname.as112.arpa 624 ; 625 $TTL 1W 626 @ SOA SERVER.EXAMPLE.NET. ADMIN.EXAMPLE.NET. ( 627 1 ; serial number 628 1W ; refresh 629 1M ; retry 630 1W ; expire 631 1W ) ; negative caching TTL 632 ; 633 NS BLACKHOLE.AS112.ARPA. 634 ; 635 TXT "Name of Facility or similar" "City, Country" 636 TXT "See http://www.as112.net/ for more information." 637 ; 638 LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m 640 4.6. Testing a Newly-Installed Node 642 The BIND9 tool "dig" can be used to retrieve the TXT resource records 643 associated with the names "HOSTNAME.AS112.NET" and 644 "HOSTNAME.AS112.ARPA", directed at one of the AS112 anycast name 645 server addresses. Continuing the example from above, the response 646 received should indicate the identity of the AS112 node that 647 responded to the query. See Section 4.5 for more details about the 648 resource records associated with "HOSTNAME.AS112.NET". 650 % dig @PRISONER.IANA.ORG HOSTNAME.AS112.NET txt +short +norec 651 "Name of Facility or similar" "City, Country" 652 "See http://www.as112.net/ for more information." 653 % 655 If the response received indicates a different node is being used, 656 then there is probably a routing problem to solve. If there is no 657 response received at all, there might be host or name server problem. 658 Judicious use of tools such as traceroute, and consultation of BGP 659 looking glasses might be useful in troubleshooting. 661 Note that an appropriate set of tests for a new server will include 662 queries sent from many different places within the expected service 663 area of the node, using both UDP and TCP transport, and exercising 664 all three AS112 anycast name server addresses. 666 5. Operations 668 5.1. Monitoring 670 AS112 nodes should be monitored to ensure they are functioning 671 correctly, just as with any other production service. An AS112 node 672 that stops answering queries correctly can cause failures and 673 timeouts in unexpected places and can lead to failures in dependent 674 systems that can be difficult to troubleshoot. 676 5.2. Downtime 678 An AS112 node that needs to go off-line (e.g. for planned maintenance 679 or as part of the diagnosis of some problem) should stop advertising 680 the AS112 service prefixes to its BGP peers. This can be done by 681 shutting down the routing software on the node altogether or by 682 causing the routing system to withdraw the route. 684 Withdrawal of the service prefixes is important in order to avoid 685 blackholing query traffic in the event that the DNS software on the 686 node is not functioning normally. 688 5.3. Statistics and Measurement 690 Use of the AS112 node should be measured in order to track long-term 691 trends, identify anomalous conditions, and to ensure that the 692 configuration of the AS112 node is sufficient to handle the query 693 load. 695 Examples of free monitoring tools that might be useful to operators 696 of AS112 nodes include: 698 o bindgraph [3] 700 o dnstop [4] 702 o DSC [5] 704 6. Communications 706 It is good operational practice to notify the community of users that 707 may fall within the reach of a new AS112 node before it is installed. 708 At Internet Exchanges, local mailing lists usually exist to 709 facilitate such announcements. 711 For nodes that are intended to be globally reachable, coordination 712 with other AS112 operators is especially recommended. The mailing 713 list is operated for this 714 purpose. 716 Information pertinent to AS112 operations is maintained at 717 . 719 Information about an AS112 node should also be published within the 720 DNS, within the "HOSTNAME.AS112.NET" and "HOSTNAME.AS112.ARPA" zones. 721 See Section 4.5 for more details. 723 7. On the Future of AS112 Nodes 725 It is recommended practice for the operators of recursive name 726 servers to answer queries for zones served by AS112 nodes locally, 727 such that queries never have an opportunity to reach AS112 servers 728 [RFC6303]. Operational experience with AS112 nodes does not 729 currently indicate an observable trend towards compliance with those 730 recommendations, however. 732 It is expected that some DNS software vendors will include default 733 configuration that will implement measures such as those described in 734 [RFC6303]. If such software is widely deployed, it is reasonable to 735 assume that the query load received by AS112 nodes will decrease; 736 however, it is safe to assume that the query load will not decrease 737 to zero, and consequently that AS112 nodes will continue to provide a 738 useful service for the foreseeable future. 740 The use of DNAME Redirection to provide AS112 service is new, and 741 hence is informed by minimal operational experience. The use of 742 DNAME means that queries for many source zones could be redirected to 743 AS112 infrastructure with no real opportunity for coordination. 745 If the DNAME Redirection approach is successful, and in the absence 746 of any operational concerns, the community might well recommend the 747 retirement of the original Direct Delegation AS112 service. This 748 document makes no such recommendation, however. 750 8. IANA Considerations 752 8.1. General 754 The name servers associated with Direct Delegation AS112 service are 755 all named under the domain IANA.ORG (see Section 3.3). However, the 756 anycast infrastructure itself is operated by a loosely-coordinated, 757 diverse mix of organisations across the Internet, and is not an IANA 758 function. 760 The autonomous system number 112, the IPv4 prefix 192.175.48.0/24 and 761 the IPv6 prefix 2620:4f:8000::/48 were assigned by ARIN. 763 The IPv4 prefix TBA-prefix-v4 and the IPv6 prefix TBA-prefix-v6, used 764 for DNAME Redirection AS112 service, were assigned by the IANA 765 [I-D.ietf-dnsop-as112-dname]. 767 The three nameservers BLACKHOLE-1.IANA.ORG, BLACKHOLE-2.IANA.ORG and 768 PRISONER.IANA.ORG are also reachable over IPv6, as described in 769 Section 3.3. Following a substantial period of pre-production 770 testing by AS112 operators, the IANA is directed to add AAAA RRSets 771 to those owner names in Section 8.2.1, to allow the servers to 772 receive queries and generate responses over IPv6 transport. 774 8.2. IANA Actions 776 8.2.1. IPv6 Transport for Direct Delegation AS112 Servers 778 The IANA is directed to add the following AAAA resource records for 779 the three Direct Delegation AS112 name servers named under IANA.ORG: 781 +----------------------+------------------+ 782 | Owner Name | AAAA RDATA | 783 +----------------------+------------------+ 784 | PRISONER.IANA.ORG | 2620:4f:8000::1 | 785 | | | 786 | BLACKHOLE-1.IANA.ORG | 2620:4f:8000::6 | 787 | | | 788 | BLACKHOLE-2.IANA.ORG | 2620:4f:8000::42 | 789 +----------------------+------------------+ 791 8.2.2. Registration in the Special-Purpose AS Numbers Registry 793 The IANA is directed to add AS112 to the "Special-Purpose AS Numbers" 794 registry specified in [RFC7249] as follows: 796 AS Numbers: 112 798 Reason for Reservation: Used by the AS112 project to sink 799 misdirected DNS queries; see [THIS DOCUMENT] 801 8.2.3. Registration in the IANA IPv4 Special-Purpose Address Registry 803 The IANA is directed to add 192.175.48.0/24 to the "IANA IPv4 804 Special-Purpose Address Registry" specified in [RFC6890] as follows: 806 Address Block: 192.175.48.0/24 808 Name: Direct Delegation AS112 Service 810 RFC: [THIS DOCUMENT] 812 Allocation Date: 1996-01-05 814 Termination Date: N/A 816 Source: True 818 Destination: True 820 Forwardable: True 822 Global: True 824 Reserved-by-Protocol: False 826 8.2.4. Registration in the IANA IPv6 Special-Purpose Address Registry 828 The IANA is directed to add 2620:4f:8000::/48 to the "IANA IPv6 829 Special-Purpose Address Registry" specified in [RFC6890] as follows: 831 Address Block: 2620:4f:8000::/48 833 Name: Direct Delegation AS112 Service 835 RFC: [THIS DOCUMENT] 837 Allocation Date: 2011-05-31 839 Termination Date: N/A 840 Source: True 842 Destination: True 844 Forwardable: True 846 Global: True 848 Reserved-by-Protocol: False 850 9. Security Considerations 852 Hosts should never normally send queries to AS112 servers; queries 853 relating to private-use addresses should be answered locally within a 854 site. Hosts that send queries to AS112 servers may well leak 855 information relating to private infrastructure to the public network, 856 and this could present a security risk. This risk is orthogonal to 857 the presence or absence of authoritative servers for these zones in 858 the public DNS infrastructure, however. 860 Queries that are answered by AS112 servers are usually unintentional; 861 it follows that the responses from AS112 servers are usually 862 unexpected. Unexpected inbound traffic can trigger intrusion 863 detection systems or alerts by firewalls. Operators of AS112 servers 864 should be prepared to be contacted by operators of remote 865 infrastructure who believe their security has been violated. Advice 866 to those who mistakenly believe that responses from AS112 nodes 867 constitutes an attack on their infrastructure can be found in 868 [RFC6305]. 870 The deployment of AS112 nodes is very loosely coordinated compared to 871 other services distributed using anycast. The malicious compromise 872 of an AS112 node and subversion of the data served by the node is 873 hence more difficult to detect due to the lack of central management. 874 Since it is conceivable that changing the responses to queries 875 received by AS112 nodes might influence the behaviour of the hosts 876 sending the queries, such a compromise might be used as an attack 877 vector against private infrastructure. 879 Operators of AS112 should take appropriate measures to ensure that 880 AS112 nodes are appropriately protected from compromise, such as 881 would normally be employed for production name server or network 882 infrastructure. The guidance provided for root name servers in 883 [RFC2870] may be instructive. 885 The zones hosted by AS112 servers are not signed with DNSSEC 886 [RFC4033]. Given the distributed and loosely-coordinated structure 887 of the AS112 service, the zones concerned could only be signed if the 888 private key material used was effectively public, obviating any 889 security benefit resulting from the use of those keys. 891 10. Acknowledgements 893 This document benefited from review and suggestions from Leo Vegoda 894 and Pearl Liang. 896 The authors wish to acknowledge the assistance of Bill Manning, John 897 Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank 898 Habicht, Chris Thompson, Peter Losher, Peter Koch, Alfred Hoenes, S. 899 Moonesamy and Mehmet Akcin in the preparation of [RFC6304], which 900 this document supercedes. 902 11. References 904 11.1. Normative References 906 [I-D.ietf-dnsop-as112-dname] 907 Abley, J., Dickson, B., Kumari, W., and G. Michaelson, 908 "AS112 Redirection using DNAME", 909 draft-ietf-dnsop-as112-dname-03 (work in progress), 910 March 2014. 912 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 913 STD 13, RFC 1034, November 1987. 915 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 916 E. Lear, "Address Allocation for Private Internets", 917 BCP 5, RFC 1918, February 1996. 919 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root 920 Name Server Operational Requirements", BCP 40, RFC 2870, 921 June 2000. 923 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 924 Rose, "DNS Security Introduction and Requirements", 925 RFC 4033, March 2005. 927 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 928 Protocol 4 (BGP-4)", RFC 4271, January 2006. 930 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 931 Services", BCP 126, RFC 4786, December 2006. 933 11.2. Informative References 935 [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A 936 Means for Expressing Location Information in the Domain 937 Name System", RFC 1876, January 1996. 939 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 940 Reverse Zones", BCP 155, RFC 5855, May 2010. 942 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 943 RFC 6303, July 2011. 945 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", 946 RFC 6304, July 2011. 948 [RFC6305] Abley, J. and W. Maton, "I'm Being Attacked by 949 PRISONER.IANA.ORG!", RFC 6305, July 2011. 951 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 952 DNS", RFC 6672, June 2012. 954 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 955 "Special-Purpose IP Address Registries", BCP 153, 956 RFC 6890, April 2013. 958 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, 959 May 2014. 961 URIs 963 [1] 965 [2] 967 [3] 969 [4] 971 [5] 973 Appendix A. History 975 Widespread use of the private address blocks listed in [RFC1918] 976 followed that document's publication in 1996. At that time the IN- 977 ADDR.ARPA zone was served by root servers. 979 The idea of off-loading IN-ADDR.ARPA queries relating to [RFC1918] 980 addresses from the root name servers was first proposed by Bill 981 Manning and John Brown. 983 The use of anycast for distributing authoritative DNS service for 984 [RFC1918] IN-ADDR.ARPA zones was subsequently proposed at a private 985 meeting of root server operators. 987 ARIN provided an IPv4 prefix for the anycast service and also the 988 autonomous system number 112 for use in originating that prefix. 989 This assignment gave the project its name. 991 In 2002, the first AS112 anycast nodes were deployed. 993 In 2011, the IN-ADDR.ARPA zone was redelegated from the root servers 994 to a new set of servers operated independently by AfriNIC, APNIC, 995 ARIN, ICANN, LACNIC, and the RIPE NCC and named according to 996 [RFC5855]. 998 [RFC6304], the precursor to this document, was published in July 999 2011. 1001 The use of anycast name servers in the AS112 project contributed to 1002 the operational experience of anycast DNS services, and it can be 1003 seen as a precursor to the anycast distribution of other 1004 authoritative DNS servers in subsequent years (e.g., various root 1005 servers). 1007 Appendix B. Revision History and Venue 1009 A suitable venue for discussion of this document is the dnsop working 1010 group. Private comments may also be directed at the authors. 1012 This section (and sub-sections) should be removed prior to 1013 publication. 1015 B.1. draft-jabley-dnsop-rfc6304bis-00 1017 Initial revision of [RFC6304] intended to provide guidance consistent 1018 with [I-D.ietf-dnsop-as112-dname]. 1020 B.2. draft-ietf-dnsop-rfc6304bis-00 1022 Change of filename following working group adoption. 1024 B.3. draft-ietf-dnsop-rfc6304bis-01 1026 Correct "Obsoletes" header in document metadata from "RFC6304" to 1027 "6304" as requested by Tim Wicinski. 1029 B.4. draft-ietf-dnsop-rfc6304bis-02 1031 Add IPv6 details for Direct Delegation AS112 service, including IANA 1032 considerations to add AAAA RRs to PRISONER.IANA.ORG and friends. 1034 Add IANA considerations that will add AS112 to the "Special-Purpose 1035 AS Numbers" registry, as created in [RFC7249]. 1037 Merge in some AUTH48 changes from RFC6304 that had been overlooked. 1039 B.5. draft-ietf-dnsop-rfc6304bis-03 1041 Change reference from RFC 5735 to RFC 6890. 1043 B.6. draft-ietf-dnsop-rfc6304bis-04 1045 Add change section for -03 that was previously overlooked. 1047 Register IPv4 netblock in IANA special-use registry. 1049 Register IPv6 netblock in IANA special-use registry. 1051 Modify registration data for AS112 in corresponding special-use 1052 registry. 1054 Add shout-out to Pearl and Leo. 1056 Authors' Addresses 1058 Joe Abley 1059 Dyn, Inc. 1060 470 Moore Street 1061 London, ON N6C 2C2 1062 Canada 1064 Phone: +1 519 670 9327 1065 Email: jabley@dyn.com 1067 William F. Maton Sotomayor 1068 Ottawa Internet Exchange 1069 Constitution Square 1070 1400-340 Albert Street 1071 Ottawa, ON K1R 0A5 1072 Canada 1074 Email: wmaton@ottix.net