idnits 2.17.00 (12 Aug 2021) /tmp/idnits30520/draft-wkumari-dnsop-omniscient-as112-02.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 (February 25, 2013) is 3372 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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: Informational NRC-CNRC 6 Expires: August 29, 2013 J. Abley 7 ICANN 8 R. Bellis 9 Nominet UK 10 February 25, 2013 12 Omniscient AS112 Servers 13 draft-wkumari-dnsop-omniscient-as112-02 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 August 29, 2013. 50 Copyright Notice 52 Copyright (c) 2013 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" . . . . . . . . . . . 10 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 . . . . . . . 12 89 B.4.2. draft-wkumari-omniscient-as112-00 . . . . . . . . . . 13 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 92 1. Introduction 94 The AS112 Project loosely coordinates Domain Name System (DNS) 95 servers [RFC1034] to which DNS zones corresponding to private use 96 addresses are delegated. Queries for names within those zones have 97 no useful responses in a global context. The purpose of the project 98 is to reduce the load of such junk queries on the authoritative name 99 servers that would otherwise receive them, directing the load instead 100 to name servers operated within the AS112 project. 102 To date, AS112 nameservers have been used exclusively for names 103 corresponding to the reverse mapping for private-use IPv4 addresses. 104 A description of current advice for AS112 operators, including 105 motivations and guidance for technical deployment and operations can 106 be found in [RFC6304]. 108 Other DNS domains have analogously local significance. Examples 109 corresponding to the reverse-mapping of special-use IPv4 and IPv6 110 addresses can be found in [RFC6303]. 112 It is to be expected that new domains will be identified from time to 113 time that fit the use pattern for which delegation to AS112 servers 114 might be desirable. There is currently no mechanism by which 115 particular zones can be reliably added to or dropped from AS112 116 servers, however. This is principally a consequence of the loosely- 117 coordinated nature of the project, coupled with a desire to avoid 118 lame delegations which might have unforeseen operational 119 consequences. 121 This document proposes a mechanism by which AS112 servers could 122 provide consistent, reliable negative responses for all DNS queries, 123 eliminating the operational requirement to add or drop particular 124 zones from all AS112 servers. 126 2. Terminology 128 An "Existing AS112 Server" is a DNS name server configured according 129 to the guidance provided in [RFC6304] and listening on the IPv4 130 addresses 192.175.48.1 (PRISONER.IANA.ORG), 192.175.48.6 (BLACKHOLE- 131 1.IANA.ORG) and 192.175.48.42 (BLACKHOLE-2.IANA.ORG). 133 An "Omniscient AS112 Server" is a DNS nameserver configured according 134 to the guidance provided in [RFC6304], as extended by this document. 135 Such servers listen on the same addresses as Existing AS112 Servers, 136 but also additional addresses as described in Section 5. 138 Where discussions apply equally to Existing AS112 Servers and 139 Omniscient AS112 Servers, the unqualified phrase "AS112 Server" is 140 used. 142 An "AS112 Zone" is a DNS zone which has been delegated to an AS112 143 Server. 145 An "Existing AS112 Zone" is an AS112 Zone which has been delegated to 146 an existing AS112 Server. 148 3. Protocol Considerations 150 Familiarity with [RFC1034] and [RFC1035] is assumed. 152 In order to safely cache the response, DNS implementations require 153 the closest-enclosing SOA to be returned. An omniscient AS112 server 154 (which is not configured with a specific list of zones, and hence 155 zone cuts) cannot necessarily know where that is. Removing labels 156 and guessing (whether to the extreme case of removing all labels, or 157 returning one, or anything in between) cannot be guaranteed to be 158 appropriate, since the answers might clash with authentic answers 159 already present in client caches. A client that has followed a 160 referral to an omniscient AS112 server is guaranteed not to have a 161 cached SOA that matches the QNAME, however, so Omniscient AS112 162 servers use the QNAME as the SOA and owner name. 164 Please see Appendix A for information on an implementation ("running 165 code") that does this. 167 AS112 Servers do not respond to AXFR (QTYPE=252) or IXFR (QTYPE=251) 168 requests. 170 A TYPE=6 (SOA) resource record for Omniscient AS112 servers contains: 171 o MNAME = "a.as112.net." 172 o RNAME = "hostmaster.as112.net." 173 o SERIAL = 1 174 o REFRESH =604800 (7 days) 175 o RETRY = 2592000 (30 days) 176 o EXPIRE = 604800 (7 days) 177 o MINIMUM = 604800 (7 days, negative caching TTL) 179 For all queries with QTYPE=2 (NS) an AS112 Server responds with an 180 authoritative (AA=1) answer with NXDomain (RCODE=3), the owner name 181 copied from the QNAME and two resource records of TYPE=2 (NS), one 182 containing "B.AS112.NET." and the containing "C.AS112.NET.". 184 For all queries with QTYPE=6 (SOA) an AS112 Server responds with an 185 authoritative (AA=1) answer with NXDomain (RCODE=3), the owner name 186 copied from the QNAME and one (ANCOUNT=1) resource record of TYPE=6 187 (SOA). 189 For all queries with QTYPE= 255 (*, also known as ANY) an AS112 190 Server responds with an authoritative (AA=1) answer with NXDomain 191 (RCODE=3) the owner name copied from the QNAME and three (ANCOUNT=3) 192 resource records, one containing the SOA (as described above), and 193 two containing NS (also as described above). 195 For all other queries an AS112 Server responds with an authoritative 196 (AA=1) NoError (RCODE=0) with the owner name copied from the QNAME in 197 the request and no answers (ANCOUNT=0). The resource record of 198 TYPE=6 (SOA) (as described above) should be returned in the authority 199 section. The presence of the SOA is to allow the negative cache TTL 200 to be set(see [RFC2308]). 202 4. Operational Considerations 204 Existing AS112 Servers address the protocol considerations described 205 in Section 3 by serving each existing AS112 Zone explicitly. In each 206 case the zone contents are identical, containing only required apex 207 SOA and NS records. Adding or dropping a delegation for an Existing 208 AS112 Zone requires coordination amongst all deployed Existing AS112 209 Server operators. 211 There is no practical expectation that AS112 Server operators 212 coordinate the configuration of their infrastructure or even make 213 their existence known in any systematic way. Delegation of new zones 214 to Existing AS112 Servers is hence problematic; there is an 215 expectation that such delegations would be lame for a significant 216 client population. Since the predictable behaviour of AS112 Servers 217 from clients is desirable, and it is possible that significant 218 variation would have operational consequences, no new zones should be 219 delegated to existing AS112 Servers. 221 Omniscient AS112 Servers generate a response (as described in 222 Section3 (Section 3)) as though they are authoritative for everything 223 ("."). Adding or dropping a delegation for an AS112 Zone therefore 224 imposes no operational requirements on Omniscient AS112 Server 225 operators. 227 Delegation of new AS112 Zones should only be made to Omniscient AS112 228 Servers. Omniscient AS112 Servers, therefore, must listen on 229 additional addresses to those used by existing AS112 Servers. 230 Addressing is discussed in Section 5. 232 By ensuring that Omniscient AS112 Servers listen on Existing AS112 233 Servers' addresses as well as the new addresses specified in 234 Section 5 a smooth migration is possible, allowing Existing AS112 235 Servers to be reconfigured as Omniscient AS112 Servers. Omniscient 236 AS112 Servers are therefore a superset of AS112 Servers. 238 5. Addressing Considerations 240 Omniscient AS112 Servers listen on the following addresses: 242 o IPv4-TBA1 (A.AS112.NET) 243 o IPv6-TBA1 (A.AS112.NET) 244 o IPv4-TBA2 (B.AS112.NET) 245 o IPv6-TBA2 (B.AS112.NET) 246 o IPv4-TBA3 (C.AS112.NET) 247 o IPv6-TBA3 (C.AS112.NET) 249 IPv4-TBA1, IPv4-TBA2 and IPv4-TBA3 are covered by a single IPv4 250 prefix, IPv4-PREFIX-TBA. Similarly, IPv6-TBA1, IPv6-TBA2 and IPv6- 251 TBA3 are covered by a single IPv6 prefix, IPv6-PREFIX-TBA. 253 The addresses specified for Omniscient AS112 Servers are deliberately 254 different from those assigned to Existing AS112 Servers for reasons 255 discussed in Section 4. 257 6. Updates to RFC 6304 259 6.1. Changes to Section 3.4, Routing Software 261 Omniscient AS112 Nodes with IPv4 connectivity should originate the 262 IPv4 service prefix associated with Existing AS112 Nodes, 263 192.175.48.0/24, and also the IPv4 service prefix associated with 264 Omniscient AS112 Nodes, IPv4-PREFIX. 266 Omniscient AS112 Nodes with IPv6 connectivity should originate the 267 IPv6 service prefix IPv6-PREFIX-TBA. 269 Applying this direction to the "bgpd.conf" file included as an 270 example in this section results in the configuration shown in 271 Figure 1. 273 ! bgpd.conf 274 ! 275 hostname as112-bgpd 276 password 277 enable password 278 ! 279 ! Note that all AS112 nodes use the local Autonomous System 280 ! Number 112, and originate IPv4 and IPv6 prefixes (where IPv4 281 ! and IPv6 connectivity is available) as follows: 282 ! 283 ! IPv4: 192.175.48.0/24 284 ! IPv4-PREFIX-TBA 285 ! 286 ! IPv6: IPv6-PREFIX-TBA 287 ! 288 ! All other addresses shown below are illustrative, and 289 ! actual numbers will depend on local circumstances. 290 ! 291 router bgp 112 292 bgp router-id 203.0.113.1 293 ! 294 address-family ipv4 295 network 192.175.48.0 296 neighbor 192.0.2.1 remote-as 64496 297 neighbor 192.0.2.1 next-hop-self 298 neighbor 192.0.2.1 prefix-list AS112-v4 out 299 neighbor 192.0.2.1 filter-list 1 out 300 neighbor 192.0.2.2 remote-as 64497 301 neighbor 192.0.2.2 next-hop-self 302 neighbor 192.0.2.2 prefix-list AS112-v4 out 303 neighbor 192.0.2.2 filter-list 1 out 304 network 192.175.48.0/24 305 network IPv4-PREFIX-TBA 306 ! 307 address-family ipv6 unicast 308 neighbor 2001:db8::1 remote-as 64496 309 neighbor 2001:db8::1 next-hop-self 310 neighbor 2001:db8::1 prefix-list AS112-v6 out 311 neighbor 2001:db8::1 filter-list 1 out 312 neighbor 2001:db8::2 remote-as 64497 313 neighbor 2001:db8::2 next-hop-self 314 neighbor 2001:db8::2 prefix-list AS112-v6 out 315 neighbor 2001:db8::2 filter-list 1 out 316 network IPv6-PREFIX-TBA 317 ! 318 ip prefix-list AS112-v4 permit 192.175.48.0/24 319 ip prefix-list AS112-v4 permit IPv4-PREFIX-TBA 320 ! 321 ipv6 prefix-list AS112-v6 permit IPv6-PREFIX-TBA 322 ! 323 ip as-path access-list 1 permit ^$ 325 Figure 1 327 6.2. Changes to Section 3.5, DNS Software 329 Omniscient AS112 Servers should be configured to listen on the 330 addresses Pv6-TBA1, IPv6-TBA, IPv6-TBA3, IPv4-TBA1, IPv4-TBA2 and 331 IPv4-TBA3 in addition to the addresses used for Existing AS112 332 Servers. 334 Omniscient AS112 Servers generate an answer as described in Section 3 335 instead of explicitly serving the zones specified in [RFC6304]. 337 As ISC BIND [BIND] does not provide the required functionality a 338 custom nameserver implementation needs to be deployed, and so the 339 example "named.conf" file in this section can be disregarded. 341 6.3. Changes to Section 3.6, Testing a Newly Installed Node 343 Testing should include all configured service addresses for an 344 Omniscient AS112 Server (IPv4 or IPv6 or both, as appropriate). Note 345 that the IPv4 service addresses include those described in [RFC6304] 346 for Existing AS112 Servers. 348 7. IANA Considerations 350 This document describes infrastructure which could be used in the 351 future to direct the IANA to delegate or redelegate infrastructure 352 zones under its administrative control. 354 However, this document makes no request of the IANA. 356 8. Security Considerations 358 The contents of the Security Considerations section of [RFC6304] 359 should be reviewed, since that discussion is pertinent to the 360 operation of Omniscient AS112 Servers as well as Existing AS112 361 Servers. 363 The deployment of Omniscient AS112 Servers enables new delegations to 364 AS112 Servers. 366 Queries received by an AS112 Server might reveal operational data for 367 which there is an expectation of privacy. For example, leaked 368 queries for an organisation's internal DNS names which are sent to an 369 AS112 Server might reveal the existence of those names to the AS112 370 Server operator. The delegation of new zones to AS112 Servers has 371 the potential to increase opportunities for such unintentional 372 information leakage. 374 The delegation of new zones to AS112 Servers has the potential to 375 increase the traffic received by those servers. AS112 Server 376 operators are encouraged to monitor traffic levels, and to take 377 appropriate steps if traffic levels threaten the stability of their 378 networks. 380 9. Acknowledgements 382 The authors thank and acknowledge the contributions of Dr Paul Vixie, 383 Bill Manning, George Michaelson, Mark Andrews, Shane Kerr, Brian 384 Dickson, S. Moonesamy, Chris Thompson, Nick Hilliard and all the folk 385 on the AS112 Project mailing lists in the preparation of this 386 document. 388 10. References 390 10.1. Normative References 392 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 393 STD 13, RFC 1034, November 1987. 395 [RFC1035] Mockapetris, P., "Domain names - implementation and 396 specification", STD 13, RFC 1035, November 1987. 398 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 399 NCACHE)", RFC 2308, March 1998. 401 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", 402 RFC 6304, July 2011. 404 10.2. Informative References 406 [BIND] Nominet UK, "Internet Systems Consortium, "BIND"", 407 . 409 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 410 RFC 6303, July 2011. 412 [evldns] Bellis, R., "evldns", . 414 Appendix A. Implementation / "Running Code" 416 The "evldns" [evldns] library (written by Ray Bellis, Nominet UK) 417 includes an Omniscient AS112 Server implementation in the file 418 "oas112d.c" 420 Appendix B. Document Notes 422 This section (and sub-sections) contain information useful for 423 development and review of this document, and should be removed prior 424 to publication. 426 B.1. Venue 428 This document is an individual submission, and is not the product of 429 an IETF working group. However, a suitable venue for discussion is 430 the dnsop working group mailing list. 432 B.2. Textual Substitutions 434 The strings "IPv4-TBA1", "IPv4-TBA2" and "IPv4-TBA3" should be 435 replaced in this document should be replaced with IPv4 addresses 436 assigned for the purpose described. The covering IPv4 prefix for all 437 three addresses should replace the string "IPv4-PREFIX-TBA". 439 Similarly, the strings "IPv6-TBA1", "IPv6-TBA2", "IPv6-TBA3" and 440 "IPv6-PREFIX-TBA" should be substituted in the text with assigned 441 production values. 443 B.3. Open Questions 445 1. Where to get IPv4 and IPv6 assignments from? There has already 446 been an assignment to DNS-OARC by ARIN for v6 service for AS112 447 servers. 449 B.4. Change History 451 Template: 453 o Initial draft 454 o Initial draft, circulated privately, not submitted. 456 -00: 458 o Rewrote much of the document (especially Section 3 to explain how 459 (and why) resonses should be generated. 460 o Updated "Updates to RFC 6304" section to explain the BIND does not 461 currently implement this, and so named.conf, etc should be 462 ignored. 463 o Removed example "empty" zone. 464 o Changed the addressing bit at the suggestion of SM. 466 -01: 468 o Document title changed to include the dnsop keyword, so that IETF 469 document automation can send courtesy notifications of document 470 actions to the dnsop working group. 471 o Abstract and introduction expanded. 472 o RFC2119 requirements notation removed, since this is an 473 informational document and any normative language would be 474 toothless. 475 o Discussion broken out into Protocol Considerations, Operational 476 Considerations and Addressing Considerations. 477 o Reverted to the custom sowftware / synthesized answers. 478 o Added in the Ray Bellis evldns stuff. 480 -01 to -02: 482 o s/NoError/NXDomain/ -- Suggestion from Paul Vixie (and others). 483 "Nxd says there is no such name, no matter what the type was, and 484 there are no children. No data/noerror says there are either 485 other types or children or both. We know what the truth must be 486 and we know which implications we want the requestor to follow. 487 Right?" -- Paul. 488 o Need to retest with empty root zone, and "minimal responses". 489 Initial test didn't seem to suppress the 'Negative Answers from 490 Authoritative Servers' (rfc2308) 491 o Removed the ''Editor note: [NoError was chosen instead of NXDOMAIN 492 because we did not think that we could reasonably return an SOA RR 493 which clearly indicates that the QNAME does exist, and also return 494 an NXDOMAIN.]" as we are now using NXDomain :-P 495 o This version submitted by Warren, with no real discussion with co- 496 authors. Trying to squeeze things under the -01 cutoff. 498 B.4.1. draft-wkumari-dnsop-omniscient-as112-00 500 Document title changed to include the dnsop keyword, so that IETF 501 document automation can send courtesy notifications of document 502 actions to the dnsop working group. 504 Abstract and introduction expanded. 506 RFC2119 requirements notation removed, since this is an informational 507 document and any normative language would be toothless. 509 Discussion broken out into Protocol Considerations, Operational 510 Considerations and Addressing Considerations. 512 Detailed updates to [RFC6304] added. 514 B.4.2. draft-wkumari-omniscient-as112-00 516 Authors' Addresses 518 Warren Kumari 519 Google 520 1600 Ampitheatre Parkway 521 Mountain View, CA 94043 522 USA 524 Email: warren@kumari.net 526 William F. Maton Sotomayor 527 National Research Council of Canada 528 1200 Montreal Road 529 Ottawa, ON K1A 0R6 530 Canada 532 Phone: +1 613 993 0880 533 Email: wfms@ryouko.imsb.nrc.ca 535 Joe Abley 536 ICANN 537 12025 Waterfront Drive, Suite 300 538 Los Angeles, CA 90094-2536 539 USA 541 Phone: +1 519 670 9327 542 Email: joe.abley@icann.org 544 Ray Bellis 545 Nominet UK 546 Edmund Halley Road 547 Oxford, OX4 4DQ 548 United Kingdom 550 Phone: +44 1865 332211 551 Email: ray.bellis@nominet.org.uk