New-look DNS Workbench

What is the DNS Workbench?

Several years ago, we were looking for a way of quickly and effectively testing and comparing multiple (authoritative) name server implementations. We didn't only have conventional, obvious settings in mind. After all, they have usually been well implemented and tested by software developers. We were thinking more of 'corner cases' and less commonplace test scenarios. That led to creation of the DNS Workbench, which soon attracted the interest of people outside SIDN. We therefore decided to make the Workbench available as a free on-line service.

The DNS Workbench is an integration of five open-source name server products: BIND9, PowerDNS, Knot, YADIFA and NSD. Each of the name servers acts as primary (master) server for no fewer than 421 zone files automatically generated specifically for the purpose. The zone files can be divided into the following groups:

RR types

Zone files with various RR types, including types that have been declared obsolete and various exotic types, which are rarely encountered in the field, but which name servers may still support. You might like to try the following test:

dig GPOS gpos.types.wb.sidnlabs.nl [@knot.sidnlabs.nl]

The query above concerns the rare GPOS type, and is addressed to the Knot server. To request the much more commonplace AAAA type, the syntax would be:

dig AAAA aaaa.types.wb.sidnlabs.nl [@bind9.sidnlabs.nl]

(to the BIND9-server)

One thing that the experiment shows is that not all name servers support all RR types by default. For example, YADIFA requires conversion to RFC3597 format before it will load the zone file. PowerDNS loads the zone, but the AXFR (zone transfer) process proves problematic. In other words, our tests brought certain bugs to light. YADIFA even crashed with:

dig +tcp ANY delegations.wb.sidnlabs.nl @yadifa.sidnlabs.nl

The bug that caused that crash has now been fixed and we're running an improved version on the Workbench, compiled from the YADIFA source code. Where the other name server software is concerned, we're running the packages supplied with Ubuntu 18.04 for as long as we can.

We offer the zone file with the special RR types in both signed and unsigned form.

Validation tests

This group consists of an extensive 'DNS tree' (called 'bad-dnssec') of zones that feature various types of signing error, which can be used for purposes such as testing DNSSEC validation software.

Illustration: 'ok.ok.ok.bad-dnssec.wb.sidnlabs.nl' is (the only) faultlessly delegated and signed zone in the group. However, the zone 'signotincepted.ok.ok.bad-dnssec.wb.sidnlabs.nl' ends (with the leftmost label) in a delegation that is signed in the future, meaning that the digital signature is not yet valid.

Combinations are also possible. For example, 'signotincepted.nods.ok.bad-dnssec.wb.sidnlabs.nl' is similarly signed in the future, but additionally lacks a parent-zone DS record. The differences can be identified by using DNSviz to examine the latter zone. DNSviz is a very handy debug tool, which can also be tested using the DNS Workbench. The first of the above zones is 'bogus', while the second is actually 'insecure', because its parent zone doesn't contain a DS for it. This experiment provides a range of variations for testing with validating resolvers. From it, we know that most resolvers validate top-down, while some also operate bottom-up, which may have direct consequences for the test scenario described above, for example.

Other errors deliberately included in the 'bad-dnssec' tree are: a digital signature with bogus data, a digital signature that has expired, and a signature set using an unknown, fictitious algorithm.

Delegations

This experiment is intended to test the various (signed) delegation combinations. For example, the zone 'bind9.powerdns.knot.delegations.wb.sidnlabs.nl' is delegated to Knot, which redelegates it to PowerDNS, which in turn redelegates it to BIND9. In other words, the zone is actually held on a BIND9 name server, but a resolver has to go via a Knot server and a PowerDNS server to resolve a domain name. That yields this complex DNSviz visualisation.

Transfers and TSIGs

All the Workbench zone files are publicly available by means of a DNS zone transfer (AXFR). The transfer can be performed with or without TSIG keys (various algorithms), e.g.:

dig axfr ok.bad-dnssec.wb.sidnlabs.nl @nsd4.sidnlabs.nl

or

dig -y "wb_md5:Wu/utSasZUkoeCNku152Zw==" \

axfr ok.bad-dnssec.wb.sidnlabs.nl  @bind9.sidnlabs.nl

Other experiments

Finally, at our users' request, we have added three further zone files. One is a zone file with a CNAME under the APEX, which is not permitted by the standard. Another of the new zone files is designed for NSEC3 opt-out testing.

Suggestions welcome!

Together, the experiments described above enable a wide variety of tests for observing software behaviour and establishing how different tooling handles the various errors deliberately introduced to the DNS zone files.

If you'd like to suggest further refinements, please get in touch! We've already got a few ideas of our own. For example, we'd like to add some more modern signing algorithms such as ECDSA to the test set, plus experiments that focus on IDNs.

If you're already using the Workbench, we'd like to hear from you too. We'd love to know what you use it for, and whether you can think of any improvements that would make it more useful to you.

The Workbench is available from https://workbench.sidnlabs.nl/ and the source code from https://github.com/SIDN/workbench.