idnits 2.17.00 (12 Aug 2021) /tmp/idnits30035/draft-wkumari-dnsop-omniscient-as112-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 14 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6304, updated by this document, for RFC5378 checks: 2007-02-28) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 30, 2012) is 3643 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6304 (Obsoleted by RFC 7534) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Updates: 6304 (if approved) W. Sotomayor 5 Intended status: BCP NRC-CNRC 6 Expires: December 1, 2012 J. Abley 7 ICANN 8 May 30, 2012 10 Omniscient AS112 Servers 11 draft-wkumari-dnsop-omniscient-as112-00 13 Abstract 15 The AS112 Project loosely coordinates Domain Name System (DNS) 16 servers to which DNS zones corresponding to private use addresses are 17 delegated. Queries for names within those zones have no useful 18 responses in a global context. The purpose of the project is to 19 reduce the load of such junk queries on the authoritative name 20 servers that would otherwise receive them, directing the load instead 21 to name servers operated within the AS112 project. 23 Adding and dropping zones from the AS112 servers is difficult, due to 24 the loosely-coordinated nature of the project. This document 25 proposes a mechanism by which AS112 name servers could answer 26 authoritatively for all possible zones, reducing the add/drop problem 27 to one of delegation within the DNS without operational impact on the 28 servers themselves. 30 This document updates RFC 6304. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 1, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Protocol Considerations . . . . . . . . . . . . . . . . . . . 4 69 4. Operational Considerations . . . . . . . . . . . . . . . . . . 4 70 5. Addressing Considerations . . . . . . . . . . . . . . . . . . 5 71 6. Updates to RFC 6304 . . . . . . . . . . . . . . . . . . . . . 5 72 6.1. Changes to Section 3.4, Routing Software . . . . . . . . . 5 73 6.2. Changes to Section 3.5, DNS Software . . . . . . . . . . . 7 74 6.3. Changes to Section 3.6, Testing a Newly Installed Node . . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 81 Appendix A. Document Notes . . . . . . . . . . . . . . . . . . . 11 82 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 A.2. Textual Substitutions . . . . . . . . . . . . . . . . . . 11 84 A.3. Open Questions . . . . . . . . . . . . . . . . . . . . . . 11 85 A.4. Change History . . . . . . . . . . . . . . . . . . . . . . 11 86 A.4.1. draft-wkumari-dnsop-omniscient-as112-00 . . . . . . . 11 87 A.4.2. draft-wkumari-omniscient-as112-00 . . . . . . . . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 The AS112 Project loosely coordinates Domain Name System (DNS) 93 servers [RFC1034] to which DNS zones corresponding to private use 94 addresses are delegated. Queries for names within those zones have 95 no useful responses in a global context. The purpose of the project 96 is to reduce the load of such junk queries on the authoritative name 97 servers that would otherwise receive them, directing the load instead 98 to name servers operated within the AS112 project. 100 To date, AS112 nameservers have been used exclusively for names 101 corresponding to the reverse mapping for private-use IPv4 addresses. 102 A description of current advice for AS112 operators, including 103 motivations and guidance for technical deployment and operations can 104 be found in [RFC6304]. 106 Other DNS domains have analogously local significance. Examples 107 corresponding to the reverse-mapping of special-use IPv4 and IPv6 108 addresses can be found in [RFC6303]. 110 It is to be expected that new domains will be identified from time to 111 time that fit the use pattern for which delegation to AS112 servers 112 might be desirable. There is currently no mechanism by which 113 particular zones can be reliably added to or dropped from AS112 114 servers, however. This is principally a consequence of the loosely- 115 coordinated nature of the project, coupled with a desire to avoid 116 lame delegations which might have unforseen operational consequences. 118 This document proposes a mechanism by which AS112 servers could 119 provide consistent, reliable negative responses for all DNS queries, 120 eliminating the operational requirement to add or drop particular 121 zones from all AS112 servers. 123 2. Terminology 125 An "Existing AS112 Server" is a DNS name server configured according 126 to the guidance provided in [RFC6304] and listening on the IPv4 127 addresses 192.175.48.1 (PRISONER.IANA.ORG), 192.175.48.6 (BLACKHOLE- 128 1.IANA.ORG) and 192.175.48.42 (BLACKHOLE-2.IANA.ORG). 130 An "Omniscient AS112 Server" is a DNS nameserver configured according 131 to the guidance provided in [RFC6304], as extended by this document. 132 Such servers listen on the same addresses as Existing AS112 Servers, 133 but also additional addresses as described in Section 5. 135 Where discussions apply equally to Existing AS112 Servers and 136 Omniscient AS112 Servers, the unqualified phrase "AS112 Server" is 137 used. 139 An "AS112 Zone" is a DNS zone which has been delegated to an AS112 140 Server. 142 An "Existing AS112 Zone" is an AS112 Zone which has been delegated to 143 an existing AS112 Server. 145 3. Protocol Considerations 147 An AS112 Server responds with an authoritative (AA=1) name error 148 (NXDOMAIN, RCODE=3) for any query request whose (QNAME, QCLASS) falls 149 within an AS112 Zone [RFC1035]. 151 AS112 Servers do not respond to zone transfer requests (QTYPE=252). 153 The name error (NXDOMAIN) response from an Omnisicient AS112 Server 154 differs from that sent by an Existing AS112 Server in that the 155 closest enclosing SOA returned has a different owner name. Existing 156 AS112 Servers return an authority-section SOA with an owner name 157 corresponding to the apex of the AS112 Zone concerned; Omniscient 158 AS112 Servers return an SOA with an owner name of ".". This 159 difference has not been shown to cause any practical change in 160 behaviour in commonly-deployed DNS resolver software. 162 4. Operational Considerations 164 Existing AS112 Servers address the protocol considerations described 165 in Section 3 by serving each Existing AS112 Zone explicitly. In each 166 case the zone contents are identical, containing only required apex 167 SOA and NS records. Adding or dropping a delegation for an Existing 168 AS112 Zone requires coordination amongst all deployed Existing AS112 169 Server operators in order to add or drop the zone. 171 There is no practical expectation that AS112 Server operators 172 coordinate the configuration of their infrastructure or even make 173 their existence known in any systematic way. Delegation of new zones 174 to Existing AS112 Servers is hence problematic; there is an 175 expectation that such delegations would be lame for a significant 176 client population. Since the predictable behaviour of AS112 Servers 177 from clients is desirable, and it is possible that significant 178 variation would have operational consequences, no new zones should be 179 delegated to existing AS112 Servers. 181 Omniscient AS112 Servers serve an unsigned root zone, containing only 182 required apex SOA and NS records. Adding or dropping a delegation 183 for an AS112 Zone requires imposes no operational requirements on 184 Omniscient AS112 Server operators. 186 Delegation of new AS112 Zones should only be made to Omniscient AS112 187 Servers. The desire to delegate new AS112 Zones therefore imposes a 188 requirement on Omnisicient AS112 Servers to listen on addresses which 189 are different to those used by Existing AS112 Servers. Addressing is 190 discussed in Section 5. 192 By ensuring that Omnisicient AS112 Servers listen on Existing AS112 193 Servers' addresses as well as the new addresses specified in 194 Section 5 a smooth migration is possible, allowing Existing AS112 195 Servers to be reconfigured as Omnisicient AS112 Servers. Omnisicient 196 AS112 Servers are therefore a superset of AS112 Servers. 198 5. Addressing Considerations 200 Omniscient AS112 Servers listen on the following addresses: 202 o IPv4-TBA1 (A.AS112.NET) 203 o IPv6-TBA1 (A.AS112.NET) 204 o IPv4-TBA2 (B.AS112.NET) 205 o IPv6-TBA2 (B.AS112.NET) 206 o IPv4-TBA3 (C.AS112.NET) 207 o IPv6-TBA3 (C.AS112.NET) 209 Pv4-TBA1, IPv4-TBA2 and IPv4-TBA3 are covered by a single IPv4 210 prefix, IPv4-PREFIX-TBA. Similarly, IPv6-TBA1, IPv6-TBA2 and IPv6- 211 TBA3 are covered by a single IPv6 prefix, IPv6-PREFIX-TBA. 213 The addresses specified for Omnisicient AS112 Servers are 214 deliberately different from those assigned to Existing AS112 Servers 215 for reasons discussed in Section 4. 217 6. Updates to RFC 6304 219 6.1. Changes to Section 3.4, Routing Software 221 Omnisicient AS112 Nodes with IPv4 connectivity should originate the 222 IPv4 service prefix associated with Existing AS112 Nodes, 223 192.175.48.0/24, and also the IPv4 service prefix associated with 224 Omniscient AS112 Nodes, IPv4-PREFIX. 226 Omniscient AS112 Nodes with IPv6 connectivity should originate the 227 IPv6 service prefix IPv6-PREFIX-TBA. 229 Applying this direction to the "bgpd.conf" file included as an 230 example in this section results in the configuration shown in 231 Figure 1. 233 ! bgpd.conf 234 ! 235 hostname as112-bgpd 236 password 237 enable password 238 ! 239 ! Note that all AS112 nodes use the local Autonomous System 240 ! Number 112, and originate IPv4 and IPv6 prefixes (where IPv4 241 ! and IPv6 connectivity is available) as follows: 242 ! 243 ! IPv4: 192.175.48.0/24 244 ! IPv4-PREFIX-TBA 245 ! 246 ! IPv6: IPv6-PREFIX-TBA 247 ! 248 ! All other addresses shown below are illustrative, and 249 ! actual numbers will depend on local circumstances. 250 ! 251 router bgp 112 252 bgp router-id 203.0.113.1 253 ! 254 address-family ipv4 255 network 192.175.48.0 256 neighbor 192.0.2.1 remote-as 64496 257 neighbor 192.0.2.1 next-hop-self 258 neighbor 192.0.2.1 prefix-list AS112-v4 out 259 neighbor 192.0.2.1 filter-list 1 out 260 neighbor 192.0.2.2 remote-as 64497 261 neighbor 192.0.2.2 next-hop-self 262 neighbor 192.0.2.2 prefix-list AS112-v4 out 263 neighbor 192.0.2.2 filter-list 1 out 264 network 192.175.48.0/24 265 network IPv4-PREFIX-TBA 266 ! 267 address-family ipv6 unicast 268 neighbor 2001:db8::1 remote-as 64496 269 neighbor 2001:db8::1 next-hop-self 270 neighbor 2001:db8::1 prefix-list AS112-v6 out 271 neighbor 2001:db8::1 filter-list 1 out 272 neighbor 2001:db8::2 remote-as 64497 273 neighbor 2001:db8::2 next-hop-self 274 neighbor 2001:db8::2 prefix-list AS112-v6 out 275 neighbor 2001:db8::2 filter-list 1 out 276 network IPv6-PREFIX-TBA 278 ! 279 ip prefix-list AS112-v4 permit 192.175.48.0/24 280 ip prefix-list AS112-v4 permit IPv4-PREFIX-TBA 281 ! 282 ipv6 prefix-list AS112-v6 permit IPv6-PREFIX-TBA 283 ! 284 ip as-path access-list 1 permit ^$ 286 Figure 1 288 6.2. Changes to Section 3.5, DNS Software 290 Omniscient AS112 Servers with IPv4 connectivity should include DNS 291 software configured to listen on the addresses IPv4-TBA1, IPv4-TBA2 292 and IPv4-TBA3 in addition to the addresses used by Existing AS112 293 Servers. 295 Omniscient AS112 Servers with IPv6 connectivity should include DNS 296 software configured to listen on the addresses IPv6-TBA1, IPv6-TBA2 297 and IPv6-TBA3. 299 Omniscient AS112 Servers serve an empty, unsigned root zone instead 300 of explicitly serving the zones specified in [RFC6304]. 302 Applying this direction to the "named.conf" file included as an 303 example in this section results in the configuration fragment shown 304 in Figure 2. 306 options { 307 // The following configuration stanza is for Omniscient AS112 308 // Servers with IPv4 connectivity 310 listen-on { 311 127.0.0.1; // localhost 313 // The following address is node-dependent and should be set to 314 // something appropriate for the new AS112 node. 316 203.0.113.1; // local address (globally unique, unicast) 318 // the following addresses correspond to Existing AS112 Server 319 // addresses 321 192.175.48.1; // prisoner.iana.org (anycast) 322 192.175.48.6; // blackhole-1.iana.org (anycast) 323 192.175.48.42; // blackhole-2.iana.org (anycast) 325 // the following addresses are required by Omniscient AS112 Servers 326 IPv4-TBA1; // A.AS112.NET 327 IPv4-TBA2; // B.AS112.NET 328 IPv4-TBA3; // C.AS112.NET 329 }; 331 // The following configuration stanza is for Omniscient AS112 332 // Servers with IPv6 connectivity 334 listen-on-v6 { 335 ::1; // localhost 337 IPv6-TBA1; // A.AS112.NET 338 IPv6-TBA2; // B.AS112.NET 339 IPv6-TBA3; // C.AS112.NET 340 }; 342 directory "/var/named"; 343 recursion no; // authoritative-only server 344 query-source address *; 345 }; 347 // Log queries, so that when people call us about unexpected 348 // answers to queries they didn't realise they had sent, we 349 // have something to talk about. Note that activating this 350 // has the potential to create high CPU load and consume 351 // enormous amounts of disk space. 353 logging { 354 channel "querylog" { 355 file "/var/log/query.log" versions 2 size 500m; 356 print-time yes; 357 }; 358 category queries { querylog; }; 359 }; 361 // Substantially empty root zone (replaces explicit zone 362 // configuration specified in RFC 6304 for Existing AS112 Servers) 364 zone "." { 365 type master; 366 file "db.empty"; 367 }; 369 // Also answer authoritatively for the HOSTNAME.AS112.NET zone, 370 // which contains data of operational relevance. 372 zone "hostname.as112.net" { 373 type master; 374 file "db.hostname.as112.net"; 376 // No other zones should be hosted on this name server. 377 }; 379 Figure 2 381 The "db.empty" file is updated to include references to nameservers 382 used by Omniscient AS112 Servers, as shown in Figure 3. 384 ; db.empty 385 ; 386 ; Empty zone for AS112 server. 387 ; 388 $TTL 1W 389 @ IN SOA A.AS112.NET. hostmaster.root-servers.org. ( 390 1 ; serial number 391 1W ; refresh 392 1M ; retry 393 1W ; expire 394 1W ) ; negative caching TTL 395 ; 396 NS B.AS112.NET. 397 NS C.AS112.NET. 398 ; 399 ; There should be no other resource records included in this zone. 400 ; 402 Figure 3 404 6.3. Changes to Section 3.6, Testing a Newly Installed Node 406 Testing should include all configured service addresses for an 407 Omniscient AS112 Server (IPv4 or IPv6 or both, as appropriate). Note 408 that the IPv4 service addresses include those described in [RFC6304] 409 for Existing AS112 Servers. 411 7. IANA Considerations 413 This document describes infrastructure which could be used in the 414 future to direct the IANA to delegate or redelegate infrastructure 415 zones under its administrative control. 417 However, this document makes no request of the IANA. 419 8. Security Considerations 421 The contents of the Security Considerations section of [RFC6304] 422 should be reviewed, since that discussion is pertinent to the 423 operation of Omniscient AS112 Servers as well as Existing AS112 424 Servers. 426 The deployment of Omniscient AS112 Servers enables new delegations to 427 AS112 Servers. 429 Queries received by an AS112 Server might reveal operational data for 430 which there is an expectation of privacy. For example, leaked 431 queries for an organisation's internal DNS names which are sent to an 432 AS112 Server might reveal the existence of those names to the AS112 433 Server operator. The delegation of new zones to AS112 Servers has 434 the potential to increase opportunities for such unintentional 435 information leakage. 437 The delegation of new zones to AS112 Servers has the potential to 438 increase the traffic received by those servers. AS112 Server 439 operators are encouraged to monitor traffic levels, and to take 440 appropriate steps if traffic levels threaten the stability of their 441 networks. 443 9. Acknowledgements 445 The authors thank and acknowledge the contributions of Dr Paul Vixie, 446 Shane Kerr and Bill Manning in the preparation of this document. 448 10. References 450 10.1. Normative References 452 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 453 STD 13, RFC 1034, November 1987. 455 [RFC1035] Mockapetris, P., "Domain names - implementation and 456 specification", STD 13, RFC 1035, November 1987. 458 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", 459 RFC 6304, July 2011. 461 10.2. Informative References 463 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 464 RFC 6303, July 2011. 466 Appendix A. Document Notes 468 This section (and sub-sections) contain information useful for 469 development and review of this document, and should be removed prior 470 to publication. 472 A.1. Venue 474 This document is an individual submission, and is not the product of 475 an IETF working group. However, a suitable venue for discussion is 476 the dnsop working group mailing list. 478 A.2. Textual Substitutions 480 The strings "IPv4-TBA1", "IPv4-TBA2" and "IPv4-TBA3" should be 481 replaced in this document should be replaced with IPv4 addresses 482 assigned for the purpose described. The covering IPv4 prefix for all 483 three addresses should replace the string "IPv4-PREFIX-TBA". 485 Similarly, the strings "IPv6-TBA1", "IPv6-TBA2", "IPv6-TBA3" and 486 "IPv6-PREFIX-TBA" should be substituted in the text with assigned 487 production values. 489 A.3. Open Questions 491 1. Where to get IPv4 and IPv6 assignments from? There has already 492 been an assignment to DNS-OARC by ARIN for v6 service for AS112 493 servers. 495 A.4. Change History 497 A.4.1. draft-wkumari-dnsop-omniscient-as112-00 499 Document title changed to include the dnsop keyword, so that IETF 500 document automation can send courtesy notifications of document 501 actions to the dnsop working group. 503 Abstract and introduction expanded. 505 RFC2119 requirements notation removed, since this is an informational 506 document and any normative language would be toothless. 508 Discussion broken out into Protocol Considerations, Operational 509 Considerations and Addressing Considerations. 511 Detailed updates to [RFC6304] added. 513 A.4.2. draft-wkumari-omniscient-as112-00 515 Initial draft, circulated privately, not submitted. 517 Authors' Addresses 519 Warren Kumari 520 Google 521 1600 Ampitheatre Parkway 522 Mountain View, CA 94043 523 USA 525 Email: warren@kumari.net 527 William F. Maton Sotomayor 528 National Research Council of Canada 529 1200 Montreal Road 530 Ottawa, ON K1A 0R6 531 Canada 533 Phone: +1 613 993 0880 534 Email: wfms@ryouko.imsb.nrc.ca 536 Joe Abley 537 ICANN 538 12025 Waterfront Drive, Suite 300 539 Los Angeles, CA 90094-2536 540 USA 542 Phone: +1 519 670 9327 543 Email: joe.abley@icann.org