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.

Definitions

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.

Detailed requirements

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 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.

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 5737

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.

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).

Matching DNSKEY

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.

Useful References

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