idnits 2.17.1 draft-ietf-dnsop-rfc6304bis-06.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 10 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 (February 14, 2015) is 3359 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 984 -- Looks like a reference, but probably isn't: '2' on line 986 -- Looks like a reference, but probably isn't: '3' on line 988 -- Looks like a reference, but probably isn't: '4' on line 990 -- Looks like a reference, but probably isn't: '5' on line 992 -- Looks like a reference, but probably isn't: '6' on line 994 -- Looks like a reference, but probably isn't: '7' on line 996 -- Looks like a reference, but probably isn't: '8' on line 998 -- Looks like a reference, but probably isn't: '9' on line 1000 == Missing Reference: 'THIS DOCUMENT' is mentioned on line 854, 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 (==), 11 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. Sotomayor 5 Intended status: Informational OttIX 6 Expires: August 18, 2015 February 14, 2015 8 AS112 Nameserver Operations 9 draft-ietf-dnsop-rfc6304bis-06 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 This document describes the steps required to install a new AS112 34 node and offers advice relating to such a node's operation. 36 This document obsoletes RFC6304. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on August 18, 2015. 55 Copyright Notice 57 Copyright (c) 2015 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. NOTE TO RFC EDITOR AND REVIEWERS . . . . . . . . . . . . . . 3 73 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 4 75 3.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3.1.1. Direct Delegation . . . . . . . . . . . . . . . . . . 4 77 3.1.2. DNAME Redirection . . . . . . . . . . . . . . . . . . 5 78 3.2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3.3. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 5 80 4. Installation of a New Node . . . . . . . . . . . . . . . . . 6 81 4.1. Useful Background Knowledge . . . . . . . . . . . . . . . 6 82 4.2. Topological Location . . . . . . . . . . . . . . . . . . 6 83 4.3. Operating System and Host Considerations . . . . . . . . 7 84 4.4. Routing Software . . . . . . . . . . . . . . . . . . . . 7 85 4.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . 9 86 4.6. Testing a Newly Installed Node . . . . . . . . . . . . . 15 87 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 5.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 15 89 5.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . 15 90 5.3. Statistics and Measurement . . . . . . . . . . . . . . . 16 91 6. Communications . . . . . . . . . . . . . . . . . . . . . . . 16 92 7. On the Future of AS112 Nodes . . . . . . . . . . . . . . . . 16 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 94 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 8.2. IANA Actions . . . . . . . . . . . . . . . . . . . . . . 18 96 8.2.1. IPv6 Transport for Direct Delegation AS112 Servers . 18 97 8.2.2. Registration in the Special-Purpose AS Numbers 98 Registry . . . . . . . . . . . . . . . . . . . . . . 18 99 8.2.3. Registration in the IANA IPv4 Special-Purpose 100 Address Registry . . . . . . . . . . . . . . . . . . 18 101 8.2.4. Registration in the IANA IPv6 Special-Purpose 102 Address Registry . . . . . . . . . . . . . . . . . . 19 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 104 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 107 11.2. Informative References . . . . . . . . . . . . . . . . . 21 108 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 109 Appendix A. A Brief History of AS112 . . . . . . . . . . . . . . 22 110 Appendix B. Changes Since RFC 6304 . . . . . . . . . . . . . . . 23 111 Appendix C. Revision History and Venue . . . . . . . . . . . . . 23 112 C.1. draft-jabley-dnsop-rfc6304bis-00 . . . . . . . . . . . . 23 113 C.2. draft-ietf-dnsop-rfc6304bis-00 . . . . . . . . . . . . . 23 114 C.3. draft-ietf-dnsop-rfc6304bis-01 . . . . . . . . . . . . . 23 115 C.4. draft-ietf-dnsop-rfc6304bis-02 . . . . . . . . . . . . . 24 116 C.5. draft-ietf-dnsop-rfc6304bis-03 . . . . . . . . . . . . . 24 117 C.6. draft-ietf-dnsop-rfc6304bis-04 . . . . . . . . . . . . . 24 118 C.7. draft-ietf-dnsop-rfc6304bis-05 . . . . . . . . . . . . . 24 119 C.8. draft-ietf-dnsop-rfc6304bis-06 . . . . . . . . . . . . . 25 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 122 1. NOTE TO RFC EDITOR AND REVIEWERS 124 This document uses the phrases "TBA-prefix-v4" and "TBA-prefix-v6" in 125 anticipation of the address assignments requested in the IANA 126 Considerations section of [I-D.ietf-dnsop-as112-dname]. 128 "TBA-address-v4" refers to the address within TBA-prefix-v4 assigned 129 to the nameserver BLACKHOLE.AS112.ARPA. Similarly, "TBA-address-v6" 130 refers to the corresponding address within TBA-prefix-v6. 132 All of "TBA-prefix-v4", "TBA-address-v4", "TBA-prefix-v6" and "TBA- 133 address-v6" in this document should be replaced with their assigned 134 values prior to publication. 136 The delegation of the AS112.ARPA zone is specified (and requested) in 137 [I-D.ietf-dnsop-as112-dname]. 139 See Appendix C for an abridged revision history, and discussion of an 140 appropriate venue for discussion. 142 This section should be removed prior to publication. 144 2. Introduction 146 Many sites connected to the Internet make use of IPv4 addresses that 147 are not globally unique. Examples are the addresses designated in 148 [RFC1918] for private use within individual sites. 150 Devices in such environments may occasionally originate Domain Name 151 System (DNS) [RFC1034] queries (so-called "reverse lookups") 152 corresponding to those private-use addresses. Since the addresses 153 concerned have only local significance, it is good practice for site 154 administrators to ensure that such queries are answered locally 155 [RFC6303]. However, it is not uncommon for such queries to follow 156 the normal delegation path in the public DNS instead of being 157 answered within the site. 159 It is not possible for public DNS servers to give useful answers to 160 such queries. In addition, due to the wide deployment of private-use 161 addresses and the continuing growth of the Internet, the volume of 162 such queries is large and growing. The AS112 project aims to provide 163 a distributed sink for such queries in order to reduce the load on 164 the IN-ADDR.ARPA authoritative servers [RFC5855]. 166 The AS112 project encompasses a loosely coordinated collection of 167 independently operated nameservers. Each nameserver functions as a 168 single node in an AS112 anycast cloud [RFC4786], and is configured to 169 answer authoritatively for a particular set of nominated zones. 171 The AS112 project is named after the Autonomous System Number (ASN) 172 that was assigned to it (see Appendix A). 174 3. AS112 DNS Service 176 3.1. Approach 178 3.1.1. Direct Delegation 180 The AS112 Project currently uses an approach whereby zones whose 181 traffic should be directed towards an AS112 sink should be directly 182 delegated to AS112 nameservers. Correspondingly, each AS112 node is 183 manually configured to answer appropriately for those zones. 185 The guidance in this document describes this capability for the zones 186 that were originally delegated in this fashion. AS112 nodes that 187 were implemented in accordance with the guidance found here will 188 continue to provide service for those zones. 190 3.1.2. DNAME Redirection 192 [I-D.ietf-dnsop-as112-dname] describes a different approach whereby 193 queries towards specific zones are redirected to an empty zone also 194 hosted on AS112 servers, using DNAME [RFC6672]. 196 The guidance in this document introduces this capability, allowing 197 any zone administrator to sink query traffic in AS112 infrastructure 198 without requiring changes to any AS112 node. 200 3.2. Zones 202 To support Direct Delegation AS112 service, AS112 name nameservers 203 answer authoritatively for the following zones, corresponding to 204 [RFC1918] private-use netblocks: 206 o 10.IN-ADDR.ARPA 208 o 16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ..., 31.172.IN-ADDR.ARPA 210 o 168.192.IN-ADDR.ARPA 212 and the following zone, corresponding to the "link local" netblock 213 169.254.0.0/16 listed in [RFC6890]: 215 o 254.169.IN-ADDR.ARPA 217 To support DNAME Redirection AS112 service, AS112 name servers answer 218 authoritatively for the following zone, as specified in 219 [I-D.ietf-dnsop-as112-dname]: 221 o EMPTY.AS112.ARPA 223 To aid identification of AS112 anycast nodes, each node also answers 224 authoritatively for the following zones: 226 o HOSTNAME.AS112.NET 228 o HOSTNAME.AS112.ARPA 230 See Section 4.5 for the recommended contents of all these zones. 232 3.3. Nameservers 234 To support Direct Delegation AS112 service, the relevant zones listed 235 in Section 3.2 are delegated to the two nameservers BLACKHOLE- 236 1.IANA.ORG (192.175.48.6, 2620:4f:8000::6) and BLACKHOLE-2.IANA.ORG 237 (192.175.48.42, 2620:4f:8000::42). 239 Additionally, the server PRISONER.IANA.ORG (192.175.48.1, 240 2620:4f:8000::1) is listed in the MNAME field of the SOA records of 241 the IN-ADDR.ARPA zones served by AS112 name servers. 242 PRISONER.IANA.ORG receives mainly dynamic update queries. 244 The addresses of all these nameservers are covered by the single IPv4 245 prefix 192.175.48.0/24 and the IPv6 prefix 2620:4f:8000::/48. To 246 date, IPv6 transport for these nameservers has only been available 247 for pre-production testing. Direction to the IANA to add AAAA RRSets 248 for the owner names of these nameservers can be found in Section 8. 250 To support DNAME Redirection AS112 service, the single zone 251 EMPTY.AS112.ARPA is delegated to the single nameserver 252 BLACKHOLE.AS112.ARPA (TBA-address-v4, TBA-address-v6). The addresses 253 of that nameserver are covered by the single IPv4 prefix TBA-prefix- 254 v4, and the single IPv6 prefix TBA-prefix-v6. 256 4. Installation of a New Node 258 4.1. Useful Background Knowledge 260 Installation of an AS112 node is relatively straightforward. 261 However, experience in the following general areas may prove useful: 263 o inter-domain routing with BGP [RFC4271]; 265 o DNS authoritative server operations; and, 267 o anycast [RFC4786] distribution of DNS services. 269 4.2. Topological Location 271 AS112 nodes may be located anywhere on the Internet. For nodes that 272 are intended to provide a public service to the Internet community 273 (as opposed to private use), it may well be advantageous to choose a 274 location that is easily (and cheaply) reachable by multiple 275 providers, such as an Internet Exchange Point. 277 AS112 nodes may advertise their service prefix to BGP peers for local 278 use (analogous to a conventional peering relationship between two 279 providers) or for global use (analogous to a customer relationship 280 with one or more providers). 282 It is good operational practice to notify the community of users that 283 may fall within the reach of a new AS112 node before it is installed. 284 At an Internet Exchange, local mailing lists usually exist to 285 facilitate such announcements. For nodes that are intended to be 286 globally reachable, coordination with other AS112 operators is highly 287 recommended. See also Section 6. 289 4.3. Operating System and Host Considerations 291 Examples in this document are based on UNIX and UNIX-like operating 292 systems, but other operating systems exist that are suitable for use 293 in construction of an AS112 node. 295 The chosen platform should include either support for cloned loopback 296 interfaces or the capability to bind multiple addresses to a single 297 loopback interface. The addresses of the nameservers listed in 298 Section 3.3 will be configured on these interfaces in order that the 299 DNS software can respond to queries properly. 301 A host that is configured to act as an AS112 anycast node should be 302 dedicated to that purpose and should not be used to simultaneously 303 provide other services. This guidance is provided due to the 304 unpredictable (and occasionally high) traffic levels that AS112 nodes 305 have been seen to attract. 307 System startup scripts should be arranged such that the various 308 AS112-related components start automatically following a system 309 reboot. The order in which interfaces are configured and software 310 components started should be arranged such that routing software 311 startup follows DNS software startup, and DNS software startup 312 follows loopback interface configuration. 314 Wrapper scripts or other arrangements should be employed to ensure 315 that the anycast service prefix for AS112 is not advertised while 316 either the anycast addresses are not configured or the DNS software 317 is not running. 319 4.4. Routing Software 321 AS112 nodes signal the availability of AS112 nameservers to the 322 Internet using BGP [RFC4271]: each AS112 node is a BGP speaker and 323 announces the prefixes 192.175.48.0/24 and 2620:4f:8000::/48 to the 324 Internet with origin AS 112 (see also Section 3.3). 326 The examples in this document are based on the Quagga Routing Suite 327 [1] running on Linux, but other software packages exist which also 328 provide suitable BGP support for AS112 nodes. 330 The "bgpd.conf" file is used by Quagga's bgpd daemon, which provides 331 BGP support. The router ID in this example is 203.0.113.1; the AS112 332 node peers with external peers 192.0.2.1, 192.0.2.2, 2001:db8::1 and 333 2001:db8::2. Note the local AS number is 112, and the service 334 prefixes originated from the AS112 node to support Direct Delegation 335 service are 192.175.48.0/24 and 2620:4f:8000::/48; the IPv4 prefix 336 TBA-prefix-v4 and the IPv6 prefix TBA-prefix-v6 support DNAME 337 Redirection. 339 For clarity, an IPv4-only AS112 node need not configure any of the 340 IPv6 elements that follow; similarly, an IPv6-only AS112 node need 341 not configure any of the IPv4 elements. Such single-stack hosts can 342 still contribute usefully to IPv4 and IPv6 AS112 services, however, 343 and single-stack operation is not discouraged. 345 ! bgpd.conf 346 ! 347 hostname as112-bgpd 348 password 349 enable password 350 ! 351 ! Note that all AS112 nodes use the local Autonomous System Number 352 ! 112, and originate the IPv4 prefixes 192.175.48.0/24 and 353 ! TBA-prefix-v4 and the IPv6 prefixes 2620:4f:8000::/48 and 354 ! TBA-prefix-v6. 355 ! 356 ! All other addresses shown below are illustrative, and 357 ! actual numbers will depend on local circumstances. 358 ! 359 ! IPv4-only or IPv6-only AS112 nodes should omit advertisements 360 ! for address families they do not support. 361 ! 362 router bgp 112 363 bgp router-id 203.0.113.1 364 neighbor 192.0.2.1 remote-as 64496 365 neighbor 192.0.2.1 next-hop-self 366 neighbor 192.0.2.1 prefix-list AS112-v4 out 367 neighbor 192.0.2.1 filter-list 1 out 368 ! 369 neighbor 192.0.2.2 remote-as 64497 370 neighbor 192.0.2.2 next-hop-self 371 neighbor 192.0.2.2 prefix-list AS112-v4 out 372 neighbor 192.0.2.2 filter-list 1 out 373 ! 374 neighbor 2001:db8::1 remote-as 64498 375 neighbor 2001:db8::1 next-hop-self 376 neighbor 2001:db8::1 prefix-list AS112-v6 out 377 neighbor 2001:db8::1 filter-list 1 out 378 ! 379 neighbor 2001:db8::2 remote-as 64499 380 neighbor 2001:db8::2 next-hop-self 381 neighbor 2001:db8::2 prefix-list AS112-v6 out 382 neighbor 2001:db8::2 filter-list 1 out 383 ! 384 network 192.175.48.0/24 385 network TBA-prefix-v4 386 ! 387 address-family ipv6 unicast 388 network 2620:4f:8000::/48 389 network TBA-prefix-v6 390 exit-address-family 391 ! 392 ip prefix-list AS112-v4 permit 192.175.48.0/24 393 ip prefix-list AS112-v4 permit TBA-prefix-v4 394 ! 395 ipv6 prefix-list AS112-v6 permit 2620:4f:8000::/48 396 ipv6 prefix-list AS112-v6 permit TBA-prefix-v6 397 ! 398 ip as-path access-list 1 permit ^$ 400 The configuration above includes two restrictions on what the AS112 401 should advertise to its BGP neighbours: a prefix filter that permits 402 only the service prefixes, and an AS_PATH filter that matches only 403 locally-originated routes. Together, these measures prevent the node 404 from becoming a transit point for its adjacent ASes. 406 The "zebra.conf" file is required to provide integration between 407 protocol daemons (bgpd, in this case) and the kernel. 409 ! zebra.conf 410 ! 411 hostname as112 412 password 413 enable password 414 ! 415 interface lo 416 ! 417 interface eth0 418 ! 420 4.5. DNS Software 422 Although the queries received by AS112 nodes are definitively 423 misdirected, it is important that they be answered in a manner that 424 is accurate and consistent. For this reason, AS112 nodes operate as 425 fully functional and standards-compliant DNS authoritative servers 426 [RFC1034], and hence require appropriate DNS software. 428 Examples in this document are based on ISC BIND9 [2], but other DNS 429 software exists that is suitable for use in construction of an AS112 430 node. 432 The following is a sample BIND9 "named.conf" file for a dedicated 433 AS112 server. Note that the nameserver is configured to act as an 434 authoritative-only server (i.e., recursion is disabled). The 435 nameserver is also configured to listen on the various AS112 anycast 436 nameserver addresses, as well as its local addresses. 438 A basic logging example is included in the sample as well. AS112 439 operators may exercise discretion at the amount of logging detail 440 they desire or the type of logging they may use in the maintenance of 441 their node. The detail of information can then be used to single-out 442 bad implementors, badly managed nameservers or for simple measurement 443 analysis. 445 // named.conf 447 // Global options 449 options { 450 listen-on { 451 127.0.0.1; // localhost 453 // The following address is node-dependent and should be set to 454 // something appropriate for the new AS112 node. 456 203.0.113.1; // local address (globally unique, unicast) 458 // The following addresses are used to support Direct Delegation 459 // AS112 service, and are the same for all AS112 nodes. 461 192.175.48.1; // prisoner.iana.org (anycast) 462 192.175.48.6; // blackhole-1.iana.org (anycast) 463 192.175.48.42; // blackhole-2.iana.org (anycast) 465 // The following address is used to support DNAME Redirection 466 // AS112 service, and is the same for all AS112 nodes. 468 TBA-address-v4; // blackhole.as112.arpa (anycast) 469 }; 471 listen-on-v6 { 472 ::1; // localhost 474 // The following addresses are used to support Direct Delegation 475 // AS112 service, and are the same for all AS112 nodes. 477 2620:4f:8000::1; // prisoner.iana.org (anycast) 478 2620:4f:8000::6; // blackhole-1.iana.org (anycast) 479 2620:4f:8000::42; // blackhole-2.iana.org (anycast) 481 // The following address is used to support DNAME Redirection 482 // AS112 service, and is the same for all AS112 nodes. 484 TBA-address-v6; // blackhole.as112.arpa (anycast) 485 }; 487 directory "/var/named"; 488 recursion no; // authoritative-only server 489 }; 491 // Log queries, so that when people call us about unexpected 492 // answers to queries they didn't realise they had sent, we 493 // have something to talk about. Note that activating this 494 // naively has the potential to create high CPU load and consume 495 // enormous amounts of disk space. This example retains 2 old 496 // versions at a maximum of 500MB each before rotating out the 497 // oldest one. 499 logging { 500 channel "querylog" { 501 file "/var/log/query.log" versions 2 size 500m; 502 print-time yes; 503 }; 504 category queries { querylog; }; 505 }; 507 // Direct Delegation AS112 Service 509 // RFC 1918 511 zone "10.in-addr.arpa" { type master; file "db.dd-empty"; }; 512 zone "16.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 513 zone "17.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 514 zone "18.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 515 zone "19.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 516 zone "20.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 517 zone "21.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 518 zone "22.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 519 zone "23.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 520 zone "24.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 521 zone "25.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 522 zone "26.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 523 zone "27.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 524 zone "28.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 525 zone "29.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 526 zone "30.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 527 zone "31.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 528 zone "168.192.in-addr.arpa" { type master; file "db.dd-empty"; }; 530 // RFC 6890 532 zone "254.169.in-addr.arpa" { type master; file "db.dd-empty"; }; 534 // DNAME Redirection AS112 Service 536 zone "empty.as112.arpa" { type master; file "db.dr-empty"; }; 538 // Also answer authoritatively for the HOSTNAME.AS112.NET and 539 // HOSTNAME.AS112.ARPA zones, which contains data of operational 540 // relevance. 542 zone "hostname.as112.net" { 543 type master; 544 file "db.hostname.as112.net"; 545 }; 547 zone "hostname.as112.arpa" { 548 type master; 549 file "db.hostname.as112.arpa"; 550 }; 552 The "db.dd-empty" file follows, below. This is the source data used 553 to populate all the IN-ADDR.ARPA zones listed in Section 3.2 that 554 support Direct Delegation AS112 service. Note that the RNAME 555 specified in the SOA record corresponds to hostmaster@root- 556 servers.org, a suitable email address for receiving technical queries 557 about these zones. 559 ; db.dd-empty 560 ; 561 ; Empty zone for Direct Delegation AS112 service. 562 ; 563 $TTL 1W 564 @ IN SOA prisoner.iana.org. hostmaster.root-servers.org. ( 565 1 ; serial number 566 1W ; refresh 567 1M ; retry 568 1W ; expire 569 1W ) ; negative caching TTL 570 ; 571 NS blackhole-1.iana.org. 572 NS blackhole-2.iana.org. 573 ; 574 ; There should be no other resource records included in this zone. 575 ; 576 ; Records that relate to RFC 1918-numbered resources within the 577 ; site hosting this AS112 node should not be hosted on this 578 ; nameserver. 580 The "db.dr-empty" file follows below. This is the source data used 581 to populate the EMPTY.AS112.ARPA zone that supports DNAME Redirection 582 AS112 service. Note that the RNAME specified in the SOA record 583 corresponds to noc@dns.icann.org, a suitable email address for 584 technical queries about this zone. 586 ; db.dr-empty 587 ; 588 ; Empty zone for Direct Delegation AS112 service. 589 ; 590 $TTL 1W 591 @ IN SOA blackhole.as112.arpa. noc.dns.icann.org. ( 592 1 ; serial number 593 1W ; refresh 594 1M ; retry 595 1W ; expire 596 1W ) ; negative caching TTL 597 ; 598 NS blackhole.as112.arpa. 599 ; 600 ; There should be no other resource records included in this zone. 601 ; 602 ; Records that relate to RFC 1918-numbered resources within the 603 ; site hosting this AS112 node should not be hosted on this 604 ; nameserver. 606 The "db.hostname.as112.net" and "db.hostname.as112.arpa" files 607 follow, below. These zones contain various resource records that 608 provide operational data to users for troubleshooting or measurement 609 purposes; the data should be edited to suit local circumstances. 610 Note that the responses to the queries "HOSTNAME.AS112.NET IN TXT" 611 and "HOSTNAME.AS112.ARPA IN TXT" should fit within a 512 octet DNS/ 612 UDP datagram: i.e., it should be available over UDP transport without 613 requiring EDNS0 support by the client. 615 The optional LOC record [RFC1876] included in each zone apex provides 616 information about the geospatial location of the node. 618 ; db.hostname.as112.net 619 ; 620 $TTL 1W 621 @ SOA server.example.net. admin.example.net. ( 622 1 ; serial number 623 1W ; refresh 624 1M ; retry 625 1W ; expire 626 1W ) ; negative caching TTL 627 ; 628 NS blackhole-1.iana.org. 629 NS blackhole-2.iana.org. 630 ; 631 TXT "Name of Facility or similar" "City, Country" 632 TXT "See http://www.as112.net/ for more information." 633 TXT "Unique IP: 203.0.113.1." 634 ; 635 LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m 637 ; db.hostname.as112.arpa 638 ; 639 $TTL 1W 640 @ SOA server.example.net. admin.example.net. ( 641 1 ; serial number 642 1W ; refresh 643 1M ; retry 644 1W ; expire 645 1W ) ; negative caching TTL 646 ; 647 NS blackhole.as112.arpa. 648 ; 649 TXT "Name of Facility or similar" "City, Country" 650 TXT "See http://www.as112.net/ for more information." 651 ; 652 LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m 654 4.6. Testing a Newly Installed Node 656 The BIND9 tool "dig" can be used to retrieve the TXT resource records 657 associated with the names "HOSTNAME.AS112.NET" and 658 "HOSTNAME.AS112.ARPA", directed at one of the AS112 anycast 659 nameserver addresses. Continuing the example from above, the 660 response received should indicate the identity of the AS112 node that 661 responded to the query. See Section 4.5 for more details about the 662 resource records associated with "HOSTNAME.AS112.NET". 664 % dig @prisoner.iana.org hostname.as112.net txt +short +norec 665 "Name of Facility or similar" "City, Country" 666 "See http://www.as112.net/ for more information." 667 % 669 If the response received indicates a different node is being used, 670 then there is probably a routing problem to solve. If there is no 671 response received at all, there might be a host or nameserver 672 problem. Judicious use of tools such as traceroute and consultation 673 of BGP looking glasses might be useful in troubleshooting. 675 Note that an appropriate set of tests for a new server will include 676 queries sent from many different places within the expected service 677 area of the node, using both UDP and TCP transport, and exercising 678 all three AS112 anycast nameserver addresses. 680 5. Operations 682 5.1. Monitoring 684 AS112 nodes should be monitored to ensure they are functioning 685 correctly, just as with any other production service. An AS112 node 686 that stops answering queries correctly can cause failures and 687 timeouts in unexpected places and can lead to failures in dependent 688 systems that can be difficult to troubleshoot. 690 5.2. Downtime 692 An AS112 node that needs to go off-line (e.g., for planned 693 maintenance or as part of the diagnosis of some problem) should stop 694 advertising the AS112 service prefixes to its BGP peers. This can be 695 done by shutting down the routing software on the node altogether or 696 by causing the routing system to withdraw the route. 698 Withdrawing the service prefixes is important in order to avoid 699 blackholing query traffic in the event that the DNS software on the 700 node is not functioning normally. 702 5.3. Statistics and Measurement 704 Use of the AS112 node should be measured in order to track long-term 705 trends, identify anomalous conditions, and ensure that the 706 configuration of the AS112 node is sufficient to handle the query 707 load. 709 Examples of free monitoring tools that might be useful to operators 710 of AS112 nodes include: 712 o bindgraph [3] 714 o dnstop [4] 716 o DSC [5] 718 Operators of AS112 nodes should also consider participating in 719 collection events as part of a larger, co-ordinated effort to gather 720 important baselines. One example of such an effort is Day-in-the- 721 Life [6] coordinated by the DNS-OARC [7]. 723 6. Communications 725 It is good operational practice to notify the community of users that 726 may fall within the reach of a new AS112 node before it is installed. 727 At Internet Exchanges, local mailing lists usually exist to 728 facilitate such announcements. 730 For nodes that are intended to be globally reachable, coordination 731 with other AS112 operators is especially recommended. The mailing 732 list [8] is operated for this purpose. 734 Information pertinent to AS112 operations is maintained at [9]. 736 Information about an AS112 node should also be published within the 737 DNS, within the "HOSTNAME.AS112.NET" and "HOSTNAME.AS112.ARPA" zones. 738 See Section 4.5 for more details. 740 AS112 operators should also be aware of the measures described in 741 [RFC6305] and direct site administrators appropriately. 743 7. On the Future of AS112 Nodes 745 It is recommended practice for the operators of recursive nameservers 746 to answer queries for zones served by AS112 nodes locally, such that 747 queries never have an opportunity to reach AS112 servers [RFC6303]. 748 Operational experience with AS112 nodes does not currently indicate 749 an observable trend towards compliance with those recommendations, 750 however. 752 It is expected that some DNS software vendors will include default 753 configuration that will implement measures such as those described in 754 [RFC6303]. If such software is widely deployed, it is reasonable to 755 assume that the query load received by AS112 nodes will decrease; 756 however, it is safe to assume that the query load will not decrease 757 to zero, and consequently that AS112 nodes will continue to provide a 758 useful service for the foreseeable future. 760 The use of DNAME Redirection to provide AS112 service is new, and 761 hence is informed by minimal operational experience. The use of 762 DNAME means that queries for many source zones could be redirected to 763 AS112 infrastructure with no real opportunity for coordination. 765 If the DNAME Redirection approach is successful, and in the absence 766 of any operational concerns, the community might well recommend the 767 retirement of the original Direct Delegation AS112 service. This 768 document makes no such recommendation, however. 770 8. IANA Considerations 772 8.1. General 774 The nameservers associated with Direct Delegation AS112 service are 775 all named under the domain IANA.ORG (see Section 3.3). However, the 776 anycast infrastructure itself is operated by a loosely-coordinated, 777 diverse mix of organisations across the Internet, and is not an IANA 778 function. 780 The autonomous system number 112, the IPv4 prefix 192.175.48.0/24 and 781 the IPv6 prefix 2620:4f:8000::/48 were assigned by ARIN. 783 The IPv4 prefix TBA-prefix-v4 and the IPv6 prefix TBA-prefix-v6, used 784 for DNAME Redirection AS112 service, were assigned by the IANA 785 [I-D.ietf-dnsop-as112-dname]. 787 The three nameservers BLACKHOLE-1.IANA.ORG, BLACKHOLE-2.IANA.ORG and 788 PRISONER.IANA.ORG are also reachable over IPv6, as described in 789 Section 3.3. Following a substantial period of pre-production 790 testing by AS112 operators, the IANA is directed to add AAAA RRSets 791 to those owner names in Section 8.2.1, to allow the servers to 792 receive queries and generate responses over IPv6 transport. 794 8.2. IANA Actions 796 8.2.1. IPv6 Transport for Direct Delegation AS112 Servers 798 The IANA is directed to add the following AAAA resource records for 799 the three Direct Delegation AS112 nameservers named under IANA.ORG: 801 +----------------------+------------------+ 802 | Owner Name | AAAA RDATA | 803 +----------------------+------------------+ 804 | PRISONER.IANA.ORG | 2620:4f:8000::1 | 805 | | | 806 | BLACKHOLE-1.IANA.ORG | 2620:4f:8000::6 | 807 | | | 808 | BLACKHOLE-2.IANA.ORG | 2620:4f:8000::42 | 809 +----------------------+------------------+ 811 8.2.2. Registration in the Special-Purpose AS Numbers Registry 813 The IANA is directed to add AS112 to the "Special-Purpose AS Numbers" 814 registry specified in [RFC7249] as follows: 816 AS Numbers: 112 818 Reason for Reservation: Used by the AS112 project to sink 819 misdirected DNS queries; see [THIS DOCUMENT] 821 8.2.3. Registration in the IANA IPv4 Special-Purpose Address Registry 823 The IANA is directed to add 192.175.48.0/24 to the "IANA IPv4 824 Special-Purpose Address Registry" specified in [RFC6890] as follows: 826 Address Block: 192.175.48.0/24 828 Name: Direct Delegation AS112 Service 830 RFC: [THIS DOCUMENT] 832 Allocation Date: 1996-01-05 834 Termination Date: N/A 836 Source: True 838 Destination: True 840 Forwardable: True 841 Global: True 843 Reserved-by-Protocol: False 845 8.2.4. Registration in the IANA IPv6 Special-Purpose Address Registry 847 The IANA is directed to add 2620:4f:8000::/48 to the "IANA IPv6 848 Special-Purpose Address Registry" specified in [RFC6890] as follows: 850 Address Block: 2620:4f:8000::/48 852 Name: Direct Delegation AS112 Service 854 RFC: [THIS DOCUMENT] 856 Allocation Date: 2011-05-31 858 Termination Date: N/A 860 Source: True 862 Destination: True 864 Forwardable: True 866 Global: True 868 Reserved-by-Protocol: False 870 9. Security Considerations 872 Hosts should never normally send queries to AS112 servers; queries 873 relating to private-use addresses should be answered locally within a 874 site. Hosts that send queries to AS112 servers may well leak 875 information relating to private infrastructure to the public network, 876 and this could present a security risk. Additionally, AS112 877 operators may log this information making it further subject to 878 whatever security and privacy risks that might entail. These risks 879 are orthogonal to the presence or absence of authoritative servers 880 for these zones in the public DNS infrastructure, however. 882 Queries that are answered by AS112 servers are usually unintentional; 883 it follows that the responses from AS112 servers are usually 884 unexpected. Unexpected inbound traffic can trigger intrusion 885 detection systems or alerts by firewalls. Operators of AS112 servers 886 should be prepared to be contacted by operators of remote 887 infrastructure who believe their security has been violated. Advice 888 to those who mistakenly believe that responses from AS112 nodes 889 constitute an attack on their infrastructure can be found in 890 [RFC6305]. 892 The deployment of AS112 nodes is very loosely coordinated compared to 893 other services distributed using anycast. The malicious compromise 894 of an AS112 node and subversion of the data served by the node are 895 hence more difficult to detect due to the lack of central management. 896 Since it is conceivable that changing the responses to queries 897 received by AS112 nodes might influence the behaviour of the hosts 898 sending the queries, such a compromise might be used as an attack 899 vector against private infrastructure. 901 Operators of AS112 should take appropriate measures to ensure that 902 AS112 nodes are appropriately protected from compromise, such as 903 would normally be employed for production nameserver or network 904 infrastructure. The guidance provided for root nameservers in 905 [RFC2870] may be instructive. 907 The zones hosted by AS112 servers are not signed with DNSSEC 908 [RFC4033]. Given the distributed and loosely coordinated structure 909 of the AS112 service, the zones concerned could only be signed if the 910 private key material used was effectively public, obviating any 911 security benefit resulting from the use of those keys. 913 10. Acknowledgements 915 This document benefited from review and suggestions from Leo Vegoda 916 and Pearl Liang. 918 The authors wish to acknowledge the assistance of Bill Manning, John 919 Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank 920 Habicht, Chris Thompson, Peter Losher, Peter Koch, Alfred Hoenes, S. 921 Moonesamy, Mehmet Akcin and Aleksi Suhonen in the preparation of 922 [RFC6304], which this document supercedes. 924 11. References 926 11.1. Normative References 928 [I-D.ietf-dnsop-as112-dname] 929 Abley, J., Dickson, B., Kumari, W., and G. Michaelson, 930 "AS112 Redirection using DNAME", draft-ietf-dnsop- 931 as112-dname-03 (work in progress), March 2014. 933 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 934 STD 13, RFC 1034, November 1987. 936 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 937 E. Lear, "Address Allocation for Private Internets", BCP 938 5, RFC 1918, February 1996. 940 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root 941 Name Server Operational Requirements", BCP 40, RFC 2870, 942 June 2000. 944 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 945 Rose, "DNS Security Introduction and Requirements", RFC 946 4033, March 2005. 948 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 949 Protocol 4 (BGP-4)", RFC 4271, January 2006. 951 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 952 Services", BCP 126, RFC 4786, December 2006. 954 11.2. Informative References 956 [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A 957 Means for Expressing Location Information in the Domain 958 Name System", RFC 1876, January 1996. 960 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 961 Reverse Zones", BCP 155, RFC 5855, May 2010. 963 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 964 6303, July 2011. 966 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 967 6304, July 2011. 969 [RFC6305] Abley, J. and W. Maton, "I'm Being Attacked by 970 PRISONER.IANA.ORG!", RFC 6305, July 2011. 972 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 973 DNS", RFC 6672, June 2012. 975 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 976 "Special-Purpose IP Address Registries", BCP 153, RFC 977 6890, April 2013. 979 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May 980 2014. 982 11.3. URIs 984 [1] http://www.quagga.net/ 986 [2] http://www.isc.org/software/BIND/ 988 [3] http://www.linux.it/~md/software/ 990 [4] http://dns.measurement-factory.com/tools/dnstop/ 992 [5] http://dns.measurement-factory.com/tools/dsc/ 994 [6] https://www.dns-oarc.net/oarc/data/ditl/ 996 [7] https://www.dns-oarc.net/ 998 [8] mailto:as112-ops@lists.dns-oarc.net 1000 [9] http://www.as112.net/ 1002 Appendix A. A Brief History of AS112 1004 Widespread use of the private address blocks listed in [RFC1918] 1005 followed that document's publication in 1996. At that time the IN- 1006 ADDR.ARPA zone was served by root servers. 1008 The idea of off-loading IN-ADDR.ARPA queries relating to [RFC1918] 1009 addresses from the root nameservers was first proposed by Bill 1010 Manning and John Brown. 1012 The use of anycast for distributing authoritative DNS service for 1013 [RFC1918] IN-ADDR.ARPA zones was subsequently proposed at a private 1014 meeting of root server operators. 1016 ARIN provided an IPv4 prefix for the anycast service and also the 1017 autonomous system number 112 for use in originating that prefix. 1018 This assignment gave the project its name. 1020 In 2002, the first AS112 anycast nodes were deployed. 1022 In 2011, the IN-ADDR.ARPA zone was redelegated from the root servers 1023 to a new set of servers operated independently by AfriNIC, APNIC, 1024 ARIN, ICANN, LACNIC, and the RIPE NCC and named according to 1025 [RFC5855]. 1027 [RFC6304], the precursor to this document, was published in July 1028 2011. 1030 The use of anycast nameservers in the AS112 project contributed to 1031 the operational experience of anycast DNS services, and it can be 1032 seen as a precursor to the anycast distribution of other 1033 authoritative DNS servers in subsequent years (e.g., various root 1034 servers). 1036 Appendix B. Changes Since RFC 6304 1038 A number of changes and enhancements to the AS112 service has been 1039 introduced since the publication of [RFC6304]. 1041 o The addition of IPv6 transport. 1043 o The extension of the AS112 service to include the ability to have 1044 additional zones delegated for sinking or removed using the DNAME 1045 resource record. 1047 o Requisite changes to the guidance regarding the configuration of 1048 current and future AS112 nodes. 1050 o Further clarification about the leakage of information in the 1051 Security Considerations section. 1053 o A direction to the IANA to register the AS112 Project's prefixes 1054 in the IANA Special-Purpose Address Registries. 1056 Appendix C. Revision History and Venue 1058 A suitable venue for discussion of this document is the dnsop working 1059 group. Private comments may also be directed at the authors. 1061 This section (and sub-sections) should be removed prior to 1062 publication. 1064 C.1. draft-jabley-dnsop-rfc6304bis-00 1066 Initial revision of [RFC6304] intended to provide guidance consistent 1067 with [I-D.ietf-dnsop-as112-dname]. 1069 C.2. draft-ietf-dnsop-rfc6304bis-00 1071 Change of filename following working group adoption. 1073 C.3. draft-ietf-dnsop-rfc6304bis-01 1075 Correct "Obsoletes" header in document metadata from "RFC6304" to 1076 "6304" as requested by Tim Wicinski. 1078 C.4. draft-ietf-dnsop-rfc6304bis-02 1080 Add IPv6 details for Direct Delegation AS112 service, including IANA 1081 considerations to add AAAA RRs to PRISONER.IANA.ORG and friends. 1083 Add IANA considerations that will add AS112 to the "Special-Purpose 1084 AS Numbers" registry, as created in [RFC7249]. 1086 Merge in some AUTH48 changes from RFC6304 that had been overlooked. 1088 C.5. draft-ietf-dnsop-rfc6304bis-03 1090 Change reference from RFC 5735 to RFC 6890. 1092 C.6. draft-ietf-dnsop-rfc6304bis-04 1094 Add change section for -03 that was previously overlooked. 1096 Register IPv4 netblock in IANA special-use registry. 1098 Register IPv6 netblock in IANA special-use registry. 1100 Modify registration data for AS112 in corresponding special-use 1101 registry. 1103 Add shout-out to Pearl and Leo. 1105 C.7. draft-ietf-dnsop-rfc6304bis-05 1107 As per IESG review and a replay of the same comment made by Pete 1108 Resnick of the review of the draft of RFC 6304, switch from 1109 Informational to Best Current Practice. 1111 Amend the abstract slightly to shorten it and re-state second-last 1112 paragraph as if RFC 6304 neever existed. 1114 Amend AS112 DNS Service section slightly to remove references to RFC 1115 6304 and make this a little more standalone. 1117 Add a paragraph about logging. 1119 Expand the first paragraph in the Security Considerations section to 1120 include a word on the logging of such leaked information. 1122 Add mention about further measurement and analysis contribution 1123 through the DNS-OARC. 1125 Add another reference to RFC 6305 in Communication section. 1127 Add some more missing changes suggested during RFC 6304 AUTH48 phase. 1129 Re-sync some more language with RFC 6304 after another edit round 1130 post-AUTH48 that was missing from the current draft. 1132 Expand the TXT record return to include info about the unique IP of 1133 the AS112 node. 1135 Add shout-out to Aleksi Suhonen. 1137 C.8. draft-ietf-dnsop-rfc6304bis-06 1139 As per WG Chairs, switch from Best Current Practice to Informational. 1141 Authors' Addresses 1143 Joe Abley 1144 Dyn, Inc. 1145 470 Moore Street 1146 London, ON N6C 2C2 1147 Canada 1149 Phone: +1 519 670 9327 1150 Email: jabley@dyn.com 1152 William F. Maton Sotomayor 1153 Ottawa Internet Exchange 1154 Constitution Square 1155 1400-340 Albert Street 1156 Ottawa, ON K1R 0A5 1157 Canada 1159 Email: wmaton@ottix.net