Zone verification, the feature formerly known as CreDNS, formerly known as dnSƧexy

By Jeroen Koekkoek and Benno Overeinder

With DNS Security Extensions (DNSSEC), a great responsibility lies with the publication of a correctly (DNSSEC) signed zone. While the DNS is known for its robustness and almost always returning an answer even if partial data is found in zones, with DNSSEC any error in the signing process results in a bogus zone. Zone verification prevents zones with errors in DNSSEC signed data from being made public by qualifying the zone as invalid in the process. Verification can be applied to inbound zone transfers and locally administered zone data, and while originally designed specifically for DNSSEC, the feature can also be used to perform other desired checks, e.g. to verify the Message Digest for DNS Zones.

Design Considerations

There are quite a few DNS(SEC) verifiers already available. Usually, they operate in one of two ways:

• Read the zone file to detect errors before the zone is published.
  Not always possible. E.g. when the operator depends on a proprietary signer, or uses a provisioning system that does not allow access to zone data before it is published.
• Query the zone after it has been published.
  Too late. At that point the zone has already been invalidated.

Zone verification in NSD is designed as a bump-in-the-wire solution and can be considered a zone transfer proxy that only propagates the update if the zone, with updates applied, passes all the checks. And, rather than reinventing the wheel, the existing tools can be used for verification. To the other servers in the chain, the NSD instance with verification enabled is just another nameserver.

The verifying NSD instance sits between the hidden primary and the public facing secondary servers and requests a zone transfer whenever it is notified of an update or the refresh timer expires. The update process is very much the same as it is on non-verifying NSD instances, except that just before the updated zone is published, a verifier is executed. Based on the exit code of the verifier, which to NSD is simply a command, NSD either publishes or retracts the updated zone. Variables are set in the environment in which the command is executed so that the verifier knows which address+port can be used to query the zone, e.g. to verify the SOA record with drill or dig, and whether zone data can be read from stdin or not, e.g. to verify with ldns-verify-zone or validns.

NSD Internals

NSD serves zone data from a main memory database, utilizing the copy-on-write memory behavior of the fork system call for lock-free operation. This design makes NSD performant while minimizing code complexity. Reload operations cause the main server to fork a new instance and updates to be applied. If any update fails to apply, the server exits and the current database remains in use until a reload operation is successful. Once a reload is successful, which is usually the case, the new server forks a set of servers that will deal with incoming queries and the servers with outdated databases terminate. This behavior fits zone verification very well because existing zone data is never purged before a valid copy is available.

The fact that NSD forks is also the reason why updates are applied in a batched fashion. Creation and termination of servers is relatively expensive and therefore must be controlled.

Changes from CreDNS

CreDNS was based on NSD3, which has been superseded by NSD4 on October 29th 2013. With zone verification being a part of NSD 4.6.0 and newer, its future is safeguarded going forward and a number of issues have been addressed.

• NSD3 used a continuous difffile to store updates (ixfr.db) which could potentially fill up the disk on replication failures. A side-effect being that each reload included newly received updates, possibly causing valid updates to be delayed.
  
  NSD4 keeps transfers in separate files. Zone verification builds on that and introduces a reload window. A batch of updates is finished before new updates are tried, thereby eliminating valid updates being delayed if corrupt or inconsistent updates are received before a reload finishes. All updates in a given window are deleted when a reload finishes, keeping the disk from filling up.
• NSD4 introduced patterns, a convenient way to apply the same configuration to multiple zones. Zone verification can now be enabled or disabled and configured globally, per pattern and per zone.
• Last but not least, NSD4 introduced IXFR-out in version 4.5.0. With this feature, zone verification with NDS4 is really a bump in the wire in an IXFR-in – DNSSEC zone verification – IXFR-out pipeline, whereas with CreDNS/NSD3 it always resulted in an AXFR-out down the line.

Configuration

To enable zone verification for all zones, enable: it in the new verify: section and configure a verifier:.

verify: enable: yes  
verifier: ldns-verify-zone -V2  
verifier-timeout: 10  
verifier-feed-zone: yes

verify-zones: no can be added to disable zone verification globally. verify-zone: yes can instead be specified per-pattern or per-zone to enable it selectively.

verify:
  enable: yes
  verify-zones: no
  ip-address: ::1

pattern:
  name: "zones-to-verify"
  verify-zone: yes
  verifier-timeout: 10

zone:
  name: "example.com"
  include-pattern: "zones-to-verify"
  verifier: drill -S -k example.com.ds @::1 -p 5432 example.com SOA

zone:
  name: "example.net"

Verifier options are carried down, so verifier:, verifier-timeout: and verifier-feed-zone: values from the verify: section are used if not configured per-zone or per-pattern.

Acknowledgements

This work was funded in part by SIDN and DENIC, who generously supported our work and recognised the value of zone verification to the DNS community.

Willem Toorop’s presentations from RIPE64 and ICANN44 were used as inspiration. Some of the figures were used for detail and a bit of nostalgia.