idnits 2.17.1 draft-ietf-dnsop-root-loopback-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 17 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 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 -- The document date (November 30, 2014) is 3434 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 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 Intended status: Informational P. Hoffman 5 Expires: June 3, 2015 VPN Consortium 6 November 30, 2014 8 Decreasing Access Time to Root Servers by Running One on Loopback 9 draft-ietf-dnsop-root-loopback-00 11 Abstract 13 Some DNS recursive resolvers have longer-than-desired round trip 14 times to the closest DNS root server. Such resolvers can greatly 15 decrease the round trip time by running a copy of the full root zone 16 on a loopback address (such as 127.0.0.1). Typically, the vast 17 majority of queries going to the root are for names that do not exist 18 in the root zone, and the negative answers are cached for a much 19 shorter period of time. This document shows how to start and 20 maintain such a copy of the root zone in a manner that is secure for 21 the operator of the recursive resolver and does not pose a threat to 22 other users of the DNS. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 3, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 60 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Operation of the Root Zone on the Loopback Address . . . . . 4 62 4. Using the Root Zone Server on the Loopback Address . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Appendix A. Current Sources of the Root Zone . . . . . . . . . . 5 70 Appendix B. Example Configurations of Common Implementations . . 6 71 B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 6 72 B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 7 73 B.3. Example Configuration: Microsoft Windows Server 2012 . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 DNS recursive resolvers have to answer all queries from their 79 customers, even those which are for domain names that do not exist. 80 For each queried name that has a top level domain (TLD) that is not 81 in the recursive resolver's cache, the resolver must send a query to 82 a root server to get the information for that TLD, or to find out 83 that the TLD does not exist. If there is a slow path between the 84 recursive resolver and the closest root server, getting slow 85 responses to these queries has a negative effect on the resolver's 86 customers. 88 This document describes a method for the operator of a recursive 89 resolver to greatly speed these queries. The basic idea is to create 90 an up-to-date root zone server on a loopback address on the same host 91 as the recursive server, and that server is used when the recursive 92 resolver uses for looking up root information. The recursive 93 resolver validates all responses from the root server on the loopback 94 address, just as it would all responses from a remote root server. 96 The primary goal of this design is to provide faster negative 97 responses to stub resolver queries that contain junk queries. This 98 design will probably have little effect on getting faster positive 99 responses to stub resolver for good queries on TLDs, because the data 100 for those zones is usually long-lived and already in the cache of the 101 recursive resolver; thus, getting faster positive responses is a non- 102 goal of this design. 104 This design explicitly only allows the new root zone server to be run 105 on a loopback address. This prevents the server from serving 106 authoritative answers to any system other than the recursive 107 resolver. 109 This design requires the addition of authoritative name server 110 software running on the same machine as the recursive resolver. 111 Thus, recursive resolver software such as BIND will not need to add 112 much new functionality, but recursive resolver software such as 113 Unbound will need to be able to talk to an authoritative server (such 114 as NSD) running on the same host. 116 1.1. Requirements Notation 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2. Requirements 124 In order to implement the mechanism described in this document: 126 o The system MUST be able to validate a zone with DNSSEC. 128 o The system MUST have an up-to-date copy of the DNS root key. 130 o The system MUST be able to retrieve a copy of the entire root zone 131 (including all DNSSEC-related records). 133 o The system MUST be able to run an authoritative server on one of 134 the IPv4 loopback addresses (that is, an address in the range 135 127/8). 137 A corollary of the above list is that authoritative data in the root 138 zone used on the local authoritative server MUST be identical to the 139 same data in the root zone for the DNS. It is possible to change the 140 unsigned data (the glue records) in the copy of the root zone, but 141 such changes are likely to cause problems for the recursive server 142 that accesses the local root zone. 144 3. Operation of the Root Zone on the Loopback Address 146 The operation of an authoritative server for the root in the system 147 described here can be done separately from the operation of the 148 recursive resolver. 150 The steps to set up the root zone are: 152 1. Retrieve a copy of the root zone. (See Appendix A for some 153 current locations of sources.) 155 2. Start the authoritative server with the root zone on a loopback 156 address that is not in use. This would typically be 127.0.0.1, 157 but if that address is in use, any address in 127/8 is 158 acceptable. 160 The contents of the root zone must be refreshed using the timers from 161 the SOA record in root zone, as described in [RFC1035]. If the 162 contents of the zone cannot be refreshed before the expire time, the 163 server MUST return a SERVFAIL error response for all queries until 164 the zone can be successfully be set up again. 166 4. Using the Root Zone Server on the Loopback Address 168 A recursive resolver that wants to use a root zone server operating 169 as described in Section 3 simply specifies the local address as the 170 place to look when it is looking for information from the root. All 171 responses from the root server must be validated using DNSSEC. 173 Note that using this configuration will cause the recursive resolver 174 to fail if the local root zone server fails. See Appendix B for more 175 discussion of this for specific software. 177 To test the proper operation of the recursive resolver with the local 178 root server, use a DNS client to send a query for the SOA of the root 179 to the recursive server. Make sure the response that comes back does 180 not have the AD bit in the message header set. 182 5. IANA Considerations 184 This document requires no action from the IANA. 186 6. Security Considerations 188 A system that does not follow the DNSSEC-related requirements given 189 in Section 2 can be fooled into giving bad responses in the same way 190 as any recursive resolver that does not do DNSSEC validation on 191 responses from a remote root server. 193 7. Acknowledgements 195 The editors fully acknowledge that this is not a new concept, and 196 that we have chatted with many people about this. In fact, this 197 concept may already have been implemented without the knowledge of 198 the authors. For example, Bill Manning described a similar solution 199 but to a very different problem (intermittent connectivity, instead 200 of constant but slow connectivity) in his doctoral dissertation in 201 2013 [Manning2013]. 203 Evan Hunt contributed greatly to the logic in the requirements. 204 Other significant contributors include Wouter Wijngaards, Tony Hain, 205 Doug Barton, and Greg Lindsay. 207 8. References 209 8.1. Normative References 211 [RFC1035] Mockapetris, P., "Domain names - implementation and 212 specification", STD 13, RFC 1035, November 1987. 214 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 215 Requirement Levels", BCP 14, RFC 2119, March 1997. 217 8.2. Informative References 219 [Manning2013] 220 Maning, W., "Client Based Naming", 2013, 221 . 223 Appendix A. Current Sources of the Root Zone 225 The root zone can be retrieved from anywhere as long as it comes with 226 all the DNSSEC records needed for validation. Currently, there are 227 three sources of the root zone supported by ICANN: 229 o From ICANN via FTP at ftp://rs.internic.net/domain/root.zone 231 o From ICANN via HTTP at http://www.internic.net/domain/root.zone 233 o From ICANN by AXFR from DNS servers at xfr.lax.dns.icann.org and 234 xfr.cjr.dns.icann.org 236 Currently, the root can be retrieved by zone transfer (AXFR) from the 237 following root server operators: 239 o b.root-servers.net 240 o c.root-servers.net 242 o f.root-servers.net 244 o g.root-servers.net 246 o k.root-servers.net 248 Appendix B. Example Configurations of Common Implementations 250 This section shows fragments of configurations for some popular 251 recursive server software that is believed to correctly implement the 252 requirements given in this document. 254 The IPv4 and IPv6 addresses in this section were checked recently by 255 testing for AXFR over TCP from each address for the known single- 256 letter names in the root-servers.net zone. 258 The examples here use a loopback address of 127.12.12.12, but typical 259 installations will use 127.0.0.1. The different address is used in 260 order to emphasize that the root server does not need to be on the 261 device at "localhost". 263 B.1. Example Configuration: BIND 9.9 265 BIND acts both as a recursive resolver and an authoritative server. 266 Because of this, there is "fate sharing" between the two servers in 267 the following configuration. That is, if the root server dies, it is 268 likely that all of BIND is dead. 270 Using this configuration, queries for information in the root zone 271 are returned with the AA bit not set. 273 When slaving a zone, BIND will treat zone data differently if it is 274 slaved into a separate view (or a separate instance of the software) 275 versus slaving the zone into the same view or instance that is also 276 performing the recursion. 278 Validation: When using separate views or separate instances, the DS 279 records in the slaved zone will be validated as the zone data is 280 accessed by the recursive server. When using the same view, this 281 validation does not occur for the slaved zone. 283 Caching: When using separate views or instances, the recursive 284 server will cache all of the queries for the slaved zone, just as 285 it would using the traditional root hints method. Thus, as the 286 zone in the other view or instance is refreshed or updated, 287 changed information will not appear in the recursive server until 288 the TTL of the old record times out. Currently the TTL for DS and 289 delegation NS records is two days. When using the same view, all 290 zone data in the recursive server will be updated as soon as it 291 receives its copy of the zone. 293 view root { 294 match-destinations { 127.12.12.12; }; 295 zone "." { 296 type slave; 297 file "rootzone.db"; 298 notify no; 299 masters { 300 192.228.79.201; # b.root-servers.net 301 192.33.4.12; # c.root-servers.net 302 192.5.5.241; # f.root-servers.net 303 192.112.36.4; # g.root-servers.net 304 193.0.14.129; # k.root-servers.net 305 2001:500:84::b; # b.root-servers.net 306 2001:500:2f::f; # f.root-servers.net 307 2001:7fd::1; # k.root-servers.net 308 }; 309 }; 310 }; 312 view recursive { 313 dnssec-validation auto; 314 allow-recursion { any; }; 315 recursion yes; 316 zone "." { 317 type static-stub; 318 server-addresses { 127.12.12.12; }; 319 }; 320 }; 322 B.2. Example Configuration: Unbound 1.4 and NSD 4 324 Unbound and NSD are separate software packages. Because of this, 325 there is no "fate sharing" between the two servers in the following 326 configurations. That is, if the root server instance (NSD) dies, the 327 recursive resolver instance (Unbound) will probably keep running, but 328 will not be able to resolve any queries for the root zone. 329 Therefore, the administrator of this configuration might want to 330 carefully monitor the NSD instance and restart it immediately if it 331 dies. 333 Using this configuration, queries for information in the root zone 334 are returned with the AA bit not set. 336 # Configuration for Unbound 337 server: 338 do-not-query-localhost: no 339 stub-zone: 340 name: "." 341 stub-prime: no 342 stub-addr: 127.12.12.12 344 # Configuration for NSD 345 server: 346 ip-address: 127.12.12.12 347 zone: 348 name: "." 349 request-xfr: 192.228.79.201 NOKEY # b.root-servers.net 350 request-xfr: 192.33.4.12 NOKEY # c.root-servers.net 351 request-xfr: 192.5.5.241 NOKEY # f.root-servers.net 352 request-xfr: 192.112.36.4 NOKEY # g.root-servers.net 353 request-xfr: 193.0.14.129 NOKEY # k.root-servers.net 354 request-xfr: 2001:500:84::b NOKEY # b.root-servers.net 355 request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net 356 request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net 358 B.3. Example Configuration: Microsoft Windows Server 2012 360 Windows Server 2012 contains a DNS server in the "DNS Manager" 361 component. When activated, that component acts as a recursive 362 server. DNS Manager can also act as an authoritative server. 364 Using this configuration, queries for information in the root zone 365 are returned with the AA bit set. 367 The steps to configure DNS Manager to implement the requirements in 368 this document are: 370 1. Launch the DNS Manager GUI. This can be done from the command 371 line ("dnsmgmt.msc") or from the Service Manager (the "DNS" 372 command in the "Tools" menu). 374 2. In the hierarchy under the server on which the service is 375 running, right-click on the "Forward Lookup Zones", and select 376 "New Zone". This brings up a succession of dialog boxes. 378 3. In the "Zone Type" dialog box, select "Secondary zone". 380 4. In the "Zone Name" dialog box, enter ".". 382 5. In the "Master DNS Servers" dialog box, enter "b.root- 383 servers.net". The system validates that it can do a zone 384 transfer from that server. (After this configuration is 385 completed, DNS Manager will attempt to transfer from all of the 386 root zone servers.) 388 6. In the "Completing the New Zone Wizard" dialog box, click 389 "Finish". 391 7. Verify that the DNS Manager is acting as a recursive resolver. 392 Right-click on the server name in the hierarch, choosing the 393 "Advanced" tab in the dialog box. See that "Disable recursion 394 (also disables forwarders)" is not selected, and that "Enable 395 DNSSEC validation for remote responses" is selected. 397 Authors' Addresses 399 Warren Kumari 400 Google 402 Email: Warren@kumari.net 404 Paul Hoffman 405 VPN Consortium 407 Email: paul.hoffman@vpnc.org