DNS delegation is set for an update

Hints

The existing NS records in the parent zone, and the associated glue records, are merely hints to the authoritative name servers for the relevant child zone. Because the parent zone isn't authoritative for the child zone, the records in it aren't signed. Although the NS records in the authoritative child zone are of course signed, they are not generally re-consulted by resolvers (although there is a proposal for that to become standard practice). However, the DS records (in the parent zone), which serve to authenticate the DNSKEY records for the signatures in the child zone, are authoritative and are therefore signed.

Although the NS records in the parent zone are considered to be copies of the authoritative NS records in the child zone, the arrangement is error-prone, and often leads to problems in practice. Everything works as long as a resolver is able to maintain contact with an authoritative name server for the child zone in question. And, if the child zone is signed using DNSSEC, a validating resolver can be confident that all the DNS information it receives is authentic.

RFC 7477 does provide a mechanism for automating the copying of new records to the parent zone. The procedure involves the child zone publishing all the information for the new NS and glue records in a set of CSYNC records, which can then be fetched by the parent zone. In order to prevent a delegation being diverted by a man-in-the-middle attacker, the use of DNSSEC is mandatory in that context. The CSYNC mechanism therefore complements the CDS/CDNSKEY mechanism defined in RFC 7344, which can be used in a similar way to modify the DNSSEC link in the parent zone.

For everything to work as intended, the parent zone does, of course, need to regularly scan the authoritative name servers for its child zones. However, we are not yet working with either of the mechanisms here at SIDN.

Authoritative delegations

Both of the new delegation proposals come from the IETF DNS Delegation Working Group (deleg). The main challenges that the working group is looking to address are:

• The specification of authoritative name servers that support a form of cryptographic encryption

• Support for name server aliases (in order to make it easier for registrars/registrants to contract out DNS server operation to DNS service providers)

• Synchronisation between child and parent zones

In the following paragraphs, we begin by looking at how those challenges can be addressed using the DELEG mechanism, before turning our attention to the alternative '_deleg' mechanism towards the end of the article.

If introduced, the new DELEG record type will make delegation to subdomains explicitly top-down and authoritative. The old soft delegation method will be replaced by a method aligned with the hard, authoritative DS linkage of the DNSSEC hierarchy. In addition, the DELEG record type will make it possible to specify encrypted connections, so that the confidentiality of the DNS traffic is also assured.

The DELEG record type's design follows the format of the existing Service Binding (SVCB) record type (defined in RFC 9460 and RFC 9461). A delegation made using a DELEG record (in addition to the existing NS and glue records) would typically look something like this:

; new DELEG record (authoritative) with hints:
example.nl. IN DELEG 1 ns1.example.nl.
( ipv4hint=198.51.100.3 ipv6hint=2001:db8::fffe:3 )
; existing NS and glue records (non-authoritative):
example.nl. IN NS ns1.example.nl.
ns1.example.nl. IN A 198.51.100.3
ns1.example.nl. IN AAAA 2001:db8::fffe:3

In that example, the traditional delegation is replaced by a new, authoritative DELEG record, which not only brings together the information previously contained in the NS and glue records, but also allows for the inclusion of various new pieces of information. For example, a port number can be provided for the name server (e.g. ‘port=53'), and an encrypted transport mechanism can be mandated (e.g. 'alpn=dot').

Indirections

An important feature for service providers is the ability to specify indirections. In the example above, the '1' indicates that the DELEG record is being used in ServiceMode, implying that the data relates directly to a set of name servers.

Alternatively, the DELEG record could also be used in AliasMode, where it points to an SVCB record for the name servers and the transport mechanism. An AliasMode record might look something like this:

example.nl. IN DELEG 0 dnsconfig2.example.net
dnsconfig2.example.net IN SVCB 1 .
( ipv4hint=198.51.100.3 ipv6hint=2001:db8::fffe:3 )

However, in AliasMode, an SVCB record can also point to a subsequent SVCB record (or CNAME record), opening the way for the application of multiple indirections relating to various domains (subject to a limit of 4 levels). Service providers and DNS operators will therefore be able to share delegations for multiple subdomains hosted and administered at a central location.

DNSSEC signing

When DELEG is used, DNSSEC isn't mandatory, but is strongly recommended for the prevention of substitution attacks. An unsigned DELEG record can be used only if fetched via an encrypted connection (DoT/DoH/DoQ).

In the DNSKEY record of a parent zone that is signed, the (new) DELEG flag is set if the zone also contains a DELEG record. That serves both to alert validating resolvers that the zone in question supports DELEG, and to protect against downgrade attacks (by man-in-the-middle attackers who delete the DELEG records and associated signatures).

Replacement of the old delegation method

The intention is that all NS and glue records in parent zones will ultimately be replaced by the new DELEG and SVCB records. However, the switch can't be completed until all DNS resolvers are familiar with DELEG. A resolver that supports DELEG will be able to explicitly ask for a domain's DELEG records (rather than the NS and glue records) by setting the new DE flag in its query. If the resolver doesn't set the flag, the server will send back all the DELEG, NS and glue records it has for the queried domain.

The main advantage of DELEG is the support for indirections and CNAME aliases (in contrast to an NS record, which has to point to an actual host name). That allows service providers and DNS operators to make bulk changes without modifying the parent zone.

Adoption of the DELEG mechanism will require both name servers and resolvers to support the new record type [1]. Addition of the DELEG record will also imply the extension of dashboards and provisioning protocols such as EPP and RPP [1]. Fortunately, however, the old and new mechanisms can operate side-by-side while the transition is in progress.

Recursive resolvers that don't support the new delegation mechanism are likely to be around for many years after DELEG is introduced. Consequently, authoritative name servers that have added DELEG records to their zones will need to go on making NS and glue records available as well.

Alternative proposal

The proposed introduction of a new DELEG record type is not the only option under consideration. The same working group has put forward an alternative: incremental delegation. This mechanism would have the same capabilities as the DELEG mechanism, but would facilitate introduction by minimising the need for changes to the existing DNS system.

Under this alternative proposal, there would be no DELEG record, and the DNS's existing SVCB record (defined in RFC 9461) would be used instead, with a new '_deleg' label applied, as in 'example._deleg.nl.'. Adoption of this approach would require specific support only on the resolver side, and the use of DNSSEC would not be mandatory.

An SVCB record with the '_deleg' label could be added immediately, without the need to modify the parent domain's zone file. Adoption would not depend on a new record type and a new flag being supported (section 7.3). However, the proposal's authors do recommend various improvements that could be made on the server side if the idea is implemented.

As a proof of concept, the development team at NLnet Labs implemented incremental delegation in de Unbound resolver last summer.

The DELEG camp's main criticisms of the incremental delegation mechanism (appendix C) are that it isn't a good fit with the design of the DNS, and that it would increase network traffic.

Migration

To sum up, although the functionality of a modern DNS delegation mechanism has been decided, the best form of implementation remains a topic of debate. What's more, even once consensus is achieved, it's likely to be a good few years before everyone is using the mechanism.