RFC 2870

RFC 2870: Root Name Server Operational Requirements 🎀

Okay bestie, so this is RFC 2870, called Root Name Server Operational Requirements. It came out in June 2000 from the Network Working Group, written by R. Bush (Verio), D. Karrenberg (RIPE NCC), M. Kosters (Network Solutions), and R. Plzak (SAIC). It's a Best Current Practice, so it's BCP 40 🦋, and it obsoletes RFC 2010. Main character energy for sure 👑

---

Status of this Memo 📜

This doc specifies an Internet Best Current Practice for the Internet Community, and it's literally asking for discussion and suggestions for improvements. Distribution of this memo is unlimited 🌈

Copyright Notice ©️

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract ✨

As the internet becomes more and more critical to the world's social and economic infrastructure, everyone's rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself 🫶 The root domain name servers are seen as a crucial part of that technical infrastructure. The main goal of this doc is to give guidelines for operating the root name servers. Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines are meant to meet the perceived societal needs without overly prescribing technical details 💅

---

1. Background 🌸

Domain name resolution on the internet is critically dependent on the proper, safe, and secure operation of the root domain name servers. Right now, these dozen or so servers are provided and operated by a very competent and trusted group of volunteers 🥹 This doc doesn't propose to change that. It just gives formal guidelines so the community understands how and why this is done.

1.1 ICANN and the RSSAC 🏛️

The Internet Corporation for Assigned Names and Numbers (ICANN) has become responsible for operating the root servers. ICANN has appointed a Root Server System Advisory Committee (RSSAC) to give technical and operational advice to the ICANN board. ICANN and the RSSAC look to the IETF to provide engineering standards.

1.2 What the root servers serve 🌍

The root servers serve the root, aka ".", zone. Although today some of the root servers also serve some TLDs (top level domains) such as gTLDs (COM, NET, ORG, etc.), infrastructural TLDs such as INT and IN-ADDR.ARPA, and some ccTLDs (country code TLDs, e.g. SE for Sweden), this is likely to change (see 2.5) 👀

1.3 Whois is not the vibe 🙅‍♀️

The root servers are neither involved with nor dependent upon the 'whois' data.

1.4 The DNS is sturdy 💪

The domain name system has proven to be sufficiently robust. We're confident that the, presumably temporary, loss of most of the root servers should not significantly affect operation of the internet. Iconic behaviour from the DNS honestly 🧚

1.5 Trust but verify 🔐

Experience has shown that the internet is quite vulnerable to incorrect data in the root zone or TLDs. Hence, authentication, validation, and security of these data are of great concern. This is a big deal, bestie 😭

---

2. The Servers Themselves 🖥️

The following are requirements for the technical details of the root servers themselves:

2.1 No picking favourites 🎨

It would be short-sighted of this document to specify particular hardware, operating systems, or name serving software. Variations in these areas would actually add overall robustness, so lowkey it's a good thing 🫠

2.2 Software must actually follow the rules 📚

Each server MUST run software which correctly implements the IETF standards for the DNS, currently [RFC1035] [RFC2181]. There are no formal test suites for standards compliance, but the maintainers of software used on root servers are expected to take all reasonable actions to conform to the IETF's then current documented expectations. No cap, that's a whole vibe 💅

2.3 Handle the load, no matter what 🚀

At any time, each server MUST be able to handle a load of requests for root data which is three times the measured peak of such requests on the most loaded server in then current normal conditions. This is usually expressed in requests per second. The goal is to ensure continued operation of root services should two thirds of the servers be taken out of operation, whether by intent, accident, or malice. Iykyk, the redundancy is the whole point ✨

2.4 Connectivity, diversity, and open doors 🌐

Each root server should have sufficient connectivity to the internet to support the bandwidth needs of the above requirement. Connectivity to the internet SHOULD be as diverse as possible.

Root servers SHOULD have mechanisms in place to accept IP connectivity to the root server from any internet provider delivering connectivity at their own cost. Giving everyone a seat at the table 🪑💖

2.5 Authoritative answers only, please 🙅‍♀️

Servers MUST provide authoritative responses only from the zones they serve. The servers MUST disable recursive lookup, forwarding, or any other function that may allow them to provide cached answers. They also MUST NOT provide secondary service for any zones other than the root and root-servers.net zones. These restrictions help prevent undue load on the root servers and reduce the chance of their caching incorrect data. Keeping it clean and focused, periodt 💅🍓

2.6 Don't block the root 🚪

Root servers MUST answer queries from any internet host. That means they may not block root name resolution from any valid IP address, except in the case of queries causing operational problems. In that case, the blocking SHOULD last only as long as the problem, and be as specific as reasonably possible. Blocking someone's whole life is NOT the move 😤

2.7 Zone transfers: hands off 🤚

Root servers SHOULD NOT answer AXFR, or other zone transfer, queries from clients other than other root servers. This restriction is intended to, among other things, prevent unnecessary load on the root servers. Advice has been heard such as "To avoid having a corruptible cache, make your server a stealth secondary for the root zone." The root servers MAY put the root zone up for ftp or other access on one or more less critical servers 🧚

2.8 Checksums, always 🧮

Servers MUST generate checksums when sending UDP datagrams and MUST verify checksums when receiving UDP datagrams containing a non-zero checksum. Data integrity is everything, bestie 🫶

---

Part 1 of 3 is done! Part 2 is coming up next 💜🦋

3. Security Considerations 🔐✨

okay bestie, this section is the serious one 😭 The servers need physical security, protocol security, and authentication that proves their answers are legit. No cap, it's a whole vibe check. 💅

3.1 Physical security 🏰

Physical security MUST be ensured in a manner expected of data centers critical to a major enterprise. Basically, it has to be locked down like a place that a big company really can't afford to lose. 🔒💜

3.1.1 Access control 🔑

Whether or not the overall site in which a root server is located has access control, the specific area in which the root server is located MUST have positive access control. That means the number of individuals permitted access to the area MUST be limited, controlled, and recorded. At a minimum, control measures SHOULD be either mechanical or electronic locks. Physical security MAY be enhanced by the use of intrusion detection and motion sensors, multiple serial access points, security personnel, etc. ✨

3.1.2 Power continuity ⚡

Unless there is documentable experience that the local power grid is more reliable than the MTBF of a UPS (i.e. five to ten years), power continuity for at least 48 hours MUST be assured, whether through on-site batteries, on-site power generation, or some combination thereof. This MUST supply the server itself, as well as the infrastructure necessary to connect the server to the internet. 🔋

There MUST be procedures which ensure that power fallback mechanisms and supplies are tested no less frequently than the specifications and recommendations of the manufacturer. Testing the backup stuff on schedule is a must, periodt. 🧪

3.1.3 Fire 🔥

Fire detection and/or retardation MUST be provided. Non-negotiable, bestie. 🚒

3.1.4 Rapid return to operation 🚀

Provision MUST be made for rapid return to operation after a system outage. This SHOULD involve backup of systems software and configuration. But SHOULD also involve backup hardware which is pre-configured and ready to take over operation, which MAY require manual procedures. Getting back up fast is giving main character energy 👑

3.2 Network security 🛡️

Network security should be of the level provided for critical infrastructure of a major commercial enterprise. 🌸

3.2.1 Services, logins, and remote access 🧑‍💻

The root servers themselves MUST NOT provide services other than root name service, e.g. remote internet protocols such as http, telnet, rlogin, ftp, etc. The only login accounts permitted should be for the server administrator(s). "Root" or "privileged user" access MUST NOT be permitted except through an intermediate user account. Not me giving the root servers a whole buffet of extra services 🙈

Servers MUST have a secure mechanism for remote administrative access and maintenance. Failures happen. Given the 24x7 support requirement (per 4.5), there will be times when something breaks badly enough that senior wizards will have to connect remotely. Remote logins MUST be protected by a secure means that is strongly authenticated and encrypted, and sites from which remote login is allowed MUST be protected and hardened. 🧙‍♀️🔐

3.2.2 Trust 🤝

Root name servers SHOULD NOT trust other hosts, except secondary servers trusting the primary server, for matters of authentication, encryption keys, or other access or security information. If a root operator uses kerberos authentication to manage access to the root server, then the associated kerberos key server MUST be protected with the same prudence as the root server itself. This applies to all related services which are trusted in any manner. Trust is earned, not given 💅

3.2.3 LAN segments 🧱

The LAN segment(s) on which a root server is homed MUST NOT also home crackable hosts. I.e. the LAN segments should be switched or routed so there is no possibility of masquerading. Some LAN switches aren't suitable for security purposes, there have been published attacks on their filtering. While these can often be prevented by careful configuration, extreme prudence is recommended. It is best if the LAN segment simply does not have any other hosts on it. Solo LAN segment era, iykyk 🫣

3.2.4 Firewalls 🔥🧱

The LAN segment(s) on which a root server is homed SHOULD be separately firewalled or packet filtered to discourage network access to any port other than those needed for name service. 🚧

3.2.5 Clock synchronization ⏰

The root servers SHOULD have their clocks synchronized via NTP [RFC1305] [RFC2030] or similar mechanisms, in as secure manner as possible. For this purpose, servers and their associated firewalls SHOULD allow the root servers to be NTP clients. Root servers MUST NOT act as NTP peers or servers. Clients only, no peer drama 🕰️💖

3.2.6 Intrusion logging 📓

All attempts at intrusion or other compromise SHOULD be logged, and all such logs from all root servers SHOULD be analyzed by a cooperative security team communicating with all server operators to look for patterns, serious attempts, etc. Servers SHOULD log in GMT to facilitate log comparison. Everyone logs in GMT so the timestamps line up, bestie 🌍

3.2.7 Log hosts 🗂️

Server logging SHOULD be to separate hosts which SHOULD be protected similarly to the root servers themselves. Your logs deserve bodyguards too 🫶

3.2.8 Source routing and authentication 🚫

The server SHOULD be protected from attacks based on source routing. The server MUST NOT rely on address- or name-based authentication. Vibes based on IP or name alone are a no-go 💀

3.2.9 in-addr.arpa 🔍

The network on which the server is homed SHOULD have in-addr.arpa service. 🌈

3.3 Protocol authentication and security 🧾

Protocol authentication and security are required to ensure that data presented by the root servers are those created by those authorized to maintain the root zone data. Basically, the answers have to be provably from the right people 👑🦋

3.3.1 Signing the root zone ✍️

The root zone MUST be signed by the Internet Assigned Numbers Authority (IANA) in accordance with DNSSEC, see [RFC2535] or its replacements. It is understood that DNSSEC is not yet deployable on some common platforms, but will be deployed when supported. Real talk, the platforms are catching up 🌷

3.3.2 DNSSEC-capable root servers 🔏

Root servers MUST be DNSSEC-capable so that queries may be authenticated by clients with security and authentication concerns. It is understood that DNSSEC is not yet deployable on some common platforms, but will be deployed when supported. 🎀

3.3.3 Zone transfers 📦

Transfer of the root zone between root servers MUST be authenticated and be as secure as reasonably possible. Out of band security validation of updates MUST be supported. Servers MUST use DNSSEC to authenticate root zones received from other servers. It is understood that DNSSEC is not yet deployable on some common platforms, but will be deployed when supported. Zone transfers with receipts, bestie 🧾✨

3.3.4 Hidden primary 🙈

A 'hidden primary' server, which only allows access by the authorized secondary root servers, MAY be used. Secret VIP server energy 🤫

3.3.5 Heuristic checks 🧪

Root zone updates SHOULD only progress after a number of heuristic checks designed to detect erroneous updates have been passed. In case the update fails the tests, human intervention MUST be requested. When the robots are sus, a human checks 🧍‍♀️🫶

3.3.6 Update timing ⏳

Root zone updates SHOULD normally be effective no later than 6 hours from notification of the root server operator. 🍓

3.3.7 Emergency updates 🚨

A special procedure for emergency updates SHOULD be defined. Updates initiated by the emergency procedure SHOULD be made no later than 12 hours after notification. Emergency mode, but make it organized 💖

3.3.8 Critical network failure 🛰️

In the advent of a critical network failure, each root server MUST have a method to update the root zone data via a medium which is delivered through an alternative, non-network, path. Like, sneakernet energy when the internet ghosts you 👟💀

3.3.9 Statistics and RSSAC 📊

Each root MUST keep global statistics on the amount and types of queries received/answered on a daily basis. These statistics must be made available to RSSAC and RSSAC sponsored researchers to help determine how to better deploy these machines more efficiently across the internet. Each root MAY collect data snapshots to help determine data points such as DNS query storms, significant implementation bugs, etc.数据 is the whole tea ☕📈

---

4. Communications 💬

Communications and coordination between root server operators and between the operators and the IANA and ICANN are necessary. Group chat with all the operators, but make it productive 🫶

4.1 Planned outages 📅

Planned outages and other down times SHOULD be coordinated between root server operators to ensure that a significant number of the root servers are not all down at the same time. Preannouncement of planned outages also keeps other operators from wasting time wondering about any anomalies. Spoiler alert, nobody wants a surprise outage 😭

4.2 Backup timing 💾

Root server operators SHOULD coordinate backup timing so that many servers are not off-line being backed up at the same time. Backups SHOULD be frequently transferred off site. Off-site backups or it didn't happen 🌸

4.3 Log exchange 🗃️

Root server operators SHOULD exchange log files, particularly as they relate to security, loading, and other significant events. This MAY be through a central log coordination point, or MAY be informal. Log swap meet 🦋

4.4 Statistics exchange 📈

Statistics as they concern usage rates, loading, and resource utilization SHOULD be exchanged between operators, and MUST be reported to the IANA for planning and reporting purposes. The receipts go to IANA, bestie 💅

4.5 24x7 staffing 🕐

Root name server administrative personnel MUST be available to provide service 24 hours a day, 7 days per week. On call personnel MAY be used to provide this service outside of normal working hours. The servers never sleep, so somebody's always on duty 🌙☀️

---

5. Acknowledgements 🎀

The authors would like to thank Scott Bradner, Robert Elz, Chris Fletcher, John Klensin, Steve Bellovin, and Vern Paxson for their constructive comments. Shoutout to the reviewers, you're literally the best 💖🫶

---

6. References 📚

[RFC1035] Mockapetris, P., "Domain names - implementation and
          specification", STD 13, RFC 1035, November 1987.

[RFC1305] Mills, D., "Network Time Protocol (Version 3)
          Specification, Implementation", RFC 1305, March 1992.

[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
          for IPv4, IPv6 and OSI", RFC 2030, October 1996.

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
          Specification", RFC 2181, July 1997.

[RFC2535] Eastlake, D. and C. Kaufman, "Domain Name System Security
          Extensions", RFC 2535, March 1999.

7. Authors' Addresses 🦋

Randy Bush
Verio, Inc.
5147 Crystal Springs
Bainbridge Island, WA US-98110

Phone: +1 206 780 0431
EMail: randy@psg.com


Daniel Karrenberg
RIPE Network Coordination Centre (NCC)
Singel 258
NL-1016 AB  Amsterdam
Netherlands

Phone: +31 20 535 4444
EMail: daniel.karrenberg@ripe.net


Mark Kosters
Network Solutions
505 Huntmar Park Drive
Herndon, VA 22070-5100

Phone: +1 703 742 0400
EMail: markk@netsol.com


Raymond Plzak
SAIC
1710 Goodridge Drive
McLean, Virginia 22102
+1 703 821 6535

EMail: plzakr@saic.com

8. Specification of Requirements 📏

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 RFC 2119. That's the decoder ring for every caps word above, so keep it handy 💜✨

9. Full Copyright Statement ✨

okay bestie, the legal bit 🎀 Copyright (C) The Internet Society (2000). All Rights Reserved. 💅

So you can copy this doc and share it with people, and you can even make derivative works that comment on it, explain it, or help people implement it. You can publish and distribute those too, in whole or in part, with no restrictions of any kind 🦋 The one big condition is that the copyright notice and this paragraph have to be on every copy and every derivative work. 🫶

The doc itself? Nope, you can't modify it in any way, like deleting the copyright notice or the references to the Internet Society or other Internet organizations. 🙈 There are two exceptions. First, you can change it for developing Internet standards, but then the procedures for copyrights defined in the Internet Standards process must be followed. Second, you can translate it into languages other than English. 🌍

These permissions are perpetual, which means the Internet Society or its successors or assigns will never take them back. 🔒

And now the not-so-fun disclaimer 💀 This document and the information in it is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭

---

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. 💜 Thank you to them for keeping the RFCs running, fr fr 🙌