1 Internet Engineering Task Force (IETF) J. Abley
2 Request for Comments: 7534 Dyn, Inc.
3 Obsoletes: 6304 W. Sotomayor
4 Category: Informational OttIX
5 ISSN: 2070-1721 May 2015
6
7
8 AS112 Nameserver Operations
9
10 Abstract
11
12 Many sites connected to the Internet make use of IPv4 addresses that
13 are not globally unique. Examples are the addresses designated in
14 RFC 1918 for private use within individual sites.
15
16 Devices in such environments may occasionally originate Domain Name
17 System (DNS) queries (so-called "reverse lookups") corresponding to
18 those private-use addresses. Since the addresses concerned have only
19 local significance, it is good practice for site administrators to
20 ensure that such queries are answered locally. However, it is not
21 uncommon for such queries to follow the normal delegation path in the
22 public DNS instead of being answered within the site.
23
24 It is not possible for public DNS servers to give useful answers to
25 such queries. In addition, due to the wide deployment of private-use
26 addresses and the continuing growth of the Internet, the volume of
27 such queries is large and growing. The AS112 project aims to provide
28 a distributed sink for such queries in order to reduce the load on
29 the corresponding authoritative servers. The AS112 project is named
30 after the Autonomous System Number (ASN) that was assigned to it.
31
32 This document describes the steps required to install a new AS112
33 node and offers advice relating to such a node's operation.
34
35 This document obsoletes RFC 6304.
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Abley & Sotomayor Informational [Page 1]
53 RFC 7534 AS112 Nameserver Operations May 2015
54
55
56 Status of This Memo
57
58 This document is not an Internet Standards Track specification; it is
59 published for informational purposes.
60
61 This document is a product of the Internet Engineering Task Force
62 (IETF). It represents the consensus of the IETF community. It has
63 received public review and has been approved for publication by the
64 Internet Engineering Steering Group (IESG). Not all documents
65 approved by the IESG are a candidate for any level of Internet
66 Standard; see Section 2 of RFC 5741.
67
68 Information about the current status of this document, any errata,
69 and how to provide feedback on it may be obtained at
70 http://www.rfc-editor.org/info/rfc7534.
71
72 Copyright Notice
73
74 Copyright (c) 2015 IETF Trust and the persons identified as the
75 document authors. All rights reserved.
76
77 This document is subject to BCP 78 and the IETF Trust's Legal
78 Provisions Relating to IETF Documents
79 (http://trustee.ietf.org/license-info) in effect on the date of
80 publication of this document. Please review these documents
81 carefully, as they describe your rights and restrictions with respect
82 to this document. Code Components extracted from this document must
83 include Simplified BSD License text as described in Section 4.e of
84 the Trust Legal Provisions and are provided without warranty as
85 described in the Simplified BSD License.
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Abley & Sotomayor Informational [Page 2]
108 RFC 7534 AS112 Nameserver Operations May 2015
109
110
111 Table of Contents
112
113 1. Introduction ....................................................4
114 2. AS112 DNS Service ...............................................4
115 2.1. Approach ...................................................4
116 2.1.1. Direct Delegation ...................................4
117 2.1.2. DNAME Redirection ...................................5
118 2.2. Zones ......................................................5
119 2.3. Nameservers ................................................6
120 3. Installation of a New Node ......................................6
121 3.1. Useful Background Knowledge ................................6
122 3.2. Topological Location .......................................6
123 3.3. Operating System and Host Considerations ...................7
124 3.4. Routing Software ...........................................7
125 3.5. DNS Software ..............................................10
126 3.6. Testing a Newly Installed Node ............................15
127 4. Operations .....................................................16
128 4.1. Monitoring ................................................16
129 4.2. Downtime ..................................................16
130 4.3. Statistics and Measurement ................................16
131 5. Communications .................................................17
132 6. On the Future of AS112 Nodes ...................................17
133 7. IANA Considerations ............................................18
134 7.1. General ...................................................18
135 7.2. IANA Actions ..............................................18
136 7.2.1. IPv6 Transport for Direct Delegation AS112
137 Servers ............................................18
138 7.2.2. Registration in the Special-Purpose AS
139 Numbers Registry ...................................19
140 7.2.3. Registration in the IANA IPv4
141 Special-Purpose Address Registry ...................19
142 7.2.4. Registration in the IANA IPv6
143 Special-Purpose Address Registry ...................19
144 8. Security Considerations ........................................20
145 9. References .....................................................21
146 9.1. Normative References ......................................21
147 9.2. Informative References ....................................22
148 Appendix A. A Brief History of AS112 ..............................23
149 Appendix B. Changes since RFC 6304 ................................23
150 Acknowledgements ..................................................24
151 Authors' Addresses ................................................24
152
153
154
155
156
157
158
159
160
161
162 Abley & Sotomayor Informational [Page 3]
163 RFC 7534 AS112 Nameserver Operations May 2015
164
165
166 1. Introduction
167
168 Many sites connected to the Internet make use of IPv4 addresses that
169 are not globally unique. Examples are the addresses designated in
170 [RFC1918] for private use within individual sites.
171
172 Devices in such environments may occasionally originate Domain Name
173 System (DNS) [RFC1034] queries (so-called "reverse lookups")
174 corresponding to those private-use addresses. Since the addresses
175 concerned have only local significance, it is good practice for site
176 administrators to ensure that such queries are answered locally
177 [RFC6303]. However, it is not uncommon for such queries to follow
178 the normal delegation path in the public DNS instead of being
179 answered within the site.
180
181 It is not possible for public DNS servers to give useful answers to
182 such queries. In addition, due to the wide deployment of private-use
183 addresses and the continuing growth of the Internet, the volume of
184 such queries is large and growing. The AS112 project aims to provide
185 a distributed sink for such queries in order to reduce the load on
186 the IN-ADDR.ARPA authoritative servers [RFC5855].
187
188 The AS112 project encompasses a loosely coordinated collection of
189 independently operated nameservers. Each nameserver functions as a
190 single node in an AS112 anycast cloud [RFC4786] and is configured to
191 answer authoritatively for a particular set of nominated zones.
192
193 The AS112 project is named after the Autonomous System Number (ASN)
194 that was assigned to it (see Appendix A).
195
196 2. AS112 DNS Service
197
198 2.1. Approach
199
200 2.1.1. Direct Delegation
201
202 The AS112 project currently uses an approach whereby zones whose
203 traffic should be directed towards an AS112 sink should be directly
204 delegated to AS112 nameservers. Correspondingly, each AS112 node is
205 manually configured to answer appropriately for those zones.
206
207 The guidance in this document describes this capability for the zones
208 that were originally delegated in this fashion. AS112 nodes that
209 were implemented in accordance with the guidance found here will
210 continue to provide service for those zones.
211
212
213
214
215
216
217 Abley & Sotomayor Informational [Page 4]
218 RFC 7534 AS112 Nameserver Operations May 2015
219
220
221 2.1.2. DNAME Redirection
222
223 [RFC7535] describes a different approach whereby queries towards
224 specific zones are redirected to an empty zone also hosted on AS112
225 servers, using DNAME [RFC6672].
226
227 The guidance in this document introduces this capability, allowing
228 any zone administrator to sink query traffic in AS112 infrastructure
229 without requiring changes to any AS112 node.
230
231 2.2. Zones
232
233 To support Direct Delegation AS112 service, AS112 nameservers answer
234 authoritatively for the following zones, corresponding to [RFC1918]
235 private-use netblocks:
236
237 o 10.IN-ADDR.ARPA
238
239 o 16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ..., 31.172.IN-ADDR.ARPA
240
241 o 168.192.IN-ADDR.ARPA
242
243 and the following zone, corresponding to the "link local" netblock
244 169.254.0.0/16 listed in [RFC6890]:
245
246 o 254.169.IN-ADDR.ARPA
247
248 To support DNAME redirection AS112 service, AS112 nameservers answer
249 authoritatively for the following zone, as specified in [RFC7535]:
250
251 o EMPTY.AS112.ARPA
252
253 To aid identification of AS112 anycast nodes, each node also answers
254 authoritatively for the following zones:
255
256 o HOSTNAME.AS112.NET
257
258 o HOSTNAME.AS112.ARPA
259
260 See Section 3.5 for the recommended contents of all these zones.
261
262
263
264
265
266
267
268
269
270
271
272 Abley & Sotomayor Informational [Page 5]
273 RFC 7534 AS112 Nameserver Operations May 2015
274
275
276 2.3. Nameservers
277
278 To support Direct Delegation AS112 service, the relevant zones listed
279 in Section 2.2 are delegated to the two nameservers
280 BLACKHOLE-1.IANA.ORG (192.175.48.6, 2620:4f:8000::6) and
281 BLACKHOLE-2.IANA.ORG (192.175.48.42, 2620:4f:8000::42).
282
283 Additionally, the server PRISONER.IANA.ORG (192.175.48.1,
284 2620:4f:8000::1) is listed in the MNAME field of the SOA records of
285 the IN-ADDR.ARPA zones served by AS112 nameservers.
286 PRISONER.IANA.ORG receives mainly dynamic update queries.
287
288 The addresses of all these nameservers are covered by the single IPv4
289 prefix 192.175.48.0/24 and the IPv6 prefix 2620:4f:8000::/48. To
290 date, IPv6 transport for these nameservers has only been available
291 for pre-production testing. IANA has added AAAA RRSets for the owner
292 names of these nameservers; see Section 7.
293
294 To support DNAME redirection AS112 service, the single zone
295 EMPTY.AS112.ARPA is delegated to the single nameserver
296 BLACKHOLE.AS112.ARPA (192.31.196.1, 2001:4:112::1). The addresses of
297 that nameserver are covered by the single IPv4 prefix 192.31.196.0/24
298 and the single IPv6 prefix 2001:4:112::/48.
299
300 3. Installation of a New Node
301
302 3.1. Useful Background Knowledge
303
304 Installation of an AS112 node is relatively straightforward.
305 However, experience in the following general areas may prove useful:
306
307 o inter-domain routing with BGP [RFC4271];
308
309 o DNS authoritative server operations; and
310
311 o anycast [RFC4786] distribution of DNS services.
312
313 3.2. Topological Location
314
315 AS112 nodes may be located anywhere on the Internet. For nodes that
316 are intended to provide a public service to the Internet community
317 (as opposed to private use), it may well be advantageous to choose a
318 location that is easily (and cheaply) reachable by multiple
319 providers, such as an Internet Exchange Point.
320
321
322
323
324
325
326
327 Abley & Sotomayor Informational [Page 6]
328 RFC 7534 AS112 Nameserver Operations May 2015
329
330
331 AS112 nodes may advertise their service prefix to BGP peers for local
332 use (analogous to a conventional peering relationship between two
333 providers) or for global use (analogous to a customer relationship
334 with one or more providers).
335
336 It is good operational practice to notify the community of users that
337 may fall within the reach of a new AS112 node before it is installed.
338 At an Internet Exchange, local mailing lists usually exist to
339 facilitate such announcements. For nodes that are intended to be
340 globally reachable, coordination with other AS112 operators is highly
341 recommended. See also Section 5.
342
343 3.3. Operating System and Host Considerations
344
345 Examples in this document are based on UNIX and UNIX-like operating
346 systems, but other operating systems exist that are suitable for use
347 in construction of an AS112 node.
348
349 The chosen platform should include either support for cloned loopback
350 interfaces or the capability to bind multiple addresses to a single
351 loopback interface. The addresses of the nameservers listed in
352 Section 2.3 will be configured on these interfaces in order that the
353 DNS software can respond to queries properly.
354
355 A host that is configured to act as an AS112 anycast node should be
356 dedicated to that purpose and should not be used to simultaneously
357 provide other services. This guidance is provided due to the
358 unpredictable (and occasionally high) traffic levels that AS112 nodes
359 have been seen to attract.
360
361 System startup scripts should be arranged such that the various
362 AS112-related components start automatically following a system
363 reboot. The order in which interfaces are configured and software
364 components started should be arranged such that routing software
365 startup follows DNS software startup, and DNS software startup
366 follows loopback interface configuration.
367
368 Wrapper scripts or other arrangements should be employed to ensure
369 that the anycast service prefix for AS112 is not advertised while
370 either the anycast addresses are not configured or the DNS software
371 is not running.
372
373 3.4. Routing Software
374
375 AS112 nodes signal the availability of AS112 nameservers to the
376 Internet using BGP [RFC4271]: each AS112 node is a BGP speaker and
377 announces the prefixes 192.175.48.0/24 and 2620:4f:8000::/48 to the
378 Internet with origin AS 112 (see also Section 2.3).
379
380
381
382 Abley & Sotomayor Informational [Page 7]
383 RFC 7534 AS112 Nameserver Operations May 2015
384
385
386 The examples in this document are based on the Quagga Routing Suite
387 <http://www.quagga.net> running on Linux, but other software packages
388 exist that also provide suitable BGP support for AS112 nodes.
389
390 The "bgpd.conf" file is used by Quagga's bgpd daemon, which provides
391 BGP support. The router ID in this example is 203.0.113.1; the AS112
392 node peers with external peers 192.0.2.1, 192.0.2.2, 2001:db8::1, and
393 2001:db8::2. Note that the local AS number is 112, and the service
394 prefixes originated from the AS112 node to support Direct Delegation
395 service are 192.175.48.0/24 and 2620:4f:8000::/48; the IPv4 prefix
396 192.31.196.0/24 and the IPv6 prefix 2001:4:112::/48 support DNAME
397 redirection.
398
399 For clarity, an IPv4-only AS112 node need not configure any of the
400 IPv6 elements that follow; similarly, an IPv6-only AS112 node need
401 not configure any of the IPv4 elements. Such single-stack hosts can
402 still contribute usefully to IPv4 and IPv6 AS112 services, however,
403 and single-stack operation is not discouraged.
404
405 ! bgpd.conf
406 !
407 hostname as112-bgpd
408 password <something>
409 enable password <supersomething>
410 !
411 ! Note that all AS112 nodes use the local Autonomous System Number
412 ! 112, and originate the IPv4 prefixes 192.175.48.0/24 and
413 ! 192.31.196.0/24 and the IPv6 prefixes 2620:4f:8000::/48 and
414 ! 2001:4:112::/48.
415 !
416 ! All other addresses shown below are illustrative, and
417 ! actual numbers will depend on local circumstances.
418 !
419 ! IPv4-only or IPv6-only AS112 nodes should omit advertisements
420 ! for address families they do not support.
421 !
422 router bgp 112
423 bgp router-id 203.0.113.1
424 neighbor 192.0.2.1 remote-as 64496
425 neighbor 192.0.2.1 next-hop-self
426 neighbor 192.0.2.1 prefix-list AS112-v4 out
427 neighbor 192.0.2.1 filter-list 1 out
428 !
429 neighbor 192.0.2.2 remote-as 64497
430 neighbor 192.0.2.2 next-hop-self
431 neighbor 192.0.2.2 prefix-list AS112-v4 out
432 neighbor 192.0.2.2 filter-list 1 out
433 !
434
435
436
437 Abley & Sotomayor Informational [Page 8]
438 RFC 7534 AS112 Nameserver Operations May 2015
439
440
441 neighbor 2001:db8::1 remote-as 64498
442 neighbor 2001:db8::1 next-hop-self
443 neighbor 2001:db8::1 prefix-list AS112-v6 out
444 neighbor 2001:db8::1 filter-list 1 out
445 !
446 neighbor 2001:db8::2 remote-as 64499
447 neighbor 2001:db8::2 next-hop-self
448 neighbor 2001:db8::2 prefix-list AS112-v6 out
449 neighbor 2001:db8::2 filter-list 1 out
450 !
451 network 192.175.48.0/24
452 network 192.31.196.0/24
453 !
454 address-family ipv6 unicast
455 network 2620:4f:8000::/48
456 network 2001:4:112::/48
457 exit-address-family
458 !
459 ip prefix-list AS112-v4 permit 192.175.48.0/24
460 ip prefix-list AS112-v4 permit 192.31.196.0/24
461 !
462 ipv6 prefix-list AS112-v6 permit 2620:4f:8000::/48
463 ipv6 prefix-list AS112-v6 permit 2001:4:112::/48
464 !
465 ip as-path access-list 1 permit ^$
466
467 The configuration above includes two restrictions on what the AS112
468 should advertise to its BGP neighbours: a prefix filter that permits
469 only the service prefixes, and an AS_PATH filter that matches only
470 locally originated routes. Together, these measures prevent the node
471 from becoming a transit point for its adjacent ASes.
472
473 The "zebra.conf" file is required to provide integration between
474 protocol daemons (bgpd, in this case) and the kernel.
475
476 ! zebra.conf
477 !
478 hostname as112
479 password <something>
480 enable password <supersomething>
481 !
482 interface lo
483 !
484 interface eth0
485 !
486
487
488
489
490
491
492 Abley & Sotomayor Informational [Page 9]
493 RFC 7534 AS112 Nameserver Operations May 2015
494
495
496 3.5. DNS Software
497
498 Although the queries received by AS112 nodes are definitively
499 misdirected, it is important that they be answered in a manner that
500 is accurate and consistent. For this reason, AS112 nodes operate as
501 fully functional and standards-compliant DNS authoritative servers
502 [RFC1034], and hence require appropriate DNS software.
503
504 Examples in this document are based on ISC BIND9
505 <http://www.isc.org/software/BIND/>, but other DNS software exists
506 that is suitable for use in construction of an AS112 node.
507
508 The following is a sample BIND9 "named.conf" file for a dedicated
509 AS112 server. Note that the nameserver is configured to act as an
510 authoritative-only server (i.e., recursion is disabled). The
511 nameserver is also configured to listen on the various AS112 anycast
512 nameserver addresses, as well as its local addresses.
513
514 A basic logging example is included in the sample as well. AS112
515 operators may exercise discretion at the amount of logging detail
516 they desire or the type of logging they may use in the maintenance of
517 their node. The detail of information can then be used to single out
518 bad implementors or badly managed nameservers, or it can be used for
519 simple measurement analysis.
520
521 // named.conf
522
523 // Global options
524
525 options {
526 listen-on {
527 127.0.0.1; // localhost
528
529 // The following address is node-dependent and should be set to
530 // something appropriate for the new AS112 node.
531
532 203.0.113.1; // local address (globally unique, unicast)
533
534 // The following addresses are used to support Direct Delegation
535 // AS112 service and are the same for all AS112 nodes.
536
537 192.175.48.1; // prisoner.iana.org (anycast)
538 192.175.48.6; // blackhole-1.iana.org (anycast)
539 192.175.48.42; // blackhole-2.iana.org (anycast)
540
541
542
543
544
545
546
547 Abley & Sotomayor Informational [Page 10]
548 RFC 7534 AS112 Nameserver Operations May 2015
549
550
551 // The following address is used to support DNAME redirection
552 // AS112 service and is the same for all AS112 nodes.
553
554 192.31.196.1; // blackhole.as112.arpa (anycast)
555 };
556
557 listen-on-v6 {
558 ::1; // localhost
559
560 // The following addresses are used to support Direct Delegation
561 // AS112 service and are the same for all AS112 nodes.
562
563 2620:4f:8000::1; // prisoner.iana.org (anycast)
564 2620:4f:8000::6; // blackhole-1.iana.org (anycast)
565 2620:4f:8000::42; // blackhole-2.iana.org (anycast)
566
567 // The following address is used to support DNAME redirection
568 // AS112 service and is the same for all AS112 nodes.
569
570 2001:4:112::1; // blackhole.as112.arpa (anycast)
571 };
572
573 directory "/var/named";
574 recursion no; // authoritative-only server
575 };
576
577 // Log queries, so that when people call us about unexpected
578 // answers to queries they didn't realise they had sent, we
579 // have something to talk about. Note that activating this
580 // naively has the potential to create high CPU load and consume
581 // enormous amounts of disk space. This example retains 2 old
582 // versions at a maximum of 500 MB each before rotating out the
583 // oldest one.
584
585 logging {
586 channel "querylog" {
587 file "/var/log/query.log" versions 2 size 500m;
588 print-time yes;
589 };
590 category queries { querylog; };
591 };
592
593
594
595
596
597
598
599
600
601
602 Abley & Sotomayor Informational [Page 11]
603 RFC 7534 AS112 Nameserver Operations May 2015
604
605
606 // Direct Delegation AS112 Service
607
608 // RFC 1918
609
610 zone "10.in-addr.arpa" { type master; file "db.dd-empty"; };
611 zone "16.172.in-addr.arpa" { type master; file "db.dd-empty"; };
612 zone "17.172.in-addr.arpa" { type master; file "db.dd-empty"; };
613 zone "18.172.in-addr.arpa" { type master; file "db.dd-empty"; };
614 zone "19.172.in-addr.arpa" { type master; file "db.dd-empty"; };
615 zone "20.172.in-addr.arpa" { type master; file "db.dd-empty"; };
616 zone "21.172.in-addr.arpa" { type master; file "db.dd-empty"; };
617 zone "22.172.in-addr.arpa" { type master; file "db.dd-empty"; };
618 zone "23.172.in-addr.arpa" { type master; file "db.dd-empty"; };
619 zone "24.172.in-addr.arpa" { type master; file "db.dd-empty"; };
620 zone "25.172.in-addr.arpa" { type master; file "db.dd-empty"; };
621 zone "26.172.in-addr.arpa" { type master; file "db.dd-empty"; };
622 zone "27.172.in-addr.arpa" { type master; file "db.dd-empty"; };
623 zone "28.172.in-addr.arpa" { type master; file "db.dd-empty"; };
624 zone "29.172.in-addr.arpa" { type master; file "db.dd-empty"; };
625 zone "30.172.in-addr.arpa" { type master; file "db.dd-empty"; };
626 zone "31.172.in-addr.arpa" { type master; file "db.dd-empty"; };
627 zone "168.192.in-addr.arpa" { type master; file "db.dd-empty"; };
628
629 // RFC 6890
630
631 zone "254.169.in-addr.arpa" { type master; file "db.dd-empty"; };
632
633 // DNAME redirection AS112 Service
634
635 zone "empty.as112.arpa" { type master; file "db.dr-empty"; };
636
637 // Also answer authoritatively for the HOSTNAME.AS112.NET and
638 // HOSTNAME.AS112.ARPA zones, which contain data of operational
639 // relevance.
640
641 zone "hostname.as112.net" {
642 type master;
643 file "db.hostname.as112.net";
644 };
645
646 zone "hostname.as112.arpa" {
647 type master;
648 file "db.hostname.as112.arpa";
649 };
650
651
652
653
654
655
656
657 Abley & Sotomayor Informational [Page 12]
658 RFC 7534 AS112 Nameserver Operations May 2015
659
660
661 The "db.dd-empty" file follows, below. This is the source data used
662 to populate all the IN-ADDR.ARPA zones listed in Section 2.2 that
663 support Direct Delegation AS112 service. Note that the RNAME
664 specified in the SOA record corresponds to
665 hostmaster@root-servers.org, a suitable email address for receiving
666 technical queries about these zones.
667
668 ; db.dd-empty
669 ;
670 ; Empty zone for Direct Delegation AS112 service.
671 ;
672 $TTL 1W
673 @ IN SOA prisoner.iana.org. hostmaster.root-servers.org. (
674 1 ; serial number
675 1W ; refresh
676 1M ; retry
677 1W ; expire
678 1W ) ; negative caching TTL
679 ;
680 NS blackhole-1.iana.org.
681 NS blackhole-2.iana.org.
682 ;
683 ; There should be no other resource records included in this zone.
684 ;
685 ; Records that relate to RFC 1918-numbered resources within the
686 ; site hosting this AS112 node should not be hosted on this
687 ; nameserver.
688
689 The "db.dr-empty" file follows, below. This is the source data used
690 to populate the EMPTY.AS112.ARPA zone that supports DNAME redirection
691 AS112 service. Note that the RNAME specified in the SOA record
692 corresponds to noc@dns.icann.org, a suitable email address for
693 technical queries about this zone.
694
695 ; db.dr-empty
696 ;
697 ; Empty zone for DNAME redirection AS112 service.
698 ;
699 $TTL 1W
700 @ IN SOA blackhole.as112.arpa. noc.dns.icann.org. (
701 1 ; serial number
702 1W ; refresh
703 1M ; retry
704 1W ; expire
705 1W ) ; negative caching TTL
706 ;
707 NS blackhole.as112.arpa.
708 ;
709
710
711
712 Abley & Sotomayor Informational [Page 13]
713 RFC 7534 AS112 Nameserver Operations May 2015
714
715
716 ; There should be no other resource records included in this zone.
717 ;
718 ; Records that relate to RFC 1918-numbered resources within the
719 ; site hosting this AS112 node should not be hosted on this
720 ; nameserver.
721
722 The "db.hostname.as112.net" and "db.hostname.as112.arpa" files
723 follow, below. These zones contain various resource records that
724 provide operational data to users for troubleshooting or measurement
725 purposes; the data should be edited to suit local circumstances.
726 Note that the responses to the queries "HOSTNAME.AS112.NET IN TXT"
727 and "HOSTNAME.AS112.ARPA IN TXT" should fit within a 512-octet DNS/
728 UDP datagram: i.e., it should be available over UDP transport without
729 requiring EDNS0 support by the client.
730
731 The optional LOC record [RFC1876] included in each zone apex provides
732 information about the geospatial location of the node.
733
734 Where software implementations support it, operational data should
735 also be carried using NSID [RFC5001].
736
737 ; db.hostname.as112.net
738 ;
739 $TTL 1W
740 @ SOA server.example.net. admin.example.net. (
741 1 ; serial number
742 1W ; refresh
743 1M ; retry
744 1W ; expire
745 1W ) ; negative caching TTL
746 ;
747 NS blackhole-1.iana.org.
748 NS blackhole-2.iana.org.
749 ;
750 TXT "Name of Facility or similar" "City, Country"
751 TXT "See http://www.as112.net/ for more information."
752 TXT "Unique IP: 203.0.113.1."
753 ;
754 LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m
755
756
757
758
759
760
761
762
763
764
765
766
767 Abley & Sotomayor Informational [Page 14]
768 RFC 7534 AS112 Nameserver Operations May 2015
769
770
771 ; db.hostname.as112.arpa
772 ;
773 $TTL 1W
774 @ SOA server.example.net. admin.example.net. (
775 1 ; serial number
776 1W ; refresh
777 1M ; retry
778 1W ; expire
779 1W ) ; negative caching TTL
780 ;
781 NS blackhole.as112.arpa.
782 ;
783 TXT "Name of Facility or similar" "City, Country"
784 TXT "See http://www.as112.net/ for more information."
785 ;
786 LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m
787
788 3.6. Testing a Newly Installed Node
789
790 The BIND9 tool "dig" can be used to retrieve the TXT resource records
791 associated with the names "HOSTNAME.AS112.NET" and
792 "HOSTNAME.AS112.ARPA", directed at one of the AS112 anycast
793 nameserver addresses. Continuing the example from above, the
794 response received should indicate the identity of the AS112 node that
795 responded to the query. See Section 3.5 for more details about the
796 resource records associated with "HOSTNAME.AS112.NET".
797
798 % dig @prisoner.iana.org hostname.as112.net txt +short +norec
799 "Name of Facility or similar" "City, Country"
800 "See http://www.as112.net/ for more information."
801 %
802
803 If the response received indicates that a different node is being
804 used, then there is probably a routing problem to solve. If there is
805 no response received at all, there might be a host or nameserver
806 problem. Judicious use of tools such as traceroute and consultation
807 of BGP looking glasses might be useful in troubleshooting.
808
809 Note that an appropriate set of tests for a new server will include
810 queries sent from many different places within the expected service
811 area of the node, using both UDP and TCP transport, and exercising
812 all three AS112 anycast nameserver addresses.
813
814
815
816
817
818
819
820
821
822 Abley & Sotomayor Informational [Page 15]
823 RFC 7534 AS112 Nameserver Operations May 2015
824
825
826 4. Operations
827
828 4.1. Monitoring
829
830 AS112 nodes should be monitored to ensure that they are functioning
831 correctly, just as with any other production service. An AS112 node
832 that stops answering queries correctly can cause failures and
833 timeouts in unexpected places and can lead to failures in dependent
834 systems that can be difficult to troubleshoot.
835
836 4.2. Downtime
837
838 An AS112 node that needs to go off-line (e.g., for planned
839 maintenance or as part of the diagnosis of some problem) should stop
840 advertising the AS112 service prefixes to its BGP peers. This can be
841 done by shutting down the routing software on the node altogether or
842 by causing the routing system to withdraw the route.
843
844 Withdrawing the service prefixes is important in order to avoid
845 blackholing query traffic in the event that the DNS software on the
846 node is not functioning normally.
847
848 4.3. Statistics and Measurement
849
850 Use of the AS112 node should be measured in order to track long-term
851 trends, identify anomalous conditions, and ensure that the
852 configuration of the AS112 node is sufficient to handle the query
853 load.
854
855 Examples of free monitoring tools that might be useful to operators
856 of AS112 nodes include:
857
858 o bindgraph <http://www.linux.it/~md/software/>
859
860 o dnstop <http://dns.measurement-factory.com/tools/dnstop/>
861
862 o DSC <https://www.dns-oarc.net/tools/dsc/>
863
864 Operators of AS112 nodes should also consider participating in
865 collection events as part of a larger, coordinated effort to gather
866 important baselines. One example of such an effort is Day in the
867 Life <https://www.dns-oarc.net/oarc/data/ditl/>, coordinated by the
868 DNS-OARC <https://www.dns-oarc.net/>.
869
870
871
872
873
874
875
876
877 Abley & Sotomayor Informational [Page 16]
878 RFC 7534 AS112 Nameserver Operations May 2015
879
880
881 5. Communications
882
883 It is good operational practice to notify the community of users that
884 may fall within the reach of a new AS112 node before it is installed.
885 At Internet Exchanges, local mailing lists usually exist to
886 facilitate such announcements.
887
888 For nodes that are intended to be globally reachable, coordination
889 with other AS112 operators is especially recommended. The mailing
890 list <as112-ops@lists.dns-oarc.net> is operated for this purpose.
891
892 Information pertinent to AS112 operations is maintained at
893 <http://www.as112.net/>.
894
895 Information about an AS112 node should also be published within the
896 DNS, within the "HOSTNAME.AS112.NET" and "HOSTNAME.AS112.ARPA" zones.
897 See Section 3.5 for more details.
898
899 AS112 operators should also be aware of the measures described in
900 [RFC6305] and direct site administrators appropriately.
901
902 6. On the Future of AS112 Nodes
903
904 It is recommended practice for the operators of recursive nameservers
905 to answer queries for zones served by AS112 nodes locally, such that
906 queries never have an opportunity to reach AS112 servers [RFC6303].
907 Operational experience with AS112 nodes does not currently indicate
908 an observable trend towards compliance with those recommendations,
909 however.
910
911 It is expected that some DNS software vendors will include default
912 configuration that will implement measures such as those described in
913 [RFC6303]. If such software is widely deployed, it is reasonable to
914 assume that the query load received by AS112 nodes will decrease;
915 however, it is safe to assume that the query load will not decrease
916 to zero, and consequently that AS112 nodes will continue to provide a
917 useful service for the foreseeable future.
918
919 The use of DNAME redirection to provide AS112 service is new and
920 hence is informed by minimal operational experience. The use of
921 DNAME means that queries for many source zones could be redirected to
922 AS112 infrastructure with no real opportunity for coordination.
923
924 If the DNAME redirection approach is successful, and in the absence
925 of any operational concerns, the community might well recommend the
926 retirement of the original Direct Delegation AS112 service. This
927 document makes no such recommendation, however.
928
929
930
931
932 Abley & Sotomayor Informational [Page 17]
933 RFC 7534 AS112 Nameserver Operations May 2015
934
935
936 7. IANA Considerations
937
938 7.1. General
939
940 The nameservers associated with Direct Delegation AS112 service are
941 all named under the domain IANA.ORG (see Section 2.3). However, the
942 anycast infrastructure itself is operated by a loosely coordinated,
943 diverse mix of organisations across the Internet and is not an IANA
944 function.
945
946 The autonomous system number 112, the IPv4 prefix 192.175.48.0/24,
947 and the IPv6 prefix 2620:4f:8000::/48 were assigned by ARIN.
948
949 The IPv4 prefix 192.31.196.0/24 and the IPv6 prefix 2001:4:112::/48,
950 used for DNAME redirection AS112 service, were assigned by the IANA
951 [RFC7535].
952
953 The three nameservers BLACKHOLE-1.IANA.ORG, BLACKHOLE-2.IANA.ORG, and
954 PRISONER.IANA.ORG are also reachable over IPv6, as described in
955 Section 2.3. Following a substantial period of pre-production
956 testing by AS112 operators, the IANA has added AAAA RRSets to those
957 owner names in Section 7.2.1, to allow the servers to receive queries
958 and generate responses over IPv6 transport.
959
960 7.2. IANA Actions
961
962 7.2.1. IPv6 Transport for Direct Delegation AS112 Servers
963
964 The IANA has added the following AAAA resource records for the three
965 Direct Delegation AS112 nameservers named under IANA.ORG:
966
967 +----------------------+------------------+
968 | Owner Name | AAAA RDATA |
969 +----------------------+------------------+
970 | PRISONER.IANA.ORG | 2620:4f:8000::1 |
971 | | |
972 | BLACKHOLE-1.IANA.ORG | 2620:4f:8000::6 |
973 | | |
974 | BLACKHOLE-2.IANA.ORG | 2620:4f:8000::42 |
975 +----------------------+------------------+
976
977
978
979
980
981
982
983
984
985
986
987 Abley & Sotomayor Informational [Page 18]
988 RFC 7534 AS112 Nameserver Operations May 2015
989
990
991 7.2.2. Registration in the Special-Purpose AS Numbers Registry
992
993 The IANA has added AS112 to the "Special-Purpose AS Numbers" registry
994 specified in [RFC7249] as follows:
995
996 AS Numbers: 112
997
998 Reason for Reservation: Used by the AS112 project to sink
999 misdirected DNS queries; see RFC 7534.
1000
1001 7.2.3. Registration in the IANA IPv4 Special-Purpose Address Registry
1002
1003 The IANA has added 192.175.48.0/24 to the "IANA IPv4 Special-Purpose
1004 Address Registry" specified in [RFC6890] as follows:
1005
1006 Address Block: 192.175.48.0/24
1007
1008 Name: Direct Delegation AS112 Service
1009
1010 RFC: RFC 7534
1011
1012 Allocation Date: 1996-01
1013
1014 Termination Date: N/A
1015
1016 Source: True
1017
1018 Destination: True
1019
1020 Forwardable: True
1021
1022 Global: True
1023
1024 Reserved-by-Protocol: False
1025
1026 7.2.4. Registration in the IANA IPv6 Special-Purpose Address Registry
1027
1028 The IANA has added 2620:4f:8000::/48 to the "IANA IPv6 Special-
1029 Purpose Address Registry" specified in [RFC6890] as follows:
1030
1031 Address Block: 2620:4f:8000::/48
1032
1033 Name: Direct Delegation AS112 Service
1034
1035 RFC: RFC 7534
1036
1037 Allocation Date: 2011-05
1038
1039
1040
1041
1042 Abley & Sotomayor Informational [Page 19]
1043 RFC 7534 AS112 Nameserver Operations May 2015
1044
1045
1046 Termination Date: N/A
1047
1048 Source: True
1049
1050 Destination: True
1051
1052 Forwardable: True
1053
1054 Global: True
1055
1056 Reserved-by-Protocol: False
1057
1058 8. Security Considerations
1059
1060 Hosts should never normally send queries to AS112 servers; queries
1061 relating to private-use addresses should be answered locally within a
1062 site. Hosts that send queries to AS112 servers may well leak
1063 information relating to private infrastructure to the public network,
1064 and this could present a security risk. Additionally, AS112
1065 operators may log this information, making it further subject to
1066 whatever security and privacy risks that might entail. These risks
1067 are orthogonal to the presence or absence of authoritative servers
1068 for these zones in the public DNS infrastructure, however.
1069
1070 Queries that are answered by AS112 servers are usually unintentional;
1071 it follows that the responses from AS112 servers are usually
1072 unexpected. Unexpected inbound traffic can trigger intrusion
1073 detection systems or alerts by firewalls. Operators of AS112 servers
1074 should be prepared to be contacted by operators of remote
1075 infrastructure who believe their security has been violated. Advice
1076 to those who mistakenly believe that responses from AS112 nodes
1077 constitute an attack on their infrastructure can be found in
1078 [RFC6305].
1079
1080 The deployment of AS112 nodes is very loosely coordinated compared to
1081 other services distributed using anycast. The malicious compromise
1082 of an AS112 node and subversion of the data served by the node are
1083 hence more difficult to detect due to the lack of central management.
1084 Since it is conceivable that changing the responses to queries
1085 received by AS112 nodes might influence the behaviour of the hosts
1086 sending the queries, such a compromise might be used as an attack
1087 vector against private infrastructure.
1088
1089 Operators of AS112 should take appropriate measures to ensure that
1090 AS112 nodes are appropriately protected from compromise, such as
1091 would normally be employed for production nameserver or network
1092 infrastructure. The guidance provided for root nameservers in
1093 [RFC2870] may be instructive.
1094
1095
1096
1097 Abley & Sotomayor Informational [Page 20]
1098 RFC 7534 AS112 Nameserver Operations May 2015
1099
1100
1101 The zones hosted by AS112 servers are not signed with DNSSEC
1102 [RFC4033]. Given the distributed and loosely coordinated structure
1103 of the AS112 service, the zones concerned could only be signed if the
1104 private key material used was effectively public, obviating any
1105 security benefit resulting from the use of those keys.
1106
1107 9. References
1108
1109 9.1. Normative References
1110
1111 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1112 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
1113 <http://www.rfc-editor.org/info/rfc1034>.
1114
1115 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
1116 and E. Lear, "Address Allocation for Private Internets",
1117 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
1118 <http://www.rfc-editor.org/info/rfc1918>.
1119
1120 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
1121 Name Server Operational Requirements", BCP 40, RFC 2870,
1122 DOI 10.17487/RFC2870, June 2000,
1123 <http://www.rfc-editor.org/info/rfc2870>.
1124
1125 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1126 Rose, "DNS Security Introduction and Requirements",
1127 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1128 <http://www.rfc-editor.org/info/rfc4033>.
1129
1130 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
1131 Border Gateway Protocol 4 (BGP-4)", RFC 4271,
1132 DOI 10.17487/RFC4271, January 2006,
1133 <http://www.rfc-editor.org/info/rfc4271>.
1134
1135 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
1136 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
1137 December 2006, <http://www.rfc-editor.org/info/rfc4786>.
1138
1139 [RFC7535] Abley, J., Dickson, B., Kumari, W., and G. Michaelson,
1140 "AS112 Redirection Using DNAME", RFC 7535,
1141 DOI 10.17487/RFC7535, May 2015,
1142 <http://www.rfc-editor.org/info/rfc7535>.
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152 Abley & Sotomayor Informational [Page 21]
1153 RFC 7534 AS112 Nameserver Operations May 2015
1154
1155
1156 9.2. Informative References
1157
1158 [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A
1159 Means for Expressing Location Information in the Domain
1160 Name System", RFC 1876, DOI 10.17487/RFC1876, January
1161 1996, <http://www.rfc-editor.org/info/rfc1876>.
1162
1163 [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option",
1164 RFC 5001, DOI 10.17487/RFC5001, August 2007,
1165 <http://www.rfc-editor.org/info/rfc5001>.
1166
1167 [RFC5855] Abley, J. and T. Manderson, "Nameservers for IPv4 and IPv6
1168 Reverse Zones", BCP 155, RFC 5855, DOI 10.17487/RFC5855,
1169 May 2010, <http://www.rfc-editor.org/info/rfc5855>.
1170
1171 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
1172 RFC 6303, DOI 10.17487/RFC6303, July 2011,
1173 <http://www.rfc-editor.org/info/rfc6303>.
1174
1175 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",
1176 RFC 6304, DOI 10.17487/RFC6304, July 2011,
1177 <http://www.rfc-editor.org/info/rfc6304>.
1178
1179 [RFC6305] Abley, J. and W. Maton, "I'm Being Attacked by
1180 PRISONER.IANA.ORG!", RFC 6305, DOI 10.17487/RFC6305,
1181 July 2011, <http://www.rfc-editor.org/info/rfc6305>.
1182
1183 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
1184 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
1185 <http://www.rfc-editor.org/info/rfc6672>.
1186
1187 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
1188 "Special-Purpose IP Address Registries", BCP 153,
1189 RFC 6890, DOI 10.17487/RFC6890, April 2013,
1190 <http://www.rfc-editor.org/info/rfc6890>.
1191
1192 [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249,
1193 DOI 10.17487/RFC7249, May 2014,
1194 <http://www.rfc-editor.org/info/rfc7249>.
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207 Abley & Sotomayor Informational [Page 22]
1208 RFC 7534 AS112 Nameserver Operations May 2015
1209
1210
1211 Appendix A. A Brief History of AS112
1212
1213 Widespread use of the private address blocks listed in [RFC1918]
1214 followed that document's publication in 1996. At that time, the
1215 IN-ADDR.ARPA zone was served by root servers.
1216
1217 The idea of offloading IN-ADDR.ARPA queries relating to [RFC1918]
1218 addresses from the root nameservers was first proposed by Bill
1219 Manning and John Brown.
1220
1221 The use of anycast for distributing authoritative DNS service for
1222 [RFC1918] IN-ADDR.ARPA zones was subsequently proposed at a private
1223 meeting of root server operators.
1224
1225 ARIN provided an IPv4 prefix for the anycast service and also the
1226 autonomous system number 112 for use in originating that prefix.
1227 This assignment gave the project its name.
1228
1229 In 2002, the first AS112 anycast nodes were deployed.
1230
1231 In 2011, the IN-ADDR.ARPA zone was redelegated from the root servers
1232 to a new set of servers operated independently by AfriNIC, APNIC,
1233 ARIN, ICANN, LACNIC, and the RIPE NCC and named according to
1234 [RFC5855].
1235
1236 [RFC6304], the precursor to this document, was published in
1237 July 2011.
1238
1239 The use of anycast nameservers in the AS112 project contributed to
1240 the operational experience of anycast DNS services, and it can be
1241 seen as a precursor to the anycast distribution of other
1242 authoritative DNS servers in subsequent years (e.g., various root
1243 servers).
1244
1245 Appendix B. Changes since RFC 6304
1246
1247 A number of changes and enhancements to the AS112 service has been
1248 introduced since the publication of [RFC6304].
1249
1250 o The addition of IPv6 transport.
1251
1252 o The extension of the AS112 service to include the ability to have
1253 additional zones delegated for sinking or removed using the DNAME
1254 resource record.
1255
1256 o Requisite changes to the guidance regarding the configuration of
1257 current and future AS112 nodes.
1258
1259
1260
1261
1262 Abley & Sotomayor Informational [Page 23]
1263 RFC 7534 AS112 Nameserver Operations May 2015
1264
1265
1266 o Further clarification about the leakage of information in the
1267 Security Considerations section.
1268
1269 o A direction to the IANA to register the AS112 project's prefixes
1270 in the IANA Special-Purpose Address registries.
1271
1272 Acknowledgements
1273
1274 This document benefited from review and suggestions from Leo Vegoda
1275 and Pearl Liang.
1276
1277 The authors wish to acknowledge the assistance of Bill Manning, John
1278 Brown, Marco D'Itri, Daniele Arena, Stephane Bortzmeyer, Frank
1279 Habicht, Chris Thompson, Peter Losher, Peter Koch, Alfred Hoenes, S.
1280 Moonesamy, Mehmet Akcin, and Aleksi Suhonen in the preparation of
1281 [RFC6304], which this document supersedes.
1282
1283 Authors' Addresses
1284
1285 Joe Abley
1286 Dyn, Inc.
1287 103-186 Albert Street
1288 London, ON N6A 1M1
1289 Canada
1290
1291 Phone: +1 519 670 9327
1292 EMail: jabley@dyn.com
1293
1294
1295 William F. Maton Sotomayor
1296 Ottawa Internet Exchange
1297 Constitution Square
1298 1400-340 Albert Street
1299 Ottawa, ON K1R 0A5
1300 Canada
1301
1302 EMail: wfms@ottix.net
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317 Abley & Sotomayor Informational [Page 24]
1318
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.