Technical requirements for authoritative name servers
This article describes the baseline technical conformance criteria for authoritative name servers. These are evaluated by ICANN as the IANA functions operator for changes to delegations in IANA-managed zones such as the DNS root zone and .INT zone.
For purposes of this document, an authoritative name server is a DNS server that has been designated to answer authoritatively for the designated zone, and is being requested to be listed in the delegation. It is recorded by its fully-qualified domain name, potentially along with its IP addresses.
Name server tests are completed against each unique tuple of a hostname, an IP address, and a protocol. If a hostname has multiple IP addresses, for example, the tests will be conducted against each IP address.
Minimum number of name servers
There must be at least two NS records listed in a delegation, and the hosts must not resolve to the same IP address.
The hostnames used for the name servers must comply with the requirements for valid hostnames described in RFC 1123, section 2.1.
Name server reachability
The name servers must answer DNS queries over both the UDP and TCP protocols on port 53. Tests will be conducted from multiple network locations to verify the name server is responding.
The name servers must answer authoritatively for the designated zone. Responses to queries to the name servers for the designated zone must have the “AA”-bit set.
This will be tested by querying for the SOA record of the designated zone with no “RD”-bit set.
The name servers must be in at least two topologically separate networks. A network is defined as an origin autonomous system in the BGP routing table. The requirement is assessed through inspection of views of the BGP routing table.
Consistency between glue and authoritative data
For name servers that have IP addresses listed as glue, the IP addresses must match the authoritative A and AAAA records for that host.
Consistency between delegation and zone
The set of NS records served by the authoritative name servers must match those proposed for the delegation in the parent zone.
Consistency between authoritative name servers
The data served by the authoritative name servers for the designated zone must be consistent.
All authoritative name servers must serve the same NS record set for the designated domain.
All authoritative name servers must serve the same SOA record for the designated domain.
If for operational reasons the zone content fluctuates rapidly, the serial numbers need only be loosely coherent.
No truncation of referrals
Referrals from the parent zone's name servers must fit into a non-EDNS0 UDP DNS packet and therefore the DNS payload must not exceed 512 octets.
The required delegation information in the referral is a complete set of NS records, and the minimal set of requisite glue records. The response size is assessed as a response to a query with a maximum-sized QNAME.
The minimal set of requisite glue records is considered to be:
- One A record, if all authoritative name servers are in-bailiwick of the parent zone; and,
- One AAAA record, if there are any IPv6-capable authoritative name servers and all IPv6- capable authoritative name servers are in-bailiwick of the parent zone.
The authoritative name server IP addresses must not be in specially designated networks that are either not globally routable, or are otherwise unsuited for authoritative name service.
|0.0.0.0/8||Not globally routable||RFC 5735|
|10.0.0.0/8||Not globally routable||RFC 5735|
|100.64.0.0/10||Not globally routable||RFC 6598|
|127.0.0.0/8||Not globally routable||RFC 5735|
|169.254.0.0/16||Not globally routable||RFC 5735|
|172.16.0.0/12||Not globally routable||RFC 5735|
|192.0.2.0/24||Not globally routable||RFC 5735|
|192.168.0.0/16||Not globally routable||RFC 5735|
|198.18.0.0/15||Not globally routable||RFC 5735|
|198.51.100.0/24||Not globally routable||RFC 5737|
|203.0.113.0/24||Not globally routable||RFC 5737|
|188.8.131.52/3||Not globally routable||RFC 5735|
|::/128||Not globally routable||RFC 5156|
|::1/128||Not globally routable||RFC 5156|
|::FFFF:0:0/96||IPv4 mapped addresses||RFC 4291|
|2001:2::/48||Not globally routable||RFC 5156|
|2001:10::/28||Not globally routable||RFC 5156|
|2001:DB8::/32||Not globally routable||RFC 5156|
|FC00::/7||Not globally routable||RFC 5156|
|FE80::/10||Not globally routable||RFC 5156|
No open recursive name service
The authoritative name servers must not provide recursive name service. This requirement is tested by sending a query outside the jurisdiction of the authority with the “RD”-bit set.
Same source address
Responses from the authoritative name servers must contain the same source IP address as the destination IP address of the initial query.
DS record format
Trust anchors must be provided each with the four attributes of a DS record — the key tag, the key algorithm, the digest hash type, and the digest hash. They must be provided with legal values for each of the DS record fields. For the hash digest, ICANN supports two types — SHA1 (value 1), and SHA256 (value 2).
At the time of the listing request, there must be a DNSKEY that matches the DS record present in the child zone. This will be tested for as part of the implementation of the record. As with most technical conformance criteria for the root zone, if a top-level domain operator has a situation where this is not the case, but this is by design and can be demonstrated not to affect the stability of the TLD or the root zone, it is possible to request that the DS records be listed regardless.
Validation of RRSIG
ICANN must be able to validate the RRSIG records returned for the zone based upon the DS record set that has been provided for the root zone. We test this by querying the apex SOA for the top-level domain with the DO bit set, and validating the SOA record against the proposed DS resource set.
For more information on some of the key DNS technical concepts referenced by these technical tests, please look at the following references:
- Domain Names — Concepts and Facilities (RFC 1034)
- Domain Names — Implementation and Specification (RFC 1035)
- Preventing Use of Recursive Nameservers in Reflector Attacks (RFC 5358)
- Operational Considerations and Issues with IPv6 DNS (RFC 4472)
- Extension Mechanisms for DNS (EDNS0) (RFC 2671)
- DNS Referral Response Size Issues
- DNS Transport over TCP - Implementation Requirements (RFC 5966)
- IANA IPv6 Special Purpose Address Registry
- Special-use IPv6 Addresses (RFC 5156)
- Special-use IPv4 Addresses (RFC 5735)