Technical requirements for authoritative name servers
These are the technicals tests we perform for delegation changes in the zones we manage (root zone, .INT, .ARPA). This includes changes to the name server set (NS records) and any associated delegation signer (DS) records.
Generally, we perform these tests using an automated testing regime. Any deficiencies against these requirements will be reported to the requester for remediation in order to proceed with a change request. If there are special circumstances for the request, the requester can appeal to have the request bypass the requirements. Such appeals are assessed on a case-by-case basis by a subject matter expert.
These tests do not measure against best practices or comprehensively measure protocol conformance. They are a practical set of baseline requirements that catch common misconfiguration errors that impact stable operations of the DNS.
Requirements for Name Servers
These tests are performed for the set of NS records and any associated IP addresses for those name servers. For each individual hostname, tests are performed against each IP address and protocol pair.
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. This means that the DNS response 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 5735|
|203.0.113.0/24||Not globally routable||RFC 5737|
|18.104.22.168/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.
Requirements for Delegation Signer (DS) records
These requirements must be met for signed delegations, which is when one or more DS records are supplied. If no DS records are supplied, the delegation is unsigned and none of these tests are performed.
DS record format
Trust anchors must be provided as complete DS records. This means providing the key tag, the key algorithm, the digest hash type, and the digest hash, with legal values for each component.
Supported signing algorithm
The following signing algorithms are allowed:
- DSA/SHA-1 (type 3)
- RSA/SHA-1 (type 5)
- DSA/SHA-1 with NSEC3 (type 6)
- RSA/SHA-1 with NSEC3 (type 7)
- RSA/SHA-256 (type 8)
- RSA/SHA-512 (type 10)
- GOST R 34.10-2001 (type 12)
- ECDSA Curve P-256 with SHA-256 (type 13)
- ECDSA Curve P-384 with SHA-384 (type 14)
Supported digest type
Digest types 1-4 are allowed:
- GOST R 34.11-94
Matching DNSKEY records
At the time of the listing request there must be a DNSKEY present in the child zone that matches each DS record.
While exceptions can be considered based on compelling operational circumstances to list DS records without a matching DNSKEY, it is strongly discouraged. Cross-validating all DS records is a safeguard to reduce a future risk of rolling the domain's signatures to an invalid state.
Validation of RRSIG
Validation of the zone must be possible using the DS record set that has been provided for listing in the parent zone. We test this by querying the apex SOA record for the domain with the “DO”-bit set and ensuring its RRSIG records can be validated based on 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)
- Extension Mechanisms for DNS (EDNS0) (RFC 2671)
- Operational Considerations and Issues with IPv6 DNS (RFC 4472)
- Preventing Use of Recursive Nameservers in Reflector Attacks (RFC 5358)
- DNS Transport over TCP - Implementation Requirements (RFC 5966)