This is the fifth part of a series of blog posts we are publishing, mostly around recent developments with respect to PowerDNS Recursor. The first blog post was Refreshing Of Almost Expired Records: Keeping The Cache Hot, the second Probing DoT Support of Authoritative Servers: Just Try It, the third Sharing data between threads in PowerDNS Recursor and the fourth Structured Logging in PowerDNS Recursor.
ZONEMD is a DNS record type that was introduced quite recently in RFC8976. ZONEMD records are used to validate DNS zone contents. You may ask: why is that needed, as DNSSEC already provides validation? There are several reasons for a independent validation technique that is well-integrated into the zone file format to exist:
- Not all zones are DNSSEC signed.
- Even in DNSSEC signed zones, not all records are signed. In particular, delegation and glue records are not signed.
- The existing TSIG validation method is only used during transfer and only applies to zones being transferred using AXFR or IXFR and requires pre-arranged shared keys. There is no way to TSIG sign a zone on file.
- PGP or similar signatures on files are file layout dependent and require either separate transfer or a zone file format extension that is unlikely to be generally adopted.
It was decided to define a mechanism to compute a cryptographic digest of the zone data that can easily be incorporated in a zone file because it is a DNS record. For the same reason the digest information can be transferred using either DNS specific zone transfer methods or any other method to transfer a file. The receiver of the zone can then validate the contents of the zone using the digest to detect corruption. If the zone is DNSSEC signed, the receiver can also verify the authenticity of the digest record used to validate the zone contents and, by extension, validate the authenticity of the full zone contents.
ZONEMD
An example ZONEMD record looks like:
example. 86400 IN ZONEMD 2018031900 1 1 8ee54f64ce0d57fd70e1a4811a9ca9e849e2e50cb598edf3ba9c2a58625335c1f966835f0d4338d9f78f557227d63bf6
In order, domain, TTL, class and type are part of every DNS record. 2018031900 is the serial and should correspond to the serial in the SOA record of the zone. The 1 1 are the scheme and hash algorithm which we will not describe here. The hex string is the actual digest. If the software exporting the zone does not know the presentation format for ZONEMD records, it will use the generic format. In that case, the same record will look like:
example. 86400 IN TYPE63 # 54 7848b91c01018ee54f64ce0d57fd70e1a4811a9ca9e849e2e50cb598edf3ba9c2a58625335c1f966835f0d4338d9f78f557227d63bf6
Any software receiving a zone containing a ZONEMD record can validate the digest by ordering all records in wire format in a well defined way (that is also used for DNSSEC), compute the specified cryptographic digest on that data (handling the ZONEMD record in a special way) and then compare the computed digest to the digest specified in the actual ZONEMD record. We will not go into details on how the digest is computed exactly. If you are interested, you can read about it in the RFC mentioned above.
If the zone is DNSSEC signed, the software can also validate the ZONEMD record’s associated RRSIG in the standard way to make sure that the ZONEMD record is authentic. That means the ZONEMD digest is coming from the zone owner. As the ZONEMD digest covers the whole zone data, you can be sure that whole zone is authentic if both the ZONEMD digest and its DNSSEC signature validate properly.
ZONEMD and PowerDNS
With the latest releases, ZONEMD validation is available in two places:
pdnsutil (part of the PowerDNS Authoritative Server software) can be used to validate ZONEMD digests in zone files only.- In PowerDNS Recursor ZONEMD validation is implemented when loading zones into the record cache using the
zoneToCache function.
With the zoneToCache function, ZONEMD validation happens with all three (axfr, file and url) transfer methods and parameters can be set to ignore, validate (if present) or require ZONEMD validation and DNSSEC validation of the ZONEMD record.
A typical use of zoneToCache is to load the root zone into the cache. At the moment of writing, the root zone file published by internic.net does not include ZONEMD record(s), but in the near future it will. From that moment on, PowerDNS Recursor will perform validation ensuring the retrieved root zone is not corrupted by accident and if DNSSEC is activated it will also ensure the zone contents are authentic.
Future
In the future, we will implement ZONEMD functionality in more places. For PowerDNS Authoritative server that includes validation but also generation of ZONEMD records. For PowerDNS Recursor, future work will include validation of zone transfers and local files used both by RPZs and local authoritative zones.
Conclusion
ZONEMD records provide a way to detect corruption and ensure authenticity of zone data. PowerDNS software is ready to start validating ZONEMD records for specific use-cases, and will do so in more places in the future.
PowerDNS Blog 