idnits 2.17.1 draft-jabley-dnsop-rfc6304bis-00.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 27 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document obsoletes RFC6304, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3726 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-as112-dname-00 ** Obsolete normative reference: RFC 2870 (Obsoleted by RFC 7720) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 6304 (Obsoleted by RFC 7534) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 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: RFC6304 (if approved) W. Maton 5 Intended status: Informational DNS-OARC 6 Expires: August 17, 2014 February 13, 2014 8 AS112 Nameserver Operations 9 draft-jabley-dnsop-rfc6304bis-00 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 August 17, 2014. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 5 77 2.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 2.1.1. Direct Delegation . . . . . . . . . . . . . . . . . . 5 79 2.1.2. DNAME Redirection . . . . . . . . . . . . . . . . . . 5 80 2.2. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 2.3. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 6 82 3. Installation of a New Node . . . . . . . . . . . . . . . . . . 7 83 3.1. Useful Background Knowledge . . . . . . . . . . . . . . . 7 84 3.2. Topological Location . . . . . . . . . . . . . . . . . . . 7 85 3.3. Operating System and Host Considerations . . . . . . . . . 7 86 3.4. Routing Software . . . . . . . . . . . . . . . . . . . . . 8 87 3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 10 88 3.6. Testing a Newly-Installed Node . . . . . . . . . . . . . . 14 89 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 16 91 4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 16 93 5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 17 94 6. On the Future of AS112 Nodes . . . . . . . . . . . . . . . . . 18 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 101 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 25 102 Appendix B. Revision History and Venue . . . . . . . . . . . . . 26 103 B.1. draft-jabley-dnsop-rfc6304bis-00 . . . . . . . . . . . . . 26 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 106 1. Introduction 108 Many sites connected to the Internet make use of IPv4 addresses that 109 are not globally unique. Examples are the addresses designated in 110 [RFC1918] for private use within individual sites. 112 Devices in such environments may occasionally originate Domain Name 113 System (DNS) [RFC1034] queries (so-called "reverse lookups") 114 corresponding to those private-use addresses. Since the addresses 115 concerned have only local significance, it is good practice for site 116 administrators to ensure that such queries are answered locally 117 [RFC6303]. However, it is not uncommon for such queries to follow 118 the normal delegation path in the public DNS instead of being 119 answered within the site. 121 It is not possible for public DNS servers to give useful answers to 122 such queries. In addition, due to the wide deployment of private-use 123 addresses and the continuing growth of the Internet, the volume of 124 such queries is large and growing. The AS112 project aims to provide 125 a distributed sink for such queries in order to reduce the load on 126 the IN-ADDR.ARPA authoritative servers [RFC5855]. 128 The AS112 project encompasses a loosely coordinated collection of 129 independently operated name servers. Each name server functions as a 130 single node in an AS112 anycast cloud [RFC4786], and is configured to 131 answer authoritatively for a particular set of nominated zones. 133 The AS112 project is named after the Autonomous System Number (ASN) 134 that was assigned to it (see Appendix A). 136 2. AS112 DNS Service 138 2.1. Approach 140 2.1.1. Direct Delegation 142 [RFC6304] describes an approach whereby zones whose traffic should be 143 directed towards an AS112 sink should be directly delegated to AS112 144 name servers. Correspondingly, each AS112 node is manually 145 configured to answer appropriately for those zones. 147 The guidance in this document preserves this capability for the zones 148 that were originally delegated in this fashion. AS112 nodes that 149 were implemented in accordance with the guidance in [RFC6304] will 150 continue to provide service for those zones. 152 2.1.2. DNAME Redirection 154 [I-D.ietf-dnsop-as112-dname] describes a different approach whereby 155 queries towards specific zones are redirected to an empty zone also 156 hosted on AS112 servers, using DNAME [RFC6672]. 158 The guidance in this document introduces this capability, allowing 159 any zone administrator to sink query traffic in AS112 infrastructure 160 without requiring changes to any AS112 node. 162 2.2. Zones 164 To support Direct Delegation AS112 service, AS112 name servers answer 165 authoritatively for the following zones, corresponding to [RFC1918] 166 private-use netblocks: 168 o 10.IN-ADDR.ARPA 170 o 16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ..., 31.172.IN-ADDR.ARPA 172 o 168.192.IN-ADDR.ARPA 174 and the following zone, corresponding to the "link local" netblock 175 169.254.0.0/16 listed in [RFC5735]: 177 o 254.169.IN-ADDR.ARPA 179 To support DNAME Redirection AS112 service, AS112 name servers answer 180 authoritatively for the following zone, as specified in 181 [I-D.ietf-dnsop-as112-dname]: 183 o EMPTY.AS112.ARPA 185 To aid identification of AS112 anycast nodes, each node also answers 186 authoritatively for the following zones: 188 o HOSTNAME.AS112.NET 190 o HOSTNAME.AS112.ARPA 192 See Section 3.5 for the recommended contents of all these zones. 194 2.3. Nameservers 196 To support Direct Delegation AS112 service, the relevant zones listed 197 in Section 2.2 are delegated to the two name servers BLACKHOLE- 198 1.IANA.ORG (192.175.48.6) and BLACKHOLE-2.IANA.ORG (192.175.48.42). 200 Additionally, the server PRISONER.IANA.ORG (192.175.48.1) is listed 201 in the MNAME field of the SOA records of the IN-ADDR.ARPA zones 202 served by AS112 name servers. PRISONER.IANA.ORG receives mainly 203 dynamic update queries. 205 The addresses of all these name servers are covered by the single 206 IPv4 prefix 192.175.48.0/24. 208 To support DNAME Redirection AS112 service, the single zone 209 EMPTY.AS112.ARPA is delegated to the single name server 210 BLACKHOLE.AS112.ARPA (addresses TBA). The addresses of that name 211 server are covered by the single IPv4 prefix TBA, and the single IPv6 212 prefix TBA. 214 3. Installation of a New Node 216 3.1. Useful Background Knowledge 218 Installation of an AS112 node is relatively straightforward. 219 However, experience in the following general areas may prove useful: 221 o inter-domain routing with BGP [RFC4271]; 223 o DNS authoritative server operations; 225 o anycast [RFC4786] distribution of DNS services. 227 3.2. Topological Location 229 AS112 nodes may be located anywhere on the Internet. For nodes that 230 are intended to provide a public service to the Internet community 231 (as opposed to private use), it may well be advantageous to choose a 232 location that is easily (and cheaply) reachable by multiple 233 providers, such as an Internet exchange point. 235 AS112 nodes may advertise their service prefix to BGP peers for local 236 use (analogous to a conventional peering relationship between two 237 providers) or for global use (analogous to a customer relationship 238 with one or more providers). 240 It is good operational practice to notify the community of users that 241 may fall within the reach of a new AS112 node before it is installed. 242 At an Internet Exchange, local mailing lists usually exist to 243 facilitate such announcements. For nodes that are intended to be 244 globally reachable, coordination with other AS112 operators is highly 245 recommended. See also Section 5. 247 3.3. Operating System and Host Considerations 249 Examples in this document are based on UNIX and UNIX-like operating 250 systems, but other operating systems exist which are suitable for use 251 in construction of an AS112 node. 253 The chosen platform should include support for either cloned loopback 254 interfaces, or the capability to bind multiple addresses to a single 255 loopback interface. The addresses of the name servers listed in 256 Section 2.3 will be configured on these interfaces in order that the 257 DNS software can respond to queries properly. 259 A host that is configured to act as an AS112 anycast node should be 260 dedicated to that purpose, and should not be used to simultaneously 261 provide other services. This guidance is provided due to the 262 unpredictable (and occasionally high) traffic levels that AS112 nodes 263 have been seen to attract. 265 System startup scripts should be arranged such that the various 266 AS112-related components start automatically following a system 267 reboot. The order in which interfaces are configured and software 268 components started should be arranged such that routing software 269 startup follows DNS software startup, and DNS software startup 270 follows loopback interface configuration. 272 Wrapper scripts or other arrangements should be employed to ensure 273 that the anycast service prefix for AS112 is not advertised while 274 either the anycast addresses are not configured, or while the DNS 275 software is not running. 277 3.4. Routing Software 279 AS112 nodes signal the availability of AS112 name servers to the 280 Internet using BGP [RFC4271]: each AS112 node is a BGP speaker, and 281 announces the prefix 192.175.48.0/24 to the Internet with origin AS 282 112 (see also Section 2.3). 284 The examples in this document are based on the Quagga Routing 285 Suite [1] running on Linux, but other software packages exist which 286 also provide suitable BGP support for AS112 nodes. 288 The "bgpd.conf" file is used by Quagga's bgpd daemon, which provides 289 BGP protocol support. The router id in this example is 203.0.113.1; 290 the AS112 node peers with external peers 192.0.2.1 and 192.0.2.2. 291 Note the local AS number 112, and the origination of the prefix 292 192.175.48.0/24 to support Direct Delegation AS112 service; the IPv4 293 prefix TBA and the IPv6 prefix TBA support DNAME Redirection. 295 ! bgpd.conf 296 ! 297 hostname as112-bgpd 298 password 299 enable password 300 ! 301 ! Note that all AS112 nodes use the local Autonomous System 302 ! Number 112, and originate the IPv4 prefixes 192.175.48.0/24 303 ! and TBA and the IPv6 prefix TBA. 304 ! 305 ! All other addresses shown below are illustrative, and 306 ! actual numbers will depend on local circumstances. 307 ! 308 ! IPv4-only or IPv6-only AS112 nodes should omit advertisements 309 ! for address families they do not support. 310 ! 311 router bgp 112 312 bgp router-id 203.0.113.1 313 neighbor 192.0.2.1 remote-as 64496 314 neighbor 192.0.2.1 next-hop-self 315 neighbor 192.0.2.2 remote-as 64497 316 neighbor 192.0.2.2 next-hop-self 317 ! 318 address-family ipv4 unicast 319 network 192.175.48.0/24 320 network TBA 321 ! 322 address-family ipv6 unicast 323 network TBA 325 The "zebra.conf" file is required to provide integration between 326 protocol daemons (bgpd, in this case) and the kernel. 328 ! zebra.conf 329 ! 330 hostname as112 331 password 332 enable password 333 ! 334 interface lo 335 ! 336 interface eth0 337 ! 339 3.5. DNS Software 341 Although the queries received by AS112 nodes are definitively 342 misdirected, it is important that they be answered in a manner that 343 is accurate and consistent. For this reason AS112 nodes operate as 344 fully-functional and standards-compliant DNS authoritative servers 345 [RFC1034], and hence require appropriate DNS software. 347 Examples in this document are based on ISC BIND9 [2], but other DNS 348 software exists which is suitable for use in construction of an AS112 349 node. 351 The following is a sample BIND9 "named.conf" file for a dedicated 352 AS112 server. Note that the name server is configured to act as an 353 authoritative-only server (i.e. recursion is disabled). The name 354 server is also configured to listen on the various AS112 anycast name 355 server addresses, as well as its local addresses. 357 // named.conf 359 // global options 361 options { 362 listen-on { 363 127.0.0.1; // localhost 365 // the following address is node-dependent, and should be set to 366 // something appropriate for the new AS112 node 368 203.0.113.1; // local address (globally-unique, unicast) 370 // the following addresses are used to support Direct Delegation 371 // AS112 service, and are the same for all AS112 nodes 373 192.175.48.1; // prisoner.iana.org (anycast) 374 192.175.48.6; // blackhole-1.iana.org (anycast) 375 192.175.48.42; // blackhole-2.iana.org (anycast) 377 // the following address is used to support DNAME Redirection 378 // AS112 service, and is the same for all AS112 nodes 380 TBA; // blackhole.as112.arpa (anycast) 381 }; 383 listen-on-v6 { 384 ::1; // localhost 386 // the following address is used to support DNAME Redirection 387 // AS112 service, and is the same for all AS112 nodes 389 TBA; // blackhole.as112.arpa (anycast) 390 }; 392 directory "/var/named"; 393 recursion no; // authoritative-only server 394 query-source address *; 395 }; 397 // log queries, so that when people call us about unexpected 398 // answers to queries they didn't realise they had sent, we 399 // have something to talk about. Note that activating this 400 // has the potential to create high CPU load and consume 401 // enormous amounts of disk space. 403 logging { 404 channel "querylog" { 405 file "/var/log/query.log" versions 2 size 500m; 406 print-time yes; 407 }; 408 category queries { querylog; }; 409 }; 411 // Direct Delegation AS112 Service 413 // RFC 1918 415 zone "10.in-addr.arpa" { type master; file "db.dd-empty"; }; 416 zone "16.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 417 zone "17.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 418 zone "18.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 419 zone "19.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 420 zone "20.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 421 zone "21.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 422 zone "22.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 423 zone "23.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 424 zone "24.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 425 zone "25.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 426 zone "26.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 427 zone "27.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 428 zone "28.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 429 zone "29.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 430 zone "30.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 431 zone "31.172.in-addr.arpa" { type master; file "db.dd-empty"; }; 432 zone "168.192.in-addr.arpa" { type master; file "db.dd-empty"; }; 434 // RFC 5735 435 zone "254.169.in-addr.arpa" { type master; file "db.dd-empty"; }; 437 // DNAME Redirection AS112 Service 439 zone "empty.as112.arpa" { type master; file "db.dr-empty"; }; 441 // also answer authoritatively for the HOSTNAME.AS112.NET and 442 // HOSTNAME.AS112.ARPA zones, which contain data of operational 443 // relevance 445 zone "hostname.as112.net" { 446 type master; 447 file "db.hostname.as112.net"; 448 }; 450 zone "hostname.as112.arpa" { 451 type master; 452 file "db.hostname.as112.arpa"; 453 }; 455 The "db.dd-empty" file follows, below. This is the source data used 456 to populate all the IN-ADDR.ARPA zones listed in Section 2.2 that 457 support Direct Delegation AS112 service. Note that the RNAME 458 specified in the SOA record corresponds to 459 hostmaster@root-servers.org, a suitable e-mail address for technical 460 queries about these zones. 462 ; db.dd-empty 463 ; 464 ; Empty zone for Direct Delegation AS112 service. 465 ; 466 $TTL 1W 467 @ IN SOA prisoner.iana.org. hostmaster.root-servers.org. ( 468 1 ; serial number 469 1W ; refresh 470 1M ; retry 471 1W ; expire 472 1W ) ; negative caching TTL 473 ; 474 NS blackhole-1.iana.org. 475 NS blackhole-2.iana.org. 476 ; 477 ; There should be no other resource records included in this zone. 478 ; 479 ; Records that relate to RFC 1918-numbered resources within the 480 ; site hosting this AS112 node should not be hosted on this 481 ; name server. 483 The "db.dr-empty" file follows, below. This is the source data used 484 to populate the EMPTY.AS112.ARPA zone that supports DNAME Redirection 485 AS112 service. Note that the RNAME specified in the SOA record 486 corresponds to noc@dns.icann.org, a suitable e-mail address for 487 technical queries about this zone. 489 ; db.dr-empty 490 ; 491 ; Empty zone for Direct Delegation AS112 service. 492 ; 493 $TTL 1W 494 @ IN SOA blackhole.as112.arpa. noc.dns.icann.org. ( 495 1 ; serial number 496 1W ; refresh 497 1M ; retry 498 1W ; expire 499 1W ) ; negative caching TTL 500 ; 501 NS blackhole.as112.arpa. 502 ; 503 ; There should be no other resource records included in this zone. 504 ; 505 ; Records that relate to RFC 1918-numbered resources within the 506 ; site hosting this AS112 node should not be hosted on this 507 ; name server. 509 The "db.hostname.as112.net" and "db.hostname.as112.arpa" files 510 follow, below. These zones contain various resource records that 511 provide operational data to users for troubleshooting or measurement 512 purposes, and should be edited to suit local circumstances. Note 513 that the responses to the queries "HOSTNAME.AS112.NET IN TXT" and 514 "HOSTNAME.AS112.ARPA IN TXT" should fit within a 512 octet DNS/UDP 515 datagram: i.e. it should be available over UDP transport without 516 requiring EDNS0 support. 518 The optional LOC record [RFC1876] included in each zone apex provides 519 information about the geospatial location of the node. 521 ; db.hostname.as112.net 522 ; 523 $TTL 1W 524 @ SOA server.example.net. admin.example.net. ( 525 1 ; serial number 526 1W ; refresh 527 1M ; retry 528 1W ; expire 529 1W ) ; negative caching TTL 530 ; 531 NS blackhole-2.iana.org. 532 NS blackhole-1.iana.org. 533 ; 534 TXT "Name of Facility or similar" "City, Country" 535 TXT "See http://www.as112.net/ for more information." 536 ; 537 LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m 539 ; db.hostname.as112.arpa 540 ; 541 $TTL 1W 542 @ SOA server.example.net. admin.example.net. ( 543 1 ; serial number 544 1W ; refresh 545 1M ; retry 546 1W ; expire 547 1W ) ; negative caching TTL 548 ; 549 NS blackhole.as112.arpa. 550 ; 551 TXT "Name of Facility or similar" "City, Country" 552 TXT "See http://www.as112.net/ for more information." 553 ; 554 LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m 556 3.6. Testing a Newly-Installed Node 558 The BIND9 tool "dig" can be used to retrieve the TXT resource records 559 associated with the names "HOSTNAME.AS112.NET" and 560 "HOSTNAME.AS112.ARPA", directed at one of the AS112 anycast name 561 server addresses. Continuing the example from above, the response 562 received should indicate the identity of the AS112 node that 563 responded to the query. See Section 3.5 for more details about the 564 resource records associated with "HOSTNAME.AS112.NET". 566 % dig @prisoner.iana.org hostname.as112.net txt +short +norec 567 "Name of Facility or similar" "City, Country" 568 "See http://www.as112.net/ for more information." 569 % 571 If the response received indicates a different node is being used, 572 then there is probably a routing problem to solve. If there is no 573 response received at all, there might be host or name server problem. 574 Judicious use of tools such as traceroute, and consultation of BGP 575 looking glasses might be useful in troubleshooting. 577 Note that an appropriate set of tests for a new server will include 578 queries sent from many different places within the expected service 579 area of the node, using both UDP and TCP transport, and exercising 580 all three AS112 anycast name server addresses. 582 4. Operations 584 4.1. Monitoring 586 AS112 nodes should be monitored to ensure they are functioning 587 correctly, just as with any other production service. An AS112 node 588 that stops answering queries correctly can cause failures and 589 timeouts in unexpected places and can lead to failures in dependent 590 systems that can be difficult to troubleshoot. 592 4.2. Downtime 594 An AS112 node that needs to go off-line (e.g. for planned maintenance 595 or as part of the diagnosis of some problem) should stop advertising 596 the AS112 service prefix to its BGP peers. This can be done by 597 shutting down the routing software on the node altogether or by 598 causing the routing system to withdraw the route. 600 Withdrawing the service prefix is important in order to avoid 601 blackholing query traffic in the event that the DNS software on the 602 node is not functioning normally. 604 4.3. Statistics and Measurement 606 Use of the AS112 node should be measured in order to track long-term 607 trends, identify anomalous conditions, and to ensure that the 608 configuration of the AS112 node is sufficient to handle the query 609 load. 611 Examples of free monitoring tools that might be useful to operators 612 of AS112 nodes include: 614 o bindgraph [3] 616 o dnstop [4] 618 o DSC [5] 620 5. Communications 622 It is good operational practice to notify the community of users that 623 may fall within the reach of a new AS112 node before it is installed. 624 At Internet Exchanges, local mailing lists usually exist to 625 facilitate such announcements. 627 For nodes that are intended to be globally reachable, coordination 628 with other AS112 operators is especially recommended. The mailing 629 list is operated for this 630 purpose. 632 Information pertinent to AS112 operations is maintained at 633 . 635 Information about an AS112 node should also be published within the 636 DNS, within the "HOSTNAME.AS112.NET" and "HOSTNAME.AS112.ARPA" zones. 637 See Section 3.5 for more details. 639 6. On the Future of AS112 Nodes 641 It is recommended practice for the operators of recursive name 642 servers to answer queries for zones served by AS112 nodes locally, 643 such that queries never have an opportunity to reach AS112 servers 644 [RFC6303]. Operational experience with AS112 nodes does not 645 currently indicate an observable trend towards compliance with those 646 recommendations, however. 648 It is expected that some DNS software vendors will include default 649 configuration that will implement measures such as those described in 650 [RFC6303]. If such software is widely deployed, it is reasonable to 651 assume that the query load received by AS112 nodes will decrease; 652 however, it is safe to assume that the query load will not decrease 653 to zero, and consequently that AS112 nodes will continue to provide a 654 useful service for the foreseeable future. 656 The use of DNAME Redirection to provide AS112 service is new, and 657 hence is informed by minimal operational experience. The use of 658 DNAME means that queries for many source zones could be redirected to 659 AS112 infrastructure with no real opportunity for coordination. 661 If successful, and in the absence of operational concerns, the 662 community might well recommend the retirement of the original Direct 663 Delegation AS112 service, with equivalent service for the zones 664 concerned instead provided using DNAME Redirection. This document 665 makes no such recommendation, however. 667 7. IANA Considerations 669 The name servers associated with Direct Delegation AS112 service are 670 all named under the domain IANA.ORG (see Section 2.3). However, the 671 anycast infrastructure itself is operated by a loosely-coordinated, 672 diverse mix of organisations across the Internet, and is not an IANA 673 function. 675 The autonomous system number 112 and the IPv4 prefix 192.175.48.0/24 676 were assigned by ARIN. 678 The IPv4 prefix TBA and the IPv6 prefix TBA, used for DNAME 679 Redirection AS112 service, were assigned by the IANA 680 [I-D.ietf-dnsop-as112-dname]. 682 This document has no IANA actions. 684 8. Security Considerations 686 Hosts should never normally send queries to AS112 servers; queries 687 relating to private-use addresses should be answered locally within a 688 site. Hosts that send queries to AS112 servers may well leak 689 information relating to private infrastructure to the public network, 690 and this could present a security risk. This risk is orthogonal to 691 the presence or absence of authoritative servers for these zones in 692 the public DNS infrastructure, however. 694 Queries that are answered by AS112 servers are usually unintentional; 695 it follows that the responses from AS112 servers are usually 696 unexpected. Unexpected inbound traffic can trigger intrusion 697 detection systems or alerts by firewalls. Operators of AS112 servers 698 should be prepared to be contacted by operators of remote 699 infrastructure who believe their security has been violated. Advice 700 to those who mistakenly believe that responses from AS112 nodes 701 constitutes an attack on their infrastructure can be found in 702 [RFC6305]. 704 The deployment of AS112 nodes is very loosely coordinated compared to 705 other services distributed using anycast. The malicious compromise 706 of an AS112 node and subversion of the data served by the node is 707 hence more difficult to detect due to the lack of central management. 708 Since it is conceivable that changing the responses to queries 709 received by AS112 nodes might influence the behaviour of the hosts 710 sending the queries, such a compromise might be used as an attack 711 vector against private infrastructure. 713 Operators of AS112 should take appropriate measures to ensure that 714 AS112 nodes are appropriately protected from compromise, such as 715 would normally be employed for production name server or network 716 infrastructure. The guidance provided for root name servers in 717 [RFC2870] may be instructive. 719 The zones hosted by AS112 servers are not signed with DNSSEC 720 [RFC4033]. Given the distributed and loosely-coordinated structure 721 of the AS112 service, the zones concerned could only be signed if the 722 private key material used was effectively public, obviating any 723 security benefit resulting from the use of those keys. 725 9. Acknowledgements 727 The authors wish to acknowledge the assistance of Bill Manning, John 728 Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank 729 Habicht, Chris Thompson, Peter Losher, Peter Koch, Alfred Hoenes and 730 S. Moonesamy in the preparation of [RFC6304], which this document 731 supercedes. 733 The authors further acknowledge the assistance of YOUR NAME HERE in 734 the preparation of this document. 736 10. References 738 10.1. Normative References 740 [I-D.ietf-dnsop-as112-dname] 741 Abley, J., Dickson, B., Kumari, W., and G. Michaelson, 742 "AS112 Redirection using DNAME", 743 draft-ietf-dnsop-as112-dname-00 (work in progress), 744 November 2013. 746 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 747 STD 13, RFC 1034, November 1987. 749 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 750 E. Lear, "Address Allocation for Private Internets", 751 BCP 5, RFC 1918, February 1996. 753 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root 754 Name Server Operational Requirements", BCP 40, RFC 2870, 755 June 2000. 757 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 758 Rose, "DNS Security Introduction and Requirements", 759 RFC 4033, March 2005. 761 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 762 Protocol 4 (BGP-4)", RFC 4271, January 2006. 764 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 765 Services", BCP 126, RFC 4786, December 2006. 767 10.2. Informative References 769 [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A 770 Means for Expressing Location Information in the Domain 771 Name System", RFC 1876, January 1996. 773 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 774 RFC 5735, January 2010. 776 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6 777 Reverse Zones", BCP 155, RFC 5855, May 2010. 779 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 780 RFC 6303, July 2011. 782 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", 783 RFC 6304, July 2011. 785 [RFC6305] Abley, J. and W. Maton, "I'm Being Attacked by 786 PRISONER.IANA.ORG!", RFC 6305, July 2011. 788 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 789 DNS", RFC 6672, June 2012. 791 URIs 793 [1] 795 [2] 797 [3] 799 [4] 801 [5] 803 Appendix A. History 805 Widespread use of the private address blocks listed in [RFC1918] 806 followed that document's publication in 1996. At that time the IN- 807 ADDR.ARPA zone was served by root servers. 809 The idea of off-loading IN-ADDR.ARPA queries relating to [RFC1918] 810 addresses from the root name servers was first proposed by Bill 811 Manning and John Brown. 813 The use of anycast for distributing authoritative DNS service for 814 [RFC1918] IN-ADDR.ARPA zones was subsequently proposed at a private 815 meeting of root server operators. 817 ARIN provided an IPv4 prefix for the anycast service and also the 818 autonomous system number 112 for use in originating that prefix. 819 This assignment gave the project its name. 821 In 2002, the first AS112 anycast nodes were deployed. 823 In 2011, the IN-ADDR.ARPA zone was redelegated from the root servers 824 to a new set of servers operated independently by AfriNIC, APNIC, 825 ARIN, ICANN, LACNIC, and the RIPE NCC and named according to 826 [RFC5855]. 828 [RFC6304], the precursor to this document, was published in July 829 2011. 831 The use of anycast name servers in the AS112 project contributed to 832 the operational experience of anycast DNS services, and it can be 833 seen as a precursor to the anycast distribution of other 834 authoritative DNS servers in subsequent years (e.g., various root 835 servers). 837 Appendix B. Revision History and Venue 839 A suitable venue for discussion of this document is the dnsop working 840 group. Private comments may also be directed at the authors. 842 This section (and sub-sections) should be removed prior to 843 publication. 845 B.1. draft-jabley-dnsop-rfc6304bis-00 847 Initial revision of [RFC6304] intended to provide guidance consistent 848 with [I-D.ietf-dnsop-as112-dname]. 850 Authors' Addresses 852 Joe Abley 853 Dyn, Inc. 854 470 Moore Street 855 London, ON N6C 2C2 856 Canada 858 Phone: +1 519 670 9327 859 Email: jabley@dyn.com 861 William F. Maton Sotomayor 862 DNS Operations, Analysis and Research Centre 864 Email: wfms@dns-oarc.net