DNS Delegation Requirements
pawal@blipp.com
Kirei AB
jakob@kirei.se
Internet
DNSOP
This document outlines a set of requirements on a well-behaved DNS delegation
of a domain name. A large number of tools have been developed to test DNS
delegations, but each tool uses a different set of requirements for what is a
correct setup for a delegated domain name. However, there are few requirements
on how to set up DNS in order to just make the delegation work. In order to
have a well-behaved delegation that is robust to failures and also makes DNS
resolvers behave consistently, there are a large number of things to consider.
Based on this document, it should be possible to set up a fully functional DNS
delegation for a domain name, but also to create a set of test specifications
for how to test a DNS delegation.
This document outlines a set of requirements on a well-behaved DNS delegation
of a domain name. Many domain name registries use a set of requirements on
what they may consider a valid delegation. Such requirements can be used to
implement tools that are used for pre- or post-delegation checks of the
delegations in that registry.
To test the quality of the delegation there has been a number of different
tools developed, each based on a different set of requirements. This
document outlines a set of baseline requirements on a correct setup for
a delegated domain name. This document is based on current RFCs and
documents requirements that are protocol specific, but also administrative
policy requirements drawn from best practices and recommendations.
The DNS requirements are split into these different areas, to easier
differentiate between what they are for:
Basic
Address
Connectivity
Name server
Consistency
Delegation
DNSSEC
Syntax
A secondary name server operator should follow the advice in the BCP document
.
Nothing in this document precludes others testing servers for protocol
compliance. DNS operators should test their servers to ensure that their
vendors have shipped protocol compliant products. Name server vendors can
use these tests as a part of this release processes. Registrants can use
these tests to check their DNS operators servers.
This document attempts to fully follow the DNS terminology as defined in
.
Many requirements in this document deal with the properties of a
name server that is used as part of a delegation, therefore the wording
mentioning the use - authoritative or recursive - of a name server as part of
this is omitted.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in .
The Basic requirements are fundamental to a working DNS delegation. Without
these properties, the rest of the requirements are irrelevant.
The domain name MUST follow the rules defined in Section 2.1 of in
order to be able to map the domain into a DNS packet. A domain name is normally
valid if the name has been registered with a domain name registry.
Internationalized domain names, , are expected to be encoded using
Punycode , thus following the rules outlined in Section 2.3.1 of
. Any validation of the domain name in U-label form is out of scope
for this document.
A DNS delegation MUST have a parent domain from which it is delegated. The
concept of zone cuts was first described in and later clarified in
Section 6 of . The only exception is the root zone, which do not have
a parent zone.
A fully working DNS delegation has a parent zone delegating the zone to a set
of child name servers. At least one name server MUST be able to answer DNS
queries in order to be able to authoritatively serve data for the child zone.
A delegation in the public Internet DNS hierarchy will use the globally unique
address space.
In order for the domain and its resources to be accessible from the Internet,
authoritative name servers must have addresses in the routable public
addressing space.
IANA is responsible for global coordination of the IP addressing system. Aside
its address allocation activities, it maintains reserved address ranges for
special uses. There are two IANA registries for Special-Purpose Addresses, the
IANA IPv6 Special-Purpose Address Registry and the IANA IPv4 Special-Purpose
Address Registry.
instructs IANA on how to structure the IPv4 and IPv6 Special-Purpose
Address Registries. The registries and
are maintained by IANA, and are also described in Section
2.2 and 2.3 of .
A name server MUST NOT be using any IP address within any of these registries
that are marked with False in the Global column.
IP addresses not delegated by IANA MUST NOT be used used by a name server.
Thus, IP addresses within a prefix not delegated to a RIR by IANA MUST be
rejected.
The IANA registry SHOULD be used to determine the status of
an IPv6 prefix. Only prefixes with the status ALLOCATED are allowed.
The IANA registry SHOULD be used to determine the status
of an IPv4 prefix. Only prefixes with the status ALLOCATED and LEGACY are
allowed. Note that IPv4 LEGACY is not allocated to a RIR.
Martians is a humorous term applied to packets that turn up
unexpectedly on the wrong network because of bogus routing entries. Bogons
are packets sourced from addresses that have not yet been allocated
by IANA or a RIR, or not delegated to a RIR by IANA as described above.
Martians and Bogons SHOULD NOT be used as an addressed used by a name server.
The use of underlying protocols for DNS is described in Section 4.2 of
.
The Internet supports name server access using TCP on server port 53
(decimal) as well as datagram access using UDP on UDP port 53
(decimal). Today DNS is used in conjunction with both IPv4 and IPv6,
Name servers configured for a zone in a delegation MUST be able to answer
queries using the DNS protocol.
DNS queries are sent using UDP on port 53, as described in Section 4.2.1 of
. A name server MUST respond to DNS queries over UDP for each
IP address configured for that name server.
In addition to UDP, DNS queries can also be sent using TCP on port 53, as
described in Section 4.2.2 of . A name server MUST respond to DNS
queries over TCP for each IP address configured for that name server. This
requirement has also been further clarified in , which makes TCP a
REQUIRED part of a full DNS protocol implementation.
It should be noted that even though requires TCP for a DNS protocol
implementation, it does not make specific recommendations to operators of DNS
servers. However, it also notes that failure to support TCP (or the blocking of
DNS over TCP at the network layer) may result in resolution failure and/or
application-level timeouts. The operational requirements on DNS Transport over TCP are further discussed .
To ensure consistency in DNS, an authoritative name server SHOULD NOT be
configured to do recursive lookups. Also, open recursive resolvers are
considered bad Internet practice due to their capability of assisting in large
scale DDoS attacks. The introduction to elaborates on mixing
recursor and authoritative functionality. Section 2.5 of have very specific requirement on disabling recursion functionality on root name servers.
EDNS0 is a mechanism to announce capabilities of a DNS implementation, and is
now basically required by any new functionality in DNS such as DNSSEC.
Initially standardized in and later updated by , EDNS0 is
a mechanism to announce capabilities of a DNS implementation.
The DNS standards require that name servers treat names with case insensitivity.
That is, the names example.com and EXAMPLE.COM should resolve to the same IP
address. However, in the response, most name servers echo back the name as it
appeared in the request, preserving the original case. This is specified in
and , and further clarified by .
Therefore, another way to add entropy to requests is to randomly vary the case
of letters in domain names queried. This technique, also known as "0x20"
because bit 0x20 is used to set the case of of US-ASCII letters, was first
proposed in , Use of Bit 0x20 in DNS Labels to
Improve Transaction Identity. With this technique, the name server response must
match not only the query name, but the case of every letter in the name string;
for example, wWw.eXaMpLe.CoM or WwW.ExamPLe.COm. This may add little or no
entropy to queries for the top-level and root domains, but it's effective for
most hostnames.
For DNS resolver behaviour to be consistent for a domain, it is important that
the authoritative data for the domain to be consistent. All authoritative name
servers for a zone should serve the same data, although it should be noted that
there exists cases where authoritative name servers are configured to reply
with different answers depending on the client source address and/or query
options such as EDNS0 client subnet option as specified in .
An indicator of inconsistency is that infrastructure records (e.g., SOA and NS)
differs between the authoritative name servers.
Section 4.6 in advices that data synchronisation in an anycast setup
should be done in a manner so that anycast nodes operate in a consistent manner.
An indication that not all authoritative name servers have a consistent
and updated copy of the zone is that the serial numbers differ. When querying
for the SOA RR all name servers SHOULD respond with the same SOA serial number.
Section 4.3.5 in explains the typical function of the serial
numbers in zone maintenance and transfers.
One should note that even though different SOA serial numbers are a strong
indicator of an inconsistent setup, there are several scenarios where the
serial number varies between name servers. One example is a zone with frequent
updates to zone data, where propagation delay between the name servers may
result in limited inconsistency.
As per Section 3.3.13 of , the RNAME field in the SOA RDATA refers
to the mailbox of the person responsible for the zone. An indication that not
all authoritative name servers have a consistent and updated copy of the zone
is that the RNAME differs. When querying for the SOA RR all name servers SHOULD
respond with the same SOA RNAME.
The inconsistency of the SOA parameters REFRESH, RETRY, EXPIRE and MINIMUM,
defined in Section 3.3.13 of , might lead to operational problems
for the zone. These SOA parameters SHOULD be consistent for all authoritative
name servers for the zone.
All authoritative name servers MUST serve the same NS record set in
order to ensure consistency in the zone cut as described in Section
4.2.2 of [!]. Any inconsistency of NS records described in Section
3.3.11 of RFC 1035 might result in operational failures.
is a BCP on how to select and operate secondary name servers,
and summarize many operational issues with the delegation of a zone.
For a delegation to work continuously if one component fails, there
are operational considerations to ensure this.
Section 4.2.2 also adds that the administraters of both
the parent and child zone should ensure that NS and glue RRs on both
sides of the zone cut are consistent.
Section 4.1 states that by administrative fiat we require
every zone to be available on at least two name servers. Section 5
of that answers the question on how many name servers are
needed, the recommendation is that "three servers be provided for most
organisation level zones, with at least one which must be well
removed from the others."
In order to avoid any operational problems, a delegation SHOULD contain
at least two (2) authoritative name servers.
As per the name resolving algorithm described in the NS RR
in the child zone is authoritative for the zone, and any delegation hints
in the parent are discarded in the resolving process. The NS RR set in
the parent zone SHOULD be a subset of the NS RR set in the child zone.
, Section 3.1 states that distinct authoritative name servers for a
child domain should be placed in different topological and geographical
locations. The objective is to minimise the likelihood of a single failure
disabling all of them. Further support for this is given in Section 5:
It is recommended that three servers be provided for most
organisation level zones, with at least one which must be well
removed from the others.
To avoid any single point of failure in networking, the name servers SHOULD
exhibit network path diversity. Using current routing technology, this means
that all name servers SHOULD NOT be placed within a single routing domain,
or AS (autonomous system).
A common workaround to a registry policy that requires at least two
name servers is to create two (2) names with the same IP address.
To avoid any operational errors and workaround such as this, all
name servers used for the zone MUST use distinct IP addresses.
The DNS still defaults to using UDP, although efforts into requiring
or transitioning to use TCP have come a long way. The UDP packet limit
is 512 bytes, and although the EDNS0 extension mechanism
to overcome this limit have been in use for a very long time, many
middleboxes and proxies still interfere with DNS packets ().
To avoid any such problems with the delegation, and to avoid any
unexpected truncation of a referral response, the referral containing
the delegation from the parent SHOULD fit within 512 bytes.
A name server that does not answer authoritatively for the zone is a
clear sign of misconfiguration, and is a common cause for operational
problems.
Section 6.1 of mandates that the name servers MUST answer
authoritatively for the zone.
The configured zone on the child name servers MUST match the delegated
name of the zone. When querying the child name servers for the zone,
any authoritative data for another name MUST NOT be in the response.
states that the SOA RR and the NS RR indicates the origin
of the zone, and both are mandatory records in a zone. Both RRs MUST
be present and match the name of the zone.
In-bailiwick glue for name servers listed at the parent SHOULD match
the in-bailiwick glue for the name servers in the child.
If the glue address mismatch between the parent zone and the child, this
is a strong indication of configuration error.
The hostname of the MNAME field may or may not be listed among the delegated
name servers, but SHOULD still be authoritative for the zone. MNAME may be used
for other services, e.g., DNS NOTIFY [RFC1996] and DNS Dynamic Updates
[RFC2136].
It should be noted that there are no formal requirement that the name server
listed in the SOA MNAME is reachable from the public Internet. Because of this,
it may be difficult to implement a reasonable test for this requirement.
If DNSSEC is used for the zone, either by indicating that the zone is
signed with a DS record, or the use of a DNSKEY in the zone itself, a
number of things are required for a fully functional delegation.
The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System, and was
first introduced with the RFCs , and .
The are also a number of additions to DNSSEC such as NSEC3 described
in , and a number of algorithms to the cryptographic functions.
The The Digest Type Field is defined as part of the DS RDATA Wire Format
of Section 5.1.3 in . The appendix A.2 defines the initial set of
digest algorithm types with possible future algorithms. The IANA registry
for DS Digest Types was defined by .
Any DS Digest Type used for a zone MUST be assigned by IANA.
The DNSKEY RR is defined in Section 2 of as part of the DNSKEY
RDATA Wire Format. The appendix A.1 defines the initial list of DNSKEY
Algorithm Types. The IANA Registry for DNSKEY Algorithm Types
was created with .
Any DNSKEY algorithm number used for in a zone MUST be assigned by IANA.
A valid authentication chain from the parent DS, as described in Section 3.1 of
, MUST exist for the SOA, DNSKEY and NS records of the child zone
if a DS record is published in the parent zone.
DNS delegations from a parent to a child are secured with DNSSEC by publishing
one or several Delegation Signer (DS) resource records in the parent zone,
along with the NS records for the delegation.
As stated in Section 2.4 of , a DS RR SHOULD point to a DNSKEY RR
that is present in the child's apex DNSKEY RRset. If there is a DS RR published
at the parent, there MUST be at least one DNSKEY RR in the child zone that
matches at least one DS RR for every signature algorithm, otherwise the
authentication of the referral will fail, as described in Section 5.2 of
.
For each unique algorithm from the DS RRs present, there MUST be a
matching DNSKEY using that algorithm in use in the child.
Section 10.3 of [RFC5155] specifies the max number of NSEC3 iterations allowed
for different key sizes. This requirement is enforced by several resolver
implementations.
The number of NSEC3 iterations MUST NOT be higher than what is allowed by
Section 10.3 of [RFC5155]. It should be noted that the values in the table MUST
be used independent of the key algorithm.
describes operational considerations on the choice of validity
periods for RRSIGs. Having too short validity periods might cause
operational failure in case of unexpected events, but is good for
protecting against replay attacks. Having too long validity periods may
be good for operational security, but opens up for replay attacks.
The RRSIG validity periods in the zone SHOULD NOT be too short nor too long.
If the zone is signed, the name servers MUST be able to include RRSIG RRs
as additional data in any response when the query has the DO bit set, as
described in Section 3.1.1 of .
If the zone is signed, the name servers MUST be able to include NSEC/NSEC3 RRs
as additional data in any response when the query has the DO bit set, as
described in Section 3.1.1 of .
All domain- and host names in DNS MUST follow the rules outlined in
Section 2.3.1 of . The Name Syntax and LDH Label have been
further clarified in Section 11 in and Section 2.3.1 in
. From this follow the requirements below.
There MUST NOT be any illegal characters used in the domain name. The
domain name MUST follow the rules defined in Section 2.3.1 of
, Section 2.1 of , Section 11 of
and Section 2 of .
The effort of internationalization of domain names and the development
of IDNA brought us the extension mechanism of using the string 'xn--'
to have a special meaning. To allow future extensions to DNS there
SHOULD be no instances of labels in the DNS that start with two
characters, followed by two hyphens, where the two characters are not
"xn". This has been described in Section 5 of .
The Name Server name MUST be a valid hostname according to the rules
defined in Section 2.3.1 of , in Section 2.1 in [RFC1123],
Section 11 in and Section 2 and 5 in .
As specified in Section 10.3 of , the Name Server name MUST NOT be an alias (CNAME).
The SOA RNAME field is a mailbox address defined in Section 3.3 of
and Section 2.2 of . The RNAME field MUST follow the rules of an
e-mail address defined in Section 3.4.1 of , and the '@' character
MUST be changed so that the whole e-mail address is converted into a single
domain name as described in Section 3.3 of and Section 2.1 of
.
The SOA RNAME field is a mailbox address. The SOA RNAME field is defined in
Section 3.3 of and Section 2.2 of . As a field containing
a domain name, the content of the RNAME field MUST follow the rules outlined in
Section 2.3.1 of and Section 2.1 of .
The SOA MNAME field is a hostname. The SOA MNAME field is defined in Section
3.3.13 of . As a field containing a domain name, the content of the
RNAME field MUST follow the rules outlined in Section 2.3.1 of .
Furthermore, Section 7.3 in makes it clear that the SOA MNAME field
SHOULD NOT be the name of the zone itself.
The requirement on the existence of an MX RR in the apex of the child zone may
vary by policy from different parent zones. However, it is strongly recommended
in Section 7 of that all domains should have a mailbox named
hostmaster@domain. SMTP can make a delivery without the MX, using the A or AAAA
record as specified in Section 5.1 of .
If an MX RR exists in the apex of the child zone, the hostname that
the MX RR points to MUST follow the rules outlined in Section 2.3.1
of and Section 2.1 of .
This document has no security considerations (yet).
This document has no IANA actions.
The requirements documented in this document were developed within the CENTR
Test Requirements Task Force (TRTF). Most of the original requirements and
text come from the Zonemaster project.
Domain Name System Security (DNSSEC) Algorithm Numbers
IANA
Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
IANA
IANA IPv4 Address Space Registry
IANA
IANA IPv4 Special-Purpose Address Registry
IANA
IANA IPv6 Special-Purpose Address Registry
IANA
IPv6 Global Unicast Address Assignments
IANA