idnits 2.17.1
draft-ietf-dnsop-as112-ops-09.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 15 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?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document seems to contain a disclaimer for pre-RFC5378 work, and may
have content which was first submitted before 10 November 2008. The
disclaimer is necessary when there are original authors that you have
been unable to contact, or if some do not wish to grant the BCP78 rights
to the IETF Trust. If you are able to get all authors (current and
original) to grant those rights, you can and should remove the
disclaimer; otherwise, the disclaimer is needed and you can ignore this
comment. (See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (May 11, 2011) is 4727 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 2870 (Obsoleted by RFC 7720)
-- Obsolete informational reference (is this intentional?): RFC 5735
(Obsoleted by RFC 6890)
Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Abley
3 Internet-Draft ICANN
4 Intended status: Informational W. Maton
5 Expires: November 12, 2011 NRC-CNRC
6 May 11, 2011
8 AS112 Nameserver Operations
9 draft-ietf-dnsop-as112-ops-09
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 IN-ADDR.ARPA 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 Status of this Memo
38 This Internet-Draft is submitted in full conformance with the
39 provisions of BCP 78 and BCP 79.
41 Internet-Drafts are working documents of the Internet Engineering
42 Task Force (IETF). Note that other groups may also distribute
43 working documents as Internet-Drafts. The list of current Internet-
44 Drafts is at http://datatracker.ietf.org/drafts/current/.
46 Internet-Drafts are draft documents valid for a maximum of six months
47 and may be updated, replaced, or obsoleted by other documents at any
48 time. It is inappropriate to use Internet-Drafts as reference
49 material or to cite them other than as "work in progress."
51 This Internet-Draft will expire on November 12, 2011.
53 Copyright Notice
55 Copyright (c) 2011 IETF Trust and the persons identified as the
56 document authors. All rights reserved.
58 This document is subject to BCP 78 and the IETF Trust's Legal
59 Provisions Relating to IETF Documents
60 (http://trustee.ietf.org/license-info) in effect on the date of
61 publication of this document. Please review these documents
62 carefully, as they describe your rights and restrictions with respect
63 to this document. Code Components extracted from this document must
64 include Simplified BSD License text as described in Section 4.e of
65 the Trust Legal Provisions and are provided without warranty as
66 described in the Simplified BSD License.
68 This document may contain material from IETF Documents or IETF
69 Contributions published or made publicly available before November
70 10, 2008. The person(s) controlling the copyright in some of this
71 material may not have granted the IETF Trust the right to allow
72 modifications of such material outside the IETF Standards Process.
73 Without obtaining an adequate license from the person(s) controlling
74 the copyright in such materials, this document may not be modified
75 outside the IETF Standards Process, and derivative works of it may
76 not be created outside the IETF Standards Process, except to format
77 it for publication as an RFC or to translate it into languages other
78 than English.
80 Table of Contents
82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
83 2. AS112 DNS Service . . . . . . . . . . . . . . . . . . . . . . 5
84 2.1. Zones . . . . . . . . . . . . . . . . . . . . . . . . . . 5
85 2.2. Nameservers . . . . . . . . . . . . . . . . . . . . . . . 5
86 3. Installation of a New Node . . . . . . . . . . . . . . . . . . 6
87 3.1. Useful Background Knowledge . . . . . . . . . . . . . . . 6
88 3.2. Topological Location . . . . . . . . . . . . . . . . . . . 6
89 3.3. Operating System and Host Considerations . . . . . . . . . 6
90 3.4. Routing Software . . . . . . . . . . . . . . . . . . . . . 7
91 3.5. DNS Software . . . . . . . . . . . . . . . . . . . . . . . 8
92 3.6. Testing a Newly-Installed Node . . . . . . . . . . . . . . 12
93 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 13
94 4.1. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 13
95 4.2. Downtime . . . . . . . . . . . . . . . . . . . . . . . . . 13
96 4.3. Statistics and Measurement . . . . . . . . . . . . . . . . 13
97 5. Communications . . . . . . . . . . . . . . . . . . . . . . . . 14
98 6. On the Future of AS112 Nodes . . . . . . . . . . . . . . . . . 15
99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
101 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
104 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
105 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . . 21
106 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 22
107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
109 1. Introduction
111 Many sites connected to the Internet make use of IPv4 addresses that
112 are not globally unique. Examples are the addresses designated in
113 [RFC1918] for private use within individual sites.
115 Devices in such environments may occasionally originate Domain Name
116 System (DNS) [RFC1034] queries (so-called "reverse lookups")
117 corresponding to those private-use addresses. Since the addresses
118 concerned have only local significance, it is good practice for site
119 administrators to ensure that such queries are answered locally
120 [I-D.ietf-dnsop-default-local-zones]. However, it is not uncommon
121 for such queries to follow the normal delegation path in the public
122 DNS instead of being answered within the site.
124 It is not possible for public DNS servers to give useful answers to
125 such queries. In addition, due to the wide deployment of private-use
126 addresses and the continuing growth of the Internet, the volume of
127 such queries is large and growing. The AS112 project aims to provide
128 a distributed sink for such queries in order to reduce the load on
129 the IN-ADDR.ARPA authoritative servers [RFC5855].
131 The AS112 project encompasses a loosely coordinated collection of
132 independently operated nameservers. Each nameserver functions as a
133 single node in an AS112 anycast cloud [RFC4786], and is configured to
134 answer authoritatively for a particular set of nominated zones.
136 The AS112 project is named after the Autonomous System Number (ASN)
137 that was assigned to it.
139 2. AS112 DNS Service
141 2.1. Zones
143 AS112 nameservers answer authoritatively for the following zones,
144 corresponding to [RFC1918] private-use netblocks:
146 o 10.IN-ADDR.ARPA
148 o 16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ..., 31.172.IN-ADDR.ARPA
150 o 168.192.IN-ADDR.ARPA
152 and the following zone, corresponding to the "link local" netblock
153 169.254.0.0/16 listed in [RFC5735]:
155 o 254.169.IN-ADDR.ARPA
157 To aid identification of AS112 anycast nodes, each node also answers
158 authoritatively for the zone HOSTNAME.AS112.NET.
160 See Section 3.5 for the recommended contents of all these zones.
162 It is possible that other zones corresponding to private-use
163 infrastructure will be delegated to AS112 servers in the future. A
164 list of zones for which AS112 servers answer authoritatively is
165 maintained at .
167 2.2. Nameservers
169 The zones listed in Section 2.1 are delegated to the two nameservers
170 BLACKHOLE-1.IANA.ORG (192.175.48.6) and BLACKHOLE-2.IANA.ORG
171 (192.175.48.42).
173 Additionally, the server PRISONER.IANA.ORG (192.175.48.1) is listed
174 in the MNAME field of the SOA records of the IN-ADDR.ARPA zones
175 served by AS112 nameservers. PRISONER.IANA.ORG receives mainly
176 dynamic update queries.
178 The addresses of all these nameservers are covered by the single IPv4
179 prefix 192.175.48.0/24.
181 3. Installation of a New Node
183 3.1. Useful Background Knowledge
185 Installation of an AS112 node is relatively straightforward.
186 However, experience in the following general areas may prove useful:
188 o inter-domain routing with BGP [RFC4271];
190 o DNS authoritative server operations;
192 o anycast [RFC4786] distribution of DNS services.
194 3.2. Topological Location
196 AS112 nodes may be located anywhere on the Internet. For nodes that
197 are intended to provide a public service to the Internet community
198 (as opposed to private use), it may well be advantageous to choose a
199 location that is easily (and cheaply) reachable by multiple
200 providers, such as an Internet exchange point.
202 AS112 nodes may advertise their service prefix to BGP peers for local
203 use (analogous to a conventional peering relationship between two
204 providers) or for global use (analogous to a customer relationship
205 with one or more providers).
207 It is good operational practice to notify the community of users that
208 may fall within the reach of a new AS112 node before it is installed.
209 At an Internet Exchange, local mailing lists usually exist to
210 facilitate such announcements. For nodes that are intended to be
211 globally reachable, coordination with other AS112 operators is highly
212 recommended. See also Section 5.
214 3.3. Operating System and Host Considerations
216 Examples in this document are based on UNIX and UNIX-like operating
217 systems, but other operating systems exist which are suitable for use
218 in construction of an AS112 node.
220 The chosen platform should include support for either cloned loopback
221 interfaces, or the capability to bind multiple addresses to a single
222 loopback interface. The addresses of the nameservers listed in
223 Section 2.2 will be configured on these interfaces in order that the
224 DNS software can respond to queries properly.
226 A host that is configured to act as an AS112 anycast node should be
227 dedicated to that purpose, and should not be used to simultaneously
228 provide other services. This guidance is provided due to the
229 unpredictable (and occasionally high) traffic levels that AS112 nodes
230 have been seen to attract.
232 System startup scripts should be arranged such that the various
233 AS112-related components start automatically following a system
234 reboot. The order in which interfaces are configured and software
235 components started should be arranged such that routing software
236 startup follows DNS software startup, and DNS software startup
237 follows loopback interface configuration.
239 Wrapper scripts or other arrangements should be employed to ensure
240 that the anycast service prefix for AS112 is not advertised while
241 either the anycast addresses are not configured, or while the DNS
242 software is not running.
244 3.4. Routing Software
246 AS112 nodes signal the availability of AS112 nameservers to the
247 Internet using BGP [RFC4271]: each AS112 node is a BGP speaker, and
248 announces the prefix 192.175.48.0/24 to the Internet with origin AS
249 112 (see also Section 2.2).
251 The examples in this document are based on the Quagga Routing
252 Suite [1] running on Linux, but other software packages exist which
253 also provide suitable BGP support for AS112 nodes.
255 The "bgpd.conf" file is used by Quagga's bgpd daemon, which provides
256 BGP protocol support. The router id in this example is 203.0.113.1;
257 the AS112 node peers with external peers 192.0.2.1 and 192.0.2.2.
258 Note the local AS number 112, and the origination of the prefix
259 192.175.48.0/24.
261 ! bgpd.conf
262 !
263 hostname as112-bgpd
264 password
265 enable password
266 !
267 ! Note that all AS112 nodes use the local Autonomous System
268 ! Number 112, and originate the IPv4 prefix 192.175.48.0/24.
269 ! All other addresses shown below are illustrative, and
270 ! actual numbers will depend on local circumstances.
271 !
272 router bgp 112
273 bgp router-id 203.0.113.1
274 network 192.175.48.0
275 neighbor 192.0.2.1 remote-as 64496
276 neighbor 192.0.2.1 next-hop-self
277 neighbor 192.0.2.2 remote-as 64497
278 neighbor 192.0.2.2 next-hop-self
280 The "zebra.conf" file is required to provide integration between
281 protocol daemons (bgpd, in this case) and the kernel.
283 ! zebra.conf
284 !
285 hostname as112
286 password
287 enable password
288 !
289 interface lo
290 !
291 interface eth0
292 !
294 3.5. DNS Software
296 Although the queries received by AS112 nodes are definitively
297 misdirected, it is important that they be answered in a manner that
298 is accurate and consistent. For this reason AS112 nodes operate as
299 fully-functional and standards-compliant DNS authoritative servers
300 [RFC1034], and hence require DNS software.
302 Examples in this document are based on ISC BIND9 [2], but other DNS
303 software exists which is suitable for use in construction of an AS112
304 node.
306 The following is a sample BIND9 "named.conf" file for a dedicated
307 AS112 server. Note that the nameserver is configured to act as an
308 authoritative-only server (i.e. recursion is disabled). The
309 nameserver is also configured to listen on the various AS112 anycast
310 nameserver addresses, as well as its local addresses.
312 // named.conf
314 // global options
316 options {
317 listen-on {
318 127.0.0.1; // localhost
320 // the following address is node-dependent, and should be set to
321 // something appropriate for the new AS112 node
323 203.0.113.1; // local address (globally-unique, unicast)
325 // the following addresses correspond to AS112 addresses, and
326 // are the same for all AS112 nodes
328 192.175.48.1; // prisoner.iana.org (anycast)
329 192.175.48.6; // blackhole-1.iana.org (anycast)
330 192.175.48.42; // blackhole-2.iana.org (anycast)
331 };
332 directory "/var/named";
333 recursion no; // authoritative-only server
334 query-source address *;
335 };
337 // log queries, so that when people call us about unexpected
338 // answers to queries they didn't realise they had sent, we
339 // have something to talk about. Note that activating this
340 // has the potential to create high CPU load and consume
341 // enormous amounts of disk space.
343 logging {
344 channel "querylog" {
345 file "/var/log/query.log" versions 2 size 500m;
346 print-time yes;
347 };
348 category queries { querylog; };
349 };
351 // RFC 1918
353 zone "10.in-addr.arpa" { type master; file "db.empty"; };
354 zone "16.172.in-addr.arpa" { type master; file "db.empty"; };
355 zone "17.172.in-addr.arpa" { type master; file "db.empty"; };
356 zone "18.172.in-addr.arpa" { type master; file "db.empty"; };
357 zone "19.172.in-addr.arpa" { type master; file "db.empty"; };
358 zone "20.172.in-addr.arpa" { type master; file "db.empty"; };
359 zone "21.172.in-addr.arpa" { type master; file "db.empty"; };
360 zone "22.172.in-addr.arpa" { type master; file "db.empty"; };
361 zone "23.172.in-addr.arpa" { type master; file "db.empty"; };
362 zone "24.172.in-addr.arpa" { type master; file "db.empty"; };
363 zone "25.172.in-addr.arpa" { type master; file "db.empty"; };
364 zone "26.172.in-addr.arpa" { type master; file "db.empty"; };
365 zone "27.172.in-addr.arpa" { type master; file "db.empty"; };
366 zone "28.172.in-addr.arpa" { type master; file "db.empty"; };
367 zone "29.172.in-addr.arpa" { type master; file "db.empty"; };
368 zone "30.172.in-addr.arpa" { type master; file "db.empty"; };
369 zone "31.172.in-addr.arpa" { type master; file "db.empty"; };
370 zone "168.192.in-addr.arpa" { type master; file "db.empty"; };
372 // RFC 5735
374 zone "254.169.in-addr.arpa" { type master; file "db.empty"; };
376 // also answer authoritatively for the HOSTNAME.AS112.NET zone,
377 // which contains data of operational relevance
379 zone "hostname.as112.net" {
380 type master;
381 file "db.hostname.as112.net";
382 };
384 The "db.empty" file follows, below. This is the source data used to
385 populate all the IN-ADDR.ARPA zones listed in Section 2.1. Note that
386 the RNAME specified in the SOA record corresponds to
387 hostmaster@root-servers.org, a suitable e-mail address for receiving
388 technical queries about these zones.
390 ; db.empty
391 ;
392 ; Empty zone for AS112 server.
393 ;
394 $TTL 1W
395 @ IN SOA prisoner.iana.org. hostmaster.root-servers.org. (
396 1 ; serial number
397 1W ; refresh
398 1M ; retry
399 1W ; expire
400 1W ) ; negative caching TTL
401 ;
402 NS blackhole-1.iana.org.
403 NS blackhole-2.iana.org.
404 ;
405 ; There should be no other resource records included in this zone.
406 ;
407 ; Records that relate to RFC 1918-numbered resources within the
408 ; site hosting this AS112 node should not be hosted on this
409 ; nameserver.
411 The "db.hostname.as112.net" file follows, below. This zone contains
412 various resource records that provide operational data to users for
413 troubleshooting or measurement purposes, and should be edited to suit
414 local circumstances. Note that the response to the query
415 "HOSTNAME.AS112.NET IN TXT" should fit within a 512 octet DNS/UDP
416 datagram: i.e. it should be available over UDP transport without
417 requiring EDNS0 support.
419 The optional LOC record [RFC1876] included in the zone apex provides
420 information about the geospatial location of the node.
422 ; db.hostname.as112.net
423 ;
424 $TTL 1W
425 @ SOA server.example.net. admin.example.net. (
426 1 ; serial number
427 1W ; refresh
428 1M ; retry
429 1W ; expire
430 1W ) ; negative caching TTL
431 ;
432 NS blackhole-2.iana.org.
433 NS blackhole-1.iana.org.
434 ;
435 TXT "Name of Facility or similar" "City, Country"
436 TXT "See http://www.as112.net/ for more information."
437 ;
438 LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m
440 3.6. Testing a Newly-Installed Node
442 The BIND9 tool "dig" can be used to retrieve the TXT resource records
443 associated with the domain "HOSTNAME.AS112.NET", directed at one of
444 the AS112 anycast nameserver addresses. Continuing the example from
445 above, the response received should indicate the identity of the
446 AS112 node that responded to the query. See Section 3.5 for more
447 details about the resource records associated with
448 "HOSTNAME.AS112.NET".
450 % dig @prisoner.iana.org hostname.as112.net txt +short +norec
451 "Name of Facility or similar" "City, Country"
452 "See http://www.as112.net/ for more information."
453 %
455 If the response received indicates a different node is being used,
456 then there is probably a routing problem to solve. If there is no
457 response received at all, there might be host or nameserver problem.
458 Judicious use of tools such as traceroute, and consultation of BGP
459 looking glasses might be useful in troubleshooting.
461 Note that an appropriate set of tests for a new server will include
462 queries sent from many different places within the expected service
463 area of the node, using both UDP and TCP transport, and exercising
464 all three AS112 anycast nameserver addresses.
466 4. Operations
468 4.1. Monitoring
470 AS112 nodes should be monitored to ensure they are functioning
471 correctly, just as with any other production service. An AS112 node
472 that stops answering queries correctly can cause failures and
473 timeouts in unexpected places and can lead to failures in dependent
474 systems that can be difficult to troubleshoot.
476 4.2. Downtime
478 An AS112 node that needs to go off-line (e.g. for planned maintenance
479 or as part of the diagnosis of some problem) should stop advertising
480 the AS112 service prefix to its BGP peers. This can be done by
481 shutting down the routing software on the node altogether or by
482 causing the routing system to withdraw the route.
484 Withdrawing the service prefix is important in order to avoid
485 blackholing query traffic in the event that the DNS software on the
486 node is not functioning normally.
488 4.3. Statistics and Measurement
490 Use of the AS112 node should be measured in order to track long-term
491 trends, identify anomalous conditions, and to ensure that the
492 configuration of the AS112 node is sufficient to handle the query
493 load.
495 Examples of free monitoring tools that might be useful to operators
496 of AS112 nodes include:
498 o bindgraph [3]
500 o dnstop [4]
502 o DSC [5]
504 5. Communications
506 It is good operational practice to notify the community of users that
507 may fall within the reach of a new AS112 node before it is installed.
508 At Internet Exchanges, local mailing lists usually exist to
509 facilitate such announcements.
511 For nodes that are intended to be globally reachable, coordination
512 with other AS112 operators is especially recommended. The mailing
513 list is operated for this
514 purpose.
516 Information pertinent to AS112 operations is maintained at
517 .
519 Information about an AS112 node should also be published within the
520 DNS, within the "HOSTNAME.AS112.NET" zone. See Section 3.5 for more
521 details.
523 6. On the Future of AS112 Nodes
525 It is recommended practice for the operators of recursive nameservers
526 to answer queries for zones served by AS112 nodes locally, such that
527 queries never have an opportunity to reach AS112 servers
528 [I-D.ietf-dnsop-default-local-zones]. Operational experience with
529 AS112 nodes does not currently indicate an observable trend towards
530 compliance with those recommendations, however.
532 It is expected that some DNS software vendors will include default
533 configuration that will implement measures such as those described in
534 [I-D.ietf-dnsop-default-local-zones]. If such software is widely
535 deployed, it is reasonable to assume that the query load received by
536 AS112 nodes will decrease; however, it is safe to assume that the
537 query load will not decrease to zero, and consequently that AS112
538 nodes will continue to provide a useful service for the foreseeable
539 future.
541 There may be a requirement in the future for AS112 nodes to answer
542 for their current set of zones over IPv6 transport. Such a
543 requirement would necessitate the assignment of a corresponding IPv6
544 netblock for use as an anycast service prefix.
546 There may be a requirement in the future for AS112 nodes to serve
547 additional zones, or to stop serving particular zones that are
548 currently served. Such changes would be widely announced in
549 operational forums, and published at .
551 7. IANA Considerations
553 The AS112 nameservers are all named under the domain IANA.ORG (see
554 Section 2.2). However, the anycast infrastructure itself is operated
555 by a loosely-coordinated, diverse mix of organisations across the
556 Internet, and is not an IANA function.
558 The autonomous system number 112 and the IPv4 prefix 192.175.48.0/24
559 were assigned by ARIN.
561 This document makes no request of the IANA.
563 8. Security Considerations
565 Hosts should never normally send queries to AS112 servers; queries
566 relating to private-use addresses should be answered locally within a
567 site. Hosts that send queries to AS112 servers may well leak
568 information relating to private infrastructure to the public network,
569 and this could present a security risk. This risk is orthogonal to
570 the presence or absence of authoritative servers for these zones in
571 the public DNS infrastructure, however.
573 Queries that are answered by AS112 servers are usually unintentional;
574 it follows that the responses from AS112 servers are usually
575 unexpected. Unexpected inbound traffic can trigger intrusion
576 detection systems or alerts by firewalls. Operators of AS112 servers
577 should be prepared to be contacted by operators of remote
578 infrastructure who believe their security has been violated. Advice
579 to those who mistakenly believe that responses from AS112 nodes
580 constitutes an attack on their infrastructure can be found in
581 [I-D.ietf-dnsop-as112-under-attack-help-help].
583 The deployment of AS112 nodes is very loosely coordinated compared to
584 other services distributed using anycast. The malicious compromise
585 of an AS112 node and subversion of the data served by the node is
586 hence more difficult to detect due to the lack of central management.
587 Since it is conceivable that changing the responses to queries
588 received by AS112 nodes might influence the behaviour of the hosts
589 sending the queries, such a compromise might be used as an attack
590 vector against private infrastructure.
592 Operators of AS112 should take appropriate measures to ensure that
593 AS112 nodes are appropriately protected from compromise, such as
594 would normally be employed for production nameserver or network
595 infrastructure. The guidance provided for root nameservers in
596 [RFC2870] may be instructive.
598 The zones hosted by AS112 servers are not signed with DNSSEC
599 [RFC4033]. Given the distributed and loosely-coordinated structure
600 of the AS112 service, the zones concerned could only be signed if the
601 private key material used was effectively public, obviating any
602 security benefit resulting from the use of those keys.
604 9. Acknowledgements
606 The authors wish to acknowledge the assistance of Bill Manning, John
607 Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank
608 Habicht, Chris Thompson, Peter Losher, Peter Koch, Alfred Hoenes and
609 S. Moonesamy in the preparation of this document.
611 10. References
613 10.1. Normative References
615 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
616 STD 13, RFC 1034, November 1987.
618 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
619 E. Lear, "Address Allocation for Private Internets",
620 BCP 5, RFC 1918, February 1996.
622 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
623 Name Server Operational Requirements", BCP 40, RFC 2870,
624 June 2000.
626 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
627 Rose, "DNS Security Introduction and Requirements",
628 RFC 4033, March 2005.
630 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
631 Protocol 4 (BGP-4)", RFC 4271, January 2006.
633 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
634 Services", BCP 126, RFC 4786, December 2006.
636 10.2. Informative References
638 [I-D.ietf-dnsop-as112-under-attack-help-help]
639 Abley, J. and W. Maton, "I'm Being Attacked by
640 PRISONER.IANA.ORG!",
641 draft-ietf-dnsop-as112-under-attack-help-help-06 (work in
642 progress), April 2011.
644 [I-D.ietf-dnsop-default-local-zones]
645 Andrews, M., "Locally-served DNS Zones",
646 draft-ietf-dnsop-default-local-zones-15 (work in
647 progress), March 2011.
649 [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
650 Means for Expressing Location Information in the Domain
651 Name System", RFC 1876, January 1996.
653 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
654 BCP 153, RFC 5735, January 2010.
656 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
657 Reverse Zones", BCP 155, RFC 5855, May 2010.
659 URIs
661 [1]
663 [2]
665 [3]
667 [4]
669 [5]
671 Appendix A. History
673 Widespread use of the private address blocks listed in [RFC1918]
674 followed that document's publication in 1996. At that time the IN-
675 ADDR.ARPA zone was served by root servers.
677 The idea of off-loading IN-ADDR.ARPA queries relating to [RFC1918]
678 addresses from the root nameservers was first proposed by Bill
679 Manning and John Brown.
681 The use of anycast for distributing authoritative DNS service for
682 [RFC1918] IN-ADDR.ARPA zones was subsequently proposed at a private
683 meeting of root server operators.
685 ARIN provided an IPv4 prefix for the anycast service, and also the
686 autonomous system number 112 for use in originating that prefix.
687 This assignment gave the project its name.
689 In 2002 the first AS112 anycast nodes were deployed.
691 In 2011 the IN-ADDR.ARPA zone was redelegated from the root servers
692 to a new set of servers operated independently by AfriNIC, APNIC,
693 ARIN, ICANN, LACNIC and the RIPE NCC and named according to
694 [RFC5855].
696 The use of anycast nameservers in the AS112 project contributed to
697 the operational experience of anycast DNS services, and can be seen
698 as a precursor to the anycast distribution of other authoritative DNS
699 servers in subsequent years (e.g. various root servers).
701 Appendix B. Change History
703 This section to be removed prior to publication.
705 00 Initial draft, circulated as draft-jabley-as112-ops-00 and
706 reviewed at the DNSOP working group meeting at IETF 66.
708 00 Document adoped by the DNSOP working group and renamed
709 accordingly.
711 01 Input from reviewers of DNSOP and others, some cosmetic tweaks.
713 02 Version bump as request by DNSOP chairs. Added missing IANA
714 Considerations section. Updated author's addresses. Make
715 http://www.as112.net/ URL consistent.
717 03 Fix BLACKHOLE-2.IANA.ORG IP address.
719 04 Bump version number. Refresh references. Add reference to BIRD.
720 Minor wordsmithing.
722 05 Updated following review from Peter Koch.
724 06 Updated following review from Alfred Hoenes.
726 07 Updated following IESG review.
728 08 Updated following review by S. Moonesamy.
730 09 Updated following review by Peter Koch.
732 Authors' Addresses
734 Joe Abley
735 ICANN
736 4676 Admiralty Way, Suite 330
737 Marina del Rey, CA 90292
738 US
740 Phone: +1 519 670 9327
741 Email: joe.abley@icann.org
743 William F. Maton Sotomayor
744 National Research Council of Canada
745 1200 Montreal Road
746 Ottawa, ON K1A 0R6
747 Canada
749 Phone: +1 613 993 0880
750 Email: wmaton@ryouko.imsb.nrc.ca