Duane Wessels is a Fellow at Verisign, with a focus on DNSSEC projects and root zone operations. This post originally appeared on the Verisign Blog.
The Domain Name System (DNS) root zone will soon be getting a new record type, called ZONEMD, to further ensure the security, stability, and resiliency of the global DNS in the face of emerging new approaches to DNS operation. While this change will be unnoticeable for the vast majority of DNS operators (such as registrars, Internet Service Providers (ISPs), and organizations), it provides a valuable additional layer of cryptographic security to ensure the reliability of root zone data.
In this blog post, we’ll discuss these new proposals, as well as ZONEMD. We’ll share deployment plans, how they may affect certain users, and what DNS operators need to be aware of beforehand to ensure little-to-no disruptions.
The root server system
The DNS root zone is the starting point for most domain name lookups on the Internet. The root zone contains delegations to nearly 1,500 top-level domains, such as .com, .net, .org, and many others. Since its inception in 1984, various organizations known collectively as the Root Server Operators have provided the service for what we now call the Root Server System (RSS). In this system, a myriad of servers respond to approximately 80 billion root zone queries each day.
While the RSS continues to perform this function with a high degree of dependability, there are recent proposals to use the root zone in a slightly different way. These proposals create some efficiencies for DNS operators, but they also introduce new challenges.
New proposals
In 2020, the Internet Engineering Task Force (IETF) published RFC 8806, titled ‘Running a Root Server Local to a Resolver’. Along the same lines, in 2021 the Internet Corporation for Assigned Names and Numbers (ICANN) Office of the Chief Technology Officer published OCTO-027, titled ‘Hyperlocal Root Zone Technical Analysis’. Both proposals share the idea that recursive name servers can receive and load the entire root zone locally and respond to root zone queries directly.
But in a scenario where the entire root zone is made available to millions of recursive name servers, a new question arises — how can consumers of zone data verify that zone content has not been modified before reaching their systems?
One might imagine that DNS Security Extensions (DNSSEC) could help. However, while the root zone is indeed signed with DNSSEC, most of the records in the zone are considered non-authoritative (that is, all the NS and glue records) and therefore do not have signatures. What about something like a Pretty Good Privacy (PGP) signature on the root zone file? That comes with its own challenge; in PGP, the detached signature is easily separated from the data. For example, there is no way to include a PGP signature over DNS zone transfer, and there is no easy way to know which version of the zone goes with the signature.
Introducing ZONEMD
A solution to this problem comes from RFC 8976. Led by Verisign and titled ‘Message Digest for DNS Zones’ (known colloquially as ZONEMD), this protocol calls for a cryptographic digest of the zone data to be embedded into the zone itself. This ZONEMD record can then be signed and verified by consumers of the zone data. Here’s how it works:
- Each time a zone is updated, the publisher calculates the ZONEMD record by sorting and canonicalizing all the records in the zone and providing them as input to a message digest function. Sorting and canonicalization are the same as for DNSSEC. In fact, the ZONEMD calculation can be performed at the same time the zone is signed. Digest calculation necessarily excludes the ZONEMD record itself, so the final step is to update the ZONEMD record and its signatures.
- A recipient of a zone that includes a ZONEMD record repeats the same calculation and compares its calculated digest value with the published digest. If the zone is signed, then the recipient can also validate the correctness of the published digest. In this way, recipients can verify the authenticity of zone data before using it.
A number of open-source DNS software products now, or soon will, include support for ZONEMD verification. These include Unbound (version 1.13.2), NSD (version 4.3.4), Knot DNS (version 3.1.0), PowerDNS Recursor (version 4.7.0) and BIND (version 9.19).
Who is affected?
Verisign, ICANN, and the Root Server Operators are taking steps to ensure that the addition of the ZONEMD record in no way impacts the ability of the root server system to receive zone updates and to respond to queries. As a result, most internet users are not affected by this change.
Anyone using RFC 8806, or a similar technique to load root zone data into their local resolver is unlikely to be affected as well. Software products that implement those features should be able to fully process a zone that includes the new record type, especially for the reasons described below. Once the record has been added, users can take advantage of ZONEMD verification to ensure root zone data is authentic.
Users most likely to be affected are those that receive root zone data from the internic.net servers (or some other source) and use custom software to parse the zone file. Depending on how such custom software is designed, there is a possibility that it will treat the new ZONEMD record as unexpected and lead to an error condition. Key objectives of this blog post are to raise awareness of this change, provide ample time to address software issues, and minimize the likelihood of disruptions for such users.
Deployment plan
In 2020, Verisign asked the Root Zone Evolution Review Committee (RZERC) to consider a proposal for adding data protections to the root zone using ZONEMD. In 2021, the RZERC published its recommendations in RZERC003. One of those recommendations was for Verisign and ICANN to develop a deployment plan and make the community aware of the plan’s details. That plan is summarized in the remainder of this blog post.
Phased rollout
One attribute of a ZONEMD record is the choice of a hash algorithm used to create the digest. RFC 8976 defines two standard hash algorithms — SHA-384 and SHA-512 — and a range of ‘private-use’ algorithms.
Initially, the root zone’s ZONEMD record will have a private-use hash algorithm. This allows us to first include the record in the zone without anyone worrying about the validity of the digest values. Since the hash algorithm is from the private-use range, a consumer of the zone data will not know how to calculate the digest value. A similar technique, known as the ‘Deliberately Unvalidatable Root Zone’, was used when DNSSEC was added to the root zone in 2010.
After a period of more than two months, the ZONEMD record will transition to a standard hash algorithm.
Hash algorithm
SHA-384 has been selected for the initial implementation for compatibility reasons.
The developers of BIND implemented the ZONEMD protocol based on an early Internet-Draft, sometime before it was published as an RFC. Unfortunately, the initial BIND implementation only accepts ZONEMD records with a digest length of 48 bytes (the SHA-384 length). Since the versions of BIND with this behaviour are in widespread use today, the use of the SHA-512 hash algorithm would likely lead to problems for many BIND installations, possibly including some Root Server Operators.
Presentation format
Distribution of the zone between the Root Zone Maintainer and Root Server Operators primarily takes place via the DNS zone transfer protocol. In this protocol, zone data is transmitted in ‘wire format.’
The root zone is also stored and served as a file on the internic.net FTP and web servers. Here, the zone data is in ‘presentation format’. The ZONEMD record will appear in these files using its native presentation format. For example:
. 86400 IN ZONEMD 2021101902 1 1 ( 7d016e7badfd8b9edbfb515deebe7a866bf972104fa06fec
e85402cc4ce9b69bd0cbd652cec4956a0f206998bfb34483 )Some users of zone data received from the FTP and web servers might currently be using software that does not recognize the ZONEMD presentation format. These users might experience some problems when the ZONEMD record first appears. We did consider using a generic record format, however, in consultation with ICANN, we believe that the native format is a better long-term solution.
Schedule
Currently, we are targeting the initial deployment of ZONEMD in the root zone for 13 September 2023. As previously stated, the ZONEMD record will be published first with a private-use hash algorithm number. We are targeting 6 December 2023, as the date to begin using the SHA-384 hash algorithm, at which point the root zone ZONEMD record will become verifiable.
Conclusion
Deploying ZONEMD in the root zone helps to increase the security, stability, and resiliency of the DNS. Soon, recursive name servers that choose to serve root zone data locally will have stronger assurances as to the zone’s validity.
If you’re interested in following the ZONEMD deployment progress, please look for our announcements on the DNS Operations mailing list.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.