RFC 2010

RFC 2010: Operational Criteria for Root Name Servers 🎀

Okay bestie, the title block is giving us the receipts 💅 Written by B. Manning (ISI) and P. Vixie (ISC), dated October 1996, and filed as Informational 📄. There are no Obsoletes or Updates lines, so this doc doesn't replace or change anything else.

Status of this Memo 🧾

This memo provides information for the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌈

Abstract ✨

This doc lays out the operational requirements for root name servers: the host hardware capacity, the name server software revisions, the network connectivity, and the physical environment 🖥️💜

1 - Rationale and Scope 🦋

1.1. Way back, the name servers in charge of the root (".") zone were also in charge of all the international top-level domains (iTLDs, like COM, EDU, INT, and ARPA) 🌸 A group of super capable volunteers ran these servers, and the NIC (first SRI-NIC, now InterNIC) loosely coordinated them. The IANA was always the one ultimately responsible for the servers running correctly and for what was in the DNS zones they served 👑

1.2. As [Postel96] explains, a bunch of new TLDs might show up soon 🍓 Servers for all the new and existing iTLDs will have to follow the operational requirements in [Postel96]. The root (".") zone servers are likely to end up as a separate set from the servers for any TLD or group of TLDs, including the ones InterNIC maintains 🔥

1.3. Okay, the iTLD servers and the root zone servers have a lot in common operationally, but they're honestly different server sets with different admins and slightly different requirements 🙈 Country code TLD servers will probably have even more different requirements. Still, the requirements in this doc could work for any name server (root, top level, or any other level), though they might be more strict than necessary for anything that isn't a root (".") zone server 💀

Disclaimer: The selection of name server locations and administrators, along with the procedures for dealing with noncompliance with these operational requirements, are outside the scope of this document 🙅‍♀️

Definition: For this document, the term "zone master" shall be used to designate the administrative owner of the content of a zone 🧚 This person is expected to have final responsibility for selecting and correctly operating all of the zone's servers. For the root (".") zone, that's the IANA 👑💖

Part 2 is coming next with the rest of the doc, so stay tuned 🫶✨

2. Operational Requirements ✨

2.1. Name server software 💻

okay so the zone master is the one in charge of picking the name server package that runs on every server in the zone 👑 they MUST pick it at the start and then keep checking in on it periodically 🔁. BIND is expected to be the pick, at least to begin with 🎀, and new versions or other servers may get specified from time to time 🦋

Rationale: BIND's source code is wide and free to get, and several IETF folks are constantly analysing and developing it 🧠✨

Software upgrades are specified and scheduled by the zone master too, and they MUST happen on all of a zone's servers inside a specified 96 hour window 🗓️💅

Rationale: sometimes a zone's servers have to be "cold started" to clear out bad data that keeps oscillating 🥶. If every upgrade lands at about the same time, a software change and a zone content change can be coordinated together 🫶

2.2. UDP checksums 🧮

UDP checksums MUST be generated when sending datagrams, and verified when receiving them 🔥

Rationale: some vendors turn UDP checksums off for performance and say the MAC-level frame checks (CRC, for example) are "strong enough" 🙄. In real life this has been a total disaster 💀

2.3. Dedicated host 🏠

A name server host SHOULD have no other function, and SHOULD have no login accounts other than ones for system or network administrators 🔐. No other network protocols SHOULD be served by a name server host (SMTP, NNTP, FTP, et al) 🙅‍♀️. If login is permitted from anywhere other than the system console, the login service MUST go through an encrypted channel (for example Kerberized and encrypted rlogin/telnet, the secure shell (SSH), or an equivilent) 🔒

Rationale: every extra service a host runs makes it less reliable and potentially less secure, and it complicates fault isolation too 😵. Name service doesn't eat up many system resources, but it's thought best that a host does a few things well rather than many things poorly 💖

2.4. Clock synchronization ⏰

A name server host SHOULD sync its clock using the NTP protocol (currnet version) with authentication 🕰️. At least two NTP servers SHOULD be used. As an exception to section 2.3 above, a name server host MAY also be an NTP server 🧚

Rationale: synced timestamps in system event logs are super helpful for distributed fault isolation 🔍. NTP can be spoofed by UDP blast attacks, which is why the name server host needs authentication with its NTP servers 🛡️. A name server host is allowed to be an NTP server because it's been observed that one host running both name service and stratum 1 NTP is still quite reliable and secure 🌈

2.5. Network interfaces 🌐

Name servers MUST send UDP responses with an IP source address (and UDP source port number) equal to the IP destination address (and UDP destination port number) of the request 📬. Also, a name server might have multiple real interfaces, but only one of them will be advertised in the zone's NS RRset and associated glue A RRs 🎯. The advertised address SHOULD be the "best" interface on the host, in terms of network performance and reliability to the largest number of destinations 🏆

Rationale: [RFC1035] doesn't require this, but lots of existing DNS implementations expect the source address and port of a reply to match the destination address and port the request was sent to 🤷‍♀️. The advertised address count is limited to one (1) so that DNS delegation responses containing this name server can be as short as possible ✂️

2.6. Physical environment 🏢

A name server host MUST be located in a secure space, such as a locked computer room or a data center with restricted access 🗝️. The power supply SHOULD be redundant, using batteries, generators or some other means to protect against utility power failures ⚡. Network connectivity SHOULD be redundant, so a single wide area line failure can't completely isolate the name server host from the rest of the network 🛜

2.7. Network security 🕵️‍♀️

The system and network administrators SHOULD educate themselves about potential threats and stay current on CERT bulletins about network breakins 📰. The system staff SHOULD periodically audit the name server host's activity logs and be able to detect breakins during or after the fact 🔎

2.8. Host performance 🚀

As of the time of this writing, a name server MUST be able to answer 1,200 UDP transactions per second with less than 5 milliseconds of average latency 💪. Because the network is still growing at a high rate, being able to grow to 2,000 transactions per second and still support a 5 millisecond latency is highly desirable 📈. Note that this requirement affects both the host and the network infrastructure it's attached to 🧁

2.9. Response time ⏳

The administrators responsible for a name server MUST respond to e-mail trouble reports within 24 hours 📧. Personnel issues like vacations and illness will cause responsibilities to be delegated and/or reassigned, not ignored 🏖️. After hours telephone numbers MUST be made available to the zone master for nonpublished use in emergencies 📞. An escalation contact name, e-mail address, and telephone number MUST also be made available to the zone master in case the normal channel gets no response 🚨

2.10. Zone transfer access control 🚧

The name server SHALL be configured so outbound zone transfers are permitted only to destinations on the server's local networks, and to whichever networks the zone master designates for remote debugging purposes 🙅‍♀️

Rationale: zone transfers can put a serious load on a name server, especially if several start at once against the same server 😩. There's no operational reason for anyone outside the name server's and zone's administrators to transfer the entire zone 🔐

2.11. Zone transfer protocol 📦

DNS AXFR MUST be used in preference to FTP or any other non-DNS transfer protocol 🥇. DNS NOTIFY (see [NOTIFY]) and DNS IXFR (see [IXFR]) SHALL be supported and enabled when available 🔔

Rationale: historically, common DNS implementations (a.k.a., BIND) didn't support zone transfer of the root (".") zone because of programming errors, so FTP got used instead 🫠. In the future, DNS implementations that don't support zone transfer of all zones will NOT be considered suitable for use as root name servers 🚫. The benefits of [IXFR] and [NOTIFY] should be obvious 💜

2.12. Recursion ♻️

Recursion MUST be disabled for queries 🙅‍♀️

Rationale: recursion is a major source of cache pollution and can be a major drain on name server performance 🗑️. An organization's recursive DNS needs should be served by some other host than its root name server(s) 🏃‍♀️. There's an exception for missing glue, since glue needed for some delegations might not be within or beneath any zone the server is authoritative for. Such glue MUST be fetched via recursive lookups to other servers 🧩

2.13. Outages shall be reported 📣

All outages, scheduled or not, SHALL be reported to the zone master via e-mail. If an outage is unscheduled, or if it's scheduled less than 24 hours in advance, then the zone master SHALL also be notified via telephone 📱. Extended or repeated outages may beget special handling by the zone master 👀

2.14. Inverse name lookups 🔄

The PTR RR associated with a server's primary interface address (that is, the address shown in the zone's delegation) MUST have its target specified by the zone master 🎯

Rationale: each organization has local control of their network's PTR RRs, and some software needs forward and reverse lookups to give symmetrical results to work correctly 🪞. So it's left up to the zone master to pick the name for each authority server's primary address 👑

---

3. Possible Selection Criteria 🔍

3.1. Host population 🧑‍🤝‍🧑

A server's location on the network SHOULD be such that it has a low IP hop count to a high number of end hosts 🛣️. Duplication of service SHOULD be avoided, so that any given set of end hosts needs a low IP hop count to at most one authority server for any given zone 🫧

3.2. Infrastructure diversity 🌍

A server's location on the network SHOULD be such that most failures capable of isolating it from a large number of end hosts are diverse from the failures capable of similarly isolating other authority servers for the same zone(s) 🦋

---

4. Security Considerations 🔐

See section 2.7.

---

5. References 📚

[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[Postel96] Postel, J., "New Registries and the Delegation of International Top Level Domains", Work in Progress.

[IXFR] Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.

[NOTIFY] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes", RFC 1996, August 1996.

---

6. Acknowledgements 🫶

Constructive comments have been received from: Jon Postel, Michael Patton, Andrew Partan, Michael Dillon, Don Mitchell Steven Doyle, Owen DeLong and other members of the internet community 💕

---

7. Authors' Addresses 🏡

Bill Manning USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292

Phone: +1 310 822 1511 EMail: bmanning@isi.edu

Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062

Phone: +1 415 747 0204 EMail: paul@vix.com