RFC 7706
Decreasing Access Time to Root Servers by Running One on Loopback
RFC 7706 💖 Decreasing Access Time to Root Servers by Running One on Loopback
okay bestie, this is RFC 7706, and it's giving "fix your slow DNS root lookups without letting strangers snoop on them" 👀✨ it was published in November 2015 as an Informational doc by the IETF (Internet Engineering Task Force), with W. Kumari from Google and P. Hoffman from ICANN as the authors. The ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's a standalone little gem 🦋
Abstract ✨
so some DNS recursive resolvers have round-trip times to their closest root server that are longer than they'd like 😩 and some operators also want to stop third parties from snooping on the requests they send to the root servers 👀 the fix here is to run a full copy of the root zone on a loopback address (like 127.0.0.1), which makes things way faster and keeps the requests hidden 🫶 the catch is that the operator gets some extra operational fragility, so this doc shows how to start and keep that copy running without threatening anyone else using DNS 💅
Status of This Memo
this doc is not an Internet Standards Track spec, it's just published for information 🎀
it's a product of the IETF, so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard though, so see Section 2 of RFC 5741 for the details 🧐
info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7706 🌸
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. please actually read those, bc they spell out your rights and restrictions 📜 and if you pull Code Components out of this doc, they have to include the Simplified BSD License text (per Section 4.e of the Trust Legal Provisions) and come with no warranty, as the Simplified BSD License describes 🫶
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation of the Root Zone on the Loopback Address . . . . . 5
4. Using the Root Zone Server on the Loopback Address . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Current Sources of the Root Zone . . . . . . . . . . 8
Appendix B. Example Configurations of Common Implementations . . 8
B.1. Example Configuration: BIND 9.9 . . . . . . . . . . . . . 9
B.2. Example Configuration: Unbound 1.4 and NSD 4 . . . . . . 10
B.3. Example Configuration: Microsoft Windows Server 2012 . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 121. Introduction 🌈
okay so recursive resolvers have to answer every single query from their customers, even the ones for domain names that don't exist 😭 for any queried name whose top-level domain (TLD) isn't in the resolver's cache, the resolver has to send a query to a root server to either get the info for that TLD or find out it doesn't exist. the wild part is that the vast majority of queries hitting the root are for names that aren't in the root zone at all, and those negative answers only get cached for a much shorter time 💀 so a slow path between the resolver and its closest root server really hurts the resolver's customers 😩
right now, resolvers send queries for every TLD that isn't in their caches to the root servers, even though most of those get referrals to other servers 🙈 that means malicious third parties might be able to watch that traffic on the network between the resolver and one or more of the DNS roots 👀
this doc describes a method for a recursive resolver operator to speed these queries up a lot and hide them from outsiders 💅 the basic idea is to make an up-to-date root zone server on a loopback address on the same host as the recursive server, then have the resolver use that server when it looks up root info. the resolver validates all responses from the loopback root server just like it would from a remote one 🫶
the main goals are faster negative responses to stub resolver queries that contain junk queries, and keeping queries and responses from being visible on the network ✨ this design probably won't do much for faster positive responses for good TLD queries, since that data is usually long-lived and already cached in the resolver. so faster positive responses are explicitly a non-goal here 🎀
this design only allows the new root zone server to run on a loopback address. the reason is to stop it from serving authoritative answers to anyone other than the recursive resolver 🔒
⚠️ real talk: this is not considered a "best practice." lots of people think it's excessively risky because it adds a brand new operational piece to local DNS where there wasn't one before 😬 those advantages don't come free. if this new system doesn't work correctly, users can get bad data, or the whole recursive resolution system can fail in ways that are super hard to diagnose 💀
this design needs authoritative name server software running on the same machine as the recursive resolver. so recursive resolver software like BIND won't need to add much new functionality, but recursive resolver software like Unbound will need to be able to talk to an authoritative server (like NSD) running on the same host 🧚
because of the big operational risks in this doc, distributions of recursive DNS servers MUST NOT include configuration for the design described here 🚫 it's fine to point people to this doc, but you can't indicate that this config is something to consider without reading the entire document first 📖
a different approach to these same problems is described in [AggressiveNSEC] 🦋
1.1. Requirements Notation 📝
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 💜
2. Requirements 💅
to implement the mechanism in this doc, you need all of these:
- The system MUST be able to validate a zone with DNSSEC [RFC4033]. 🔐
- The system MUST have an up-to-date copy of the DNS root key. 🗝️
- The system MUST be able to retrieve a copy of the entire root zone (including all DNSSEC-related records). 📦
- The system MUST be able to run an authoritative server on one of the IPv4 loopback addresses (that is, an address in the range 127/8 for IPv4 or ::1 in IPv6). 🔁
here's the corollary: the authoritative data in the root zone used on the local authoritative server MUST be identical to the same data in the root zone for the DNS 🫶 it's possible to change the unsigned data (the glue records) in the local copy, but those changes could cause problems for the recursive server that reads the local root zone. so any changes to the glue records SHOULD NOT be made 🙅♀️
3. Operation of the Root Zone on the Loopback Address 🌸
running the authoritative root server in this setup can be done completely separately from running the recursive resolver ✨
the steps to set up the root zone are:
- Retrieve a copy of the root zone. (See Appendix A for some current locations of sources.) 📥
- Start the authoritative server with the root zone on a loopback address that isn't in use. for IPv4 that's typically 127.0.0.1, but if that one's taken, any address in 127/8 is fine. for IPv6 it's ::1. 🚀
the contents of the root zone MUST be refreshed using the timers from the SOA record in the root zone, as described in [RFC1035] ⏰ this inherently means the local root zone will likely be a little behind the global root servers, because those get updated when triggered by NOTIFY messages. and if the zone's contents can't be refreshed before the expire time, the server MUST return a SERVFAIL error response for all queries until the zone can be successfully set up again 🚨
💀 when refreshing the root zone fails, the results can be disastrous. for example, sometimes all the NS records for a TLD get changed in a short period of time (like 2 days). if refreshing the local root zone is broken during that window, the recursive resolver ends up with bad data for the entire TLD zone 😭
an admin using this procedure SHOULD have an automated way to check that the local root zone is actually being refreshed 🤖 one approach is a separate process that periodically checks the SOA of the root zone from the local copy and makes sure it's changing. at the time this doc was published, the SOA for the root zone was the digital representation of the current date with a two-digit counter appended, and the SOA changed every day even if the root zone's contents didn't 📅 for example, the SOA of the root zone on January 2, 2015 was 2015010201. a process can use this fact to check the contents of the local root zone (using a program not specified in this document) 🧠
4. Using the Root Zone Server on the Loopback Address 🎀
a recursive resolver that wants to use a root zone server running as described in Section 3 just specifies the local address as the place to look when it needs info from the root 💖 all responses from the root server must be validated using DNSSEC 🔐
heads up: using this config means the recursive resolver will fail if the local root zone server fails 😱 see Appendix B for more on how this plays out with specific software 📚
to test that the recursive resolver is working properly with the local root server, use a DNS client to send a query for the SOA of the root to the recursive server. then make sure the response that comes back has the AA bit in the message header set to 0 ✅
⏭️ that's the first half, more coming in part 2 bestie 🧚
5. Security Considerations 🚨
Okay bestie, security is where we get serious 😭 A system that skips the DNSSEC-related requirements in Section 2 can get tricked into giving bad answers, just like any recursive resolver that doesn't do DNSSEC validation on responses from a remote root server. 💀 So anyone deploying the method in this document needs to understand the operational benefits and costs of deploying DNSSEC [RFC4033]. It's giving responsible engineer energy 🫶
As stated in Section 1, this design only allows the new root zone server to run on a loopback address 🎀 That's the whole point: it stops the server from serving authoritative answers to any system other than the recursive resolver. The result is a really iconic security property, because it limits the damage to any other system that might try to rely on an altered copy of the root. Main character protection 👑
6. References 📚
6.1. Normative References
Here are the normative references, the ones you absolutely need to read 💖
[RFC1035] is Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] is Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC4033] is Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
6.2. Informative References
These ones are more like extra reading for the curious 🧚
[AggressiveNSEC] is Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3", Work in Progress, draft-fujiwara-dnsop-nsec-aggressiveuse-02, October 2015.
[Manning2013] is Manning, W., "Client Based Naming", 2013, <http://www.sfc.wide.ad.jp/dissertation/bill_e.html>.
Appendix A. Current Sources of the Root Zone 🌸
The root zone can be retrieved from anywhere, as long as it comes with all the DNSSEC records needed for validation ✨ Right now, you can get the root zone from ICANN by zone transfer (AXFR) over TCP from DNS servers at xfr.lax.dns.icann.org and xfr.cjr.dns.icann.org.
Right now, the root can also be retrieved by AXFR over TCP from these root server operators:
b.root-servers.netc.root-servers.netf.root-servers.netg.root-servers.netk.root-servers.net
⚠️ It is crucial to note that none of the above services are guaranteed to be available. It's possible that ICANN or some of the root server operators will turn off the AXFR capability on the servers listed above. Using AXFR over TCP to addresses that are likely to be anycast (as the ones above are) may conceivably have transfer problems due to anycast, but current practice shows that to be unlikely.
To repeat the requirement from earlier in this document: if the contents of the zone cannot be refreshed before the expire time, the server MUST return a SERVFAIL error response for all queries until the zone can be successfully be set up again. 😭 This is the one rule you can't skip, periodt.
Appendix B. Example Configurations of Common Implementations 🍓
This section shows fragments of configurations for some popular recursive server software that is believed to correctly implement the requirements given in this document 💅
The IPv4 and IPv6 addresses in this section were checked recently by testing for AXFR over TCP from each address for the known single-letter names in the root-servers.net zone 🔥
The examples here use a loopback address of 127.12.12.12, but typical installations will use 127.0.0.1. The different address is used to emphasize that the root server does not need to be on the device at "localhost" 🧚
B.1. Example Configuration: BIND 9.9
BIND acts as both a recursive resolver and an authoritative server. Because of this, there is "fate-sharing" between the two servers in the following configuration. That means if the root server dies, it's likely that all of BIND is dead 💀
Using this configuration, queries for information in the root zone are returned with the AA bit not set.
When slaving a zone, BIND treats zone data differently if the zone is slaved into a separate view (or a separate instance of the software) versus slaved into the same view or instance that is also performing the recursion 🦋
- Validation: When using separate views or separate instances, the DS records in the slaved zone will be validated as the zone data is accessed by the recursive server. When using the same view, this validation does not occur for the slaved zone.
- Caching: When using separate views or instances, the recursive server will cache all of the queries for the slaved zone, just as it would using the traditional "root hints" method. Thus, as the zone in the other view or instance is refreshed or updated, changed information will not appear in the recursive server until the TTL of the old record times out. Currently, the TTL for DS and delegation NS records is two days. When using the same view, all zone data in the recursive server will be updated as soon as it receives its copy of the zone.
view root {
match-destinations { 127.12.12.12; };
zone "." {
type slave;
file "rootzone.db";
notify no;
masters {
192.228.79.201; # b.root-servers.net
192.33.4.12; # c.root-servers.net
192.5.5.241; # f.root-servers.net
192.112.36.4; # g.root-servers.net
193.0.14.129; # k.root-servers.net
192.0.47.132; # xfr.cjr.dns.icann.org
192.0.32.132; # xfr.lax.dns.icann.org
2001:500:84::b; # b.root-servers.net
2001:500:2f::f; # f.root-servers.net
2001:7fd::1; # k.root-servers.net
2620:0:2830:202::132; # xfr.cjr.dns.icann.org
2620:0:2d0:202::132; # xfr.lax.dns.icann.org
};
};
};
view recursive {
dnssec-validation auto;
allow-recursion { any; };
recursion yes;
zone "." {
type static-stub;
server-addresses { 127.12.12.12; };
};
};B.2. Example Configuration: Unbound 1.4 and NSD 4
Unbound and NSD are separate software packages 🎀 Because of this, there is no "fate-sharing" between the two servers in the following configurations. If the root server instance (NSD) dies, the recursive resolver instance (Unbound) will probably keep running but won't be able to resolve any queries for the root zone. So the administrator of this configuration might want to carefully monitor the NSD instance and restart it immediately if it dies 👀
Using this configuration, queries for information in the root zone are returned with the AA bit not set.
# Configuration for Unbound
server:
do-not-query-localhost: no
stub-zone:
name: "."
stub-prime: no
stub-addr: 127.12.12.12
# Configuration for NSD
server:
ip-address: 127.12.12.12
zone:
name: "."
request-xfr: 192.228.79.201 NOKEY # b.root-servers.net
request-xfr: 192.33.4.12 NOKEY # c.root-servers.net
request-xfr: 192.5.5.241 NOKEY # f.root-servers.net
request-xfr: 192.112.36.4 NOKEY # g.root-servers.net
request-xfr: 193.0.14.129 NOKEY # k.root-servers.net
request-xfr: 192.0.47.132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 192.0.32.132 NOKEY # xfr.lax.dns.icann.org
request-xfr: 2001:500:84::b NOKEY # b.root-servers.net
request-xfr: 2001:500:2f::f NOKEY # f.root-servers.net
request-xfr: 2001:7fd::1 NOKEY # k.root-servers.net
request-xfr: 2620:0:2830:202::132 NOKEY # xfr.cjr.dns.icann.org
request-xfr: 2620:0:2d0:202::132 NOKEY # xfr.lax.dns.icann.orgB.3. Example Configuration: Microsoft Windows Server 2012
Windows Server 2012 contains a DNS server in the "DNS Manager" component 🪟 When activated, that component acts as a recursive server. DNS Manager can also act as an authoritative server 💖
Using this configuration, queries for information in the root zone are returned with the AA bit set.
The steps to configure DNS Manager to implement the requirements in this document are:
- Launch the DNS Manager GUI. This can be done from the command line (
"dnsmgmt.msc") or from the Service Manager (the"DNS"command in the"Tools"menu). - In the hierarchy under the server on which the service is running, right-click on the
"Forward Lookup Zones", and select"New Zone". This brings up a succession of dialog boxes ✨ - In the
"Zone Type"dialog box, select"Secondary zone". - In the
"Zone Name"dialog box, enter".". - In the
"Master DNS Servers"dialog box, enter"b.root-servers.net". The system validates that it can do a zone transfer from that server. (After this configuration is completed, the DNS Manager will attempt to transfer from all of the root zone servers.) 🔥 - In the
"Completing the New Zone Wizard"dialog box, click"Finish". - Verify that the DNS Manager is acting as a recursive resolver. Right-click on the server name in the hierarchy, choosing the
"Advanced"tab in the dialog box. Check that"Disable recursion (also disables forwarders)"is not selected, and that"Enable DNSSEC validation for remote responses"is selected 🫶
Acknowledgements 🌈
The authors fully acknowledge that running a copy of the root zone on the loopback address is not a new concept, and that they have chatted with many people about that idea over time 💜 For example, Bill Manning described a similar solution, but for a very different problem (intermittent connectivity, instead of constant but slow connectivity), in his doctoral dissertation in 2013 [Manning2013] 🎓
Evan Hunt contributed greatly to the logic in the requirements. Other significant contributors include Wouter Wijngaards, Tony Hain, Doug Barton, Greg Lindsay, and Akira Kato. The authors also received many offline comments about making the document clear that this is just a description of a way to operate a root zone on localhost, and not a recommendation to do so 🙈
Authors' Addresses 💌
Warren Kumari Google
Email: Warren@kumari.net
Paul Hoffman ICANN
Email: paul.hoffman@icann.org
📦 where this page comes from
- ietf: rfc7706 2015-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms