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.

Valid hostnames

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.

Answer authoritatively

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.

Network diversity

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.

Prohibited networks

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.88.99.0/24 6to4 RFC 3068
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
224.0.0.0/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::/32 Teredo RFC 4380
2001:10::/28 Not globally routable RFC 5156
2001:db8::/32 Not globally routable RFC 5156
2002::/16 6to4 RFC 3056
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:

  • SHA-1
  • SHA-256
  • GOST R 34.11-94
  • SHA-384

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.

Useful References

For more information on some of the key DNS technical concepts referenced by these technical tests, please look at the following references:

Related articles

Last revised 2020-02-25.