idnits 2.17.00 (12 Aug 2021) /tmp/idnits29640/draft-wkumari-dnsop-omniscient-as112-01.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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 7 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 (August 29, 2012) is 3552 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'BIND' is defined on line 413, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6304 (Obsoleted by RFC 7534) Summary: 1 error (**), 0 flaws (~~), 4 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: Informational NRC-CNRC 6 Expires: March 2, 2013 J. Abley 7 ICANN 8 R. Bellis 9 Nominet UK 10 August 29, 2012 12 Omniscient AS112 Servers 13 draft-wkumari-dnsop-omniscient-as112-01 15 Abstract 17 The AS112 Project loosely coordinates Domain Name System (DNS) 18 servers to which DNS zones corresponding to private use addresses are 19 delegated. Queries for names within those zones have no useful 20 responses in a global context. The purpose of this project is to 21 reduce the load of such junk queries on the authoritative name 22 servers that would otherwise receive them, and instead direct the 23 load to name servers operated within the AS112 project. 25 Adding and dropping zones from the AS112 servers is difficult, due to 26 the loosely-coordinated nature of the project. This document 27 proposes a mechanism by which AS112 name servers could answer 28 authoritatively for all possible zones. This eliminates the add/drop 29 problem, changing it to a matter of delegation within the DNS and 30 requiring no operational changes on the servers themselves. 32 This document updates RFC 6304. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 2, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Protocol Considerations . . . . . . . . . . . . . . . . . . . 5 70 4. Operational Considerations . . . . . . . . . . . . . . . . . . 6 71 5. Addressing Considerations . . . . . . . . . . . . . . . . . . 7 72 6. Updates to RFC 6304 . . . . . . . . . . . . . . . . . . . . . 7 73 6.1. Changes to Section 3.4, Routing Software . . . . . . . . . 7 74 6.2. Changes to Section 3.5, DNS Software . . . . . . . . . . . 9 75 6.3. Changes to Section 3.6, Testing a Newly Installed Node . . 9 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 Appendix A. Implementation / "Running Code" . . . . . . . . . . . 11 83 Appendix B. Document Notes . . . . . . . . . . . . . . . . . . . 11 84 B.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 B.2. Textual Substitutions . . . . . . . . . . . . . . . . . . 11 86 B.3. Open Questions . . . . . . . . . . . . . . . . . . . . . . 11 87 B.4. Change History . . . . . . . . . . . . . . . . . . . . . . 11 88 B.4.1. draft-wkumari-dnsop-omniscient-as112-00 . . . . . . . 11 89 B.4.2. draft-wkumari-dnsop-omniscient-as112-00 . . . . . . . 12 90 B.4.3. draft-wkumari-omniscient-as112-00 . . . . . . . . . . 12 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 The AS112 Project loosely coordinates Domain Name System (DNS) 96 servers [RFC1034] to which DNS zones corresponding to private use 97 addresses are delegated. Queries for names within those zones have 98 no useful responses in a global context. The purpose of the project 99 is to reduce the load of such junk queries on the authoritative name 100 servers that would otherwise receive them, directing the load instead 101 to name servers operated within the AS112 project. 103 To date, AS112 nameservers have been used exclusively for names 104 corresponding to the reverse mapping for private-use IPv4 addresses. 105 A description of current advice for AS112 operators, including 106 motivations and guidance for technical deployment and operations can 107 be found in [RFC6304]. 109 Other DNS domains have analogously local significance. Examples 110 corresponding to the reverse-mapping of special-use IPv4 and IPv6 111 addresses can be found in [RFC6303]. 113 It is to be expected that new domains will be identified from time to 114 time that fit the use pattern for which delegation to AS112 servers 115 might be desirable. There is currently no mechanism by which 116 particular zones can be reliably added to or dropped from AS112 117 servers, however. This is principally a consequence of the loosely- 118 coordinated nature of the project, coupled with a desire to avoid 119 lame delegations which might have unforeseen operational 120 consequences. 122 This document proposes a mechanism by which AS112 servers could 123 provide consistent, reliable negative responses for all DNS queries, 124 eliminating the operational requirement to add or drop particular 125 zones from all AS112 servers. 127 2. Terminology 129 An "Existing AS112 Server" is a DNS name server configured according 130 to the guidance provided in [RFC6304] and listening on the IPv4 131 addresses 192.175.48.1 (PRISONER.IANA.ORG), 192.175.48.6 (BLACKHOLE- 132 1.IANA.ORG) and 192.175.48.42 (BLACKHOLE-2.IANA.ORG). 134 An "Omniscient AS112 Server" is a DNS nameserver configured according 135 to the guidance provided in [RFC6304], as extended by this document. 136 Such servers listen on the same addresses as Existing AS112 Servers, 137 but also additional addresses as described in Section 5. 139 Where discussions apply equally to Existing AS112 Servers and 140 Omniscient AS112 Servers, the unqualified phrase "AS112 Server" is 141 used. 143 An "AS112 Zone" is a DNS zone which has been delegated to an AS112 144 Server. 146 An "Existing AS112 Zone" is an AS112 Zone which has been delegated to 147 an existing AS112 Server. 149 3. Protocol Considerations 151 Familiarity with [RFC1034] and [RFC1035] is assumed. 153 In order to safely cache the response, DNS implementations require 154 the closest-enclosing SOA to be returned. An omniscient AS112 server 155 (which is not configured with a specific list of zones, and hence 156 zone cuts) cannot necessarily know where that is. Removing labels 157 and guessing (whether to the extreme case of removing all labels, or 158 returning one, or anything in between) cannot be guaranteed to be 159 appropriate, since the answers might clash with authentic answers 160 already present in client caches. A client that has followed a 161 referral to an omniscient AS112 server is guaranteed not to have a 162 cached SOA that matches the QNAME, however, so Omnicinet AS112 163 servers use the QNAME as the SOA and owner name. 165 Please see Appendix A for information on an implementation ("running 166 code") that does this. 168 AS112 Servers do not respond to AXFR (QTYPE=252) or IXFR (QTYPE=251) 169 requests. 171 A TYPE=6 (SOA) resource record for Omniscient AS112 servers contains: 172 o MNAME = "a.as112.net." 173 o RNAME = "hostmaster.as112.net." 174 o SERIAL = 1 175 o REFRESH =604800 (7 days) 176 o RETRY = 2592000 (30 days) 177 o EXPIRE = 604800 (7 days) 178 o MINIMUM = 604800 (7 days, negative caching TTL) 180 For all queries with QTYPE=2 (NS) an AS112 Server responds with an 181 authoritative (AA=1) answer with NoError (RCODE=0), the owner name 182 copied from the QNAME and two resource records of TYPE=2 (NS), one 183 containing "B.AS112.NET." and the containing "C.AS112.NET.". 185 For all queries with QTYPE=6 (SOA) an AS112 Server responds with an 186 authoritative (AA=1) answer with NoError (RCODE=0), the owner name 187 copied from the QNAME and one (ANCOUNT=1) resource record of TYPE=6 188 (SOA). 190 For all queries with QTYPE= 255 (*, also known as ANY) an AS112 191 Server responds with an authoritative (AA=1) answer with NoError 192 (RCODE=0) the owner name copied from the QNAME and three (ANCOUNT=3) 193 resource records, one containing the SOA (as described above), and 194 two containing NS (also as described above). 196 For all other queries an AS112 Server responds with an authoritative 197 (AA=1) NoError (RCODE=0) with the owner name copied from the QNAME in 198 the request and no answers (ANCOUNT=0). The resource record of 199 TYPE=6 (SOA) (as described above) should be returned in the authority 200 section. The presence of the SOA is to allow the negative cache TTL 201 to be set(see [RFC2308]). 203 *** Editor note -- below paragraph be removed prior to publication. 204 It is here just to provide some background and to head off onlist 205 discussions :-P *** 207 [NoError was chosen instead of NXDOMAIN because we did not think that 208 we could reasonably return an SOA RR which clearly indicates that the 209 QNAME does exist, and also return an NXDOMAIN.] 211 4. Operational Considerations 213 Existing AS112 Servers address the protocol considerations described 214 in Section 3 by serving each existing AS112 Zone explicitly. In each 215 case the zone contents are identical, containing only required apex 216 SOA and NS records. Adding or dropping a delegation for an Existing 217 AS112 Zone requires coordination amongst all deployed Existing AS112 218 Server operators. 220 There is no practical expectation that AS112 Server operators 221 coordinate the configuration of their infrastructure or even make 222 their existence known in any systematic way. Delegation of new zones 223 to Existing AS112 Servers is hence problematic; there is an 224 expectation that such delegations would be lame for a significant 225 client population. Since the predictable behaviour of AS112 Servers 226 from clients is desirable, and it is possible that significant 227 variation would have operational consequences, no new zones should be 228 delegated to existing AS112 Servers. 230 Omniscient AS112 Servers generate a response (as described in 231 Section3 (Section 3)) as though they are authoritative for everything 232 ("."). Adding or dropping a delegation for an AS112 Zone therefore 233 imposes no operational requirements on Omniscient AS112 Server 234 operators. 236 Delegation of new AS112 Zones should only be made to Omniscient AS112 237 Servers. Omniscient AS112 Servers, therefore, must listen on 238 additional addresses to those used by existing AS112 Servers. 239 Addressing is discussed in Section 5. 241 By ensuring that Omniscient AS112 Servers listen on Existing AS112 242 Servers' addresses as well as the new addresses specified in 243 Section 5 a smooth migration is possible, allowing Existing AS112 244 Servers to be reconfigured as Omniscient AS112 Servers. Omniscient 245 AS112 Servers are therefore a superset of AS112 Servers. 247 5. Addressing Considerations 249 Omniscient AS112 Servers listen on the following addresses: 251 o IPv4-TBA1 (A.AS112.NET) 252 o IPv6-TBA1 (A.AS112.NET) 253 o IPv4-TBA2 (B.AS112.NET) 254 o IPv6-TBA2 (B.AS112.NET) 255 o IPv4-TBA3 (C.AS112.NET) 256 o IPv6-TBA3 (C.AS112.NET) 258 IPv4-TBA1, IPv4-TBA2 and IPv4-TBA3 are covered by a single IPv4 259 prefix, IPv4-PREFIX-TBA. Similarly, IPv6-TBA1, IPv6-TBA2 and IPv6- 260 TBA3 are covered by a single IPv6 prefix, IPv6-PREFIX-TBA. 262 The addresses specified for Omniscient AS112 Servers are deliberately 263 different from those assigned to Existing AS112 Servers for reasons 264 discussed in Section 4. 266 6. Updates to RFC 6304 268 6.1. Changes to Section 3.4, Routing Software 270 Omniscient AS112 Nodes with IPv4 connectivity should originate the 271 IPv4 service prefix associated with Existing AS112 Nodes, 272 192.175.48.0/24, and also the IPv4 service prefix associated with 273 Omniscient AS112 Nodes, IPv4-PREFIX. 275 Omniscient AS112 Nodes with IPv6 connectivity should originate the 276 IPv6 service prefix IPv6-PREFIX-TBA. 278 Applying this direction to the "bgpd.conf" file included as an 279 example in this section results in the configuration shown in 280 Figure 1. 282 ! bgpd.conf 283 ! 284 hostname as112-bgpd 285 password 286 enable password 287 ! 288 ! Note that all AS112 nodes use the local Autonomous System 289 ! Number 112, and originate IPv4 and IPv6 prefixes (where IPv4 290 ! and IPv6 connectivity is available) as follows: 291 ! 292 ! IPv4: 192.175.48.0/24 293 ! IPv4-PREFIX-TBA 294 ! 295 ! IPv6: IPv6-PREFIX-TBA 296 ! 297 ! All other addresses shown below are illustrative, and 298 ! actual numbers will depend on local circumstances. 299 ! 300 router bgp 112 301 bgp router-id 203.0.113.1 302 ! 303 address-family ipv4 304 network 192.175.48.0 305 neighbor 192.0.2.1 remote-as 64496 306 neighbor 192.0.2.1 next-hop-self 307 neighbor 192.0.2.1 prefix-list AS112-v4 out 308 neighbor 192.0.2.1 filter-list 1 out 309 neighbor 192.0.2.2 remote-as 64497 310 neighbor 192.0.2.2 next-hop-self 311 neighbor 192.0.2.2 prefix-list AS112-v4 out 312 neighbor 192.0.2.2 filter-list 1 out 313 network 192.175.48.0/24 314 network IPv4-PREFIX-TBA 315 ! 316 address-family ipv6 unicast 317 neighbor 2001:db8::1 remote-as 64496 318 neighbor 2001:db8::1 next-hop-self 319 neighbor 2001:db8::1 prefix-list AS112-v6 out 320 neighbor 2001:db8::1 filter-list 1 out 321 neighbor 2001:db8::2 remote-as 64497 322 neighbor 2001:db8::2 next-hop-self 323 neighbor 2001:db8::2 prefix-list AS112-v6 out 324 neighbor 2001:db8::2 filter-list 1 out 325 network IPv6-PREFIX-TBA 326 ! 327 ip prefix-list AS112-v4 permit 192.175.48.0/24 328 ip prefix-list AS112-v4 permit IPv4-PREFIX-TBA 329 ! 330 ipv6 prefix-list AS112-v6 permit IPv6-PREFIX-TBA 331 ! 332 ip as-path access-list 1 permit ^$ 334 Figure 1 336 6.2. Changes to Section 3.5, DNS Software 338 Omniscient AS112 Servers should be configured to listen on the 339 addresses Pv6-TBA1, IPv6-TBA, IPv6-TBA3, IPv4-TBA1, IPv4-TBA2 and 340 IPv4-TBA3 in addition to the addresses used for Existing AS112 341 Servers. 343 Omniscient AS112 Servers generate an answer as described in Section 3 344 instead of explicitly serving the zones specified in [RFC6304]. 346 As ISC BIND [BIND]does not provide the required functionality a 347 custom nameserver implementation needs to be deployed, and so the 348 example "named.conf" file in this section can be disregarded. 350 6.3. Changes to Section 3.6, Testing a Newly Installed Node 352 Testing should include all configured service addresses for an 353 Omniscient AS112 Server (IPv4 or IPv6 or both, as appropriate). Note 354 that the IPv4 service addresses include those described in [RFC6304] 355 for Existing AS112 Servers. 357 7. IANA Considerations 359 This document describes infrastructure which could be used in the 360 future to direct the IANA to delegate or redelegate infrastructure 361 zones under its administrative control. 363 However, this document makes no request of the IANA. 365 8. Security Considerations 367 The contents of the Security Considerations section of [RFC6304] 368 should be reviewed, since that discussion is pertinent to the 369 operation of Omniscient AS112 Servers as well as Existing AS112 370 Servers. 372 The deployment of Omniscient AS112 Servers enables new delegations to 373 AS112 Servers. 375 Queries received by an AS112 Server might reveal operational data for 376 which there is an expectation of privacy. For example, leaked 377 queries for an organisation's internal DNS names which are sent to an 378 AS112 Server might reveal the existence of those names to the AS112 379 Server operator. The delegation of new zones to AS112 Servers has 380 the potential to increase opportunities for such unintentional 381 information leakage. 383 The delegation of new zones to AS112 Servers has the potential to 384 increase the traffic received by those servers. AS112 Server 385 operators are encouraged to monitor traffic levels, and to take 386 appropriate steps if traffic levels threaten the stability of their 387 networks. 389 9. Acknowledgements 391 The authors thank and acknowledge the contributions of Dr Paul Vixie, 392 Bill Manning, George Michaelson, Mark Andrews, Shane Kerr and S. 393 Moonesamy in the preparation of this document. 395 10. References 397 10.1. Normative References 399 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 400 STD 13, RFC 1034, November 1987. 402 [RFC1035] Mockapetris, P., "Domain names - implementation and 403 specification", STD 13, RFC 1035, November 1987. 405 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 406 NCACHE)", RFC 2308, March 1998. 408 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", 409 RFC 6304, July 2011. 411 10.2. Informative References 413 [BIND] Nominet UK, "Internet Systems Consortium, "BIND"", 414 . 416 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 417 RFC 6303, July 2011. 419 [evldns] Bellis, R., "evldns", . 421 Appendix A. Implementation / "Running Code" 423 The "evldns" [evldns] library (written by Ray Bellis, Nominet UK) 424 includes an Omniscient AS112 Server implementation in the file 425 "oas112d.c" 427 Appendix B. Document Notes 429 This section (and sub-sections) contain information useful for 430 development and review of this document, and should be removed prior 431 to publication. 433 B.1. Venue 435 This document is an individual submission, and is not the product of 436 an IETF working group. However, a suitable venue for discussion is 437 the dnsop working group mailing list. 439 B.2. Textual Substitutions 441 The strings "IPv4-TBA1", "IPv4-TBA2" and "IPv4-TBA3" should be 442 replaced in this document should be replaced with IPv4 addresses 443 assigned for the purpose described. The covering IPv4 prefix for all 444 three addresses should replace the string "IPv4-PREFIX-TBA". 446 Similarly, the strings "IPv6-TBA1", "IPv6-TBA2", "IPv6-TBA3" and 447 "IPv6-PREFIX-TBA" should be substituted in the text with assigned 448 production values. 450 B.3. Open Questions 452 1. Where to get IPv4 and IPv6 assignments from? There has already 453 been an assignment to DNS-OARC by ARIN for v6 service for AS112 454 servers. 456 B.4. Change History 458 B.4.1. draft-wkumari-dnsop-omniscient-as112-00 460 o Rewrote much of the document (especially Section 3 to explain how 461 (and why) resonses should be generated. 462 o Updated "Updates to RFC 6304" section to explain the BIND does not 463 currently implement this, and so named.conf, etc should be 464 ignored. 465 o Removed example "empty" zone. 467 o Changed the addressing bit at the suggestion of SM. 469 B.4.2. draft-wkumari-dnsop-omniscient-as112-00 471 Document title changed to include the dnsop keyword, so that IETF 472 document automation can send courtesy notifications of document 473 actions to the dnsop working group. 475 Abstract and introduction expanded. 477 RFC2119 requirements notation removed, since this is an informational 478 document and any normative language would be toothless. 480 Discussion broken out into Protocol Considerations, Operational 481 Considerations and Addressing Considerations. 483 Detailed updates to [RFC6304] added. 485 B.4.3. draft-wkumari-omniscient-as112-00 487 Initial draft, circulated privately, not submitted. 489 Authors' Addresses 491 Warren Kumari 492 Google 493 1600 Ampitheatre Parkway 494 Mountain View, CA 94043 495 USA 497 Email: warren@kumari.net 499 William F. Maton Sotomayor 500 National Research Council of Canada 501 1200 Montreal Road 502 Ottawa, ON K1A 0R6 503 Canada 505 Phone: +1 613 993 0880 506 Email: wfms@ryouko.imsb.nrc.ca 507 Joe Abley 508 ICANN 509 12025 Waterfront Drive, Suite 300 510 Los Angeles, CA 90094-2536 511 USA 513 Phone: +1 519 670 9327 514 Email: joe.abley@icann.org 516 Ray Bellis 517 Nominet UK 518 Edmund Halley Road 519 Oxford, OX4 4DQ 520 United Kingdom 522 Phone: +44 1865 332211 523 Email: ray.bellis@nominet.org.uk