Where does IBDNS stand two years after going open source?

What does the new mini-language-driven configuration system offer?

In earlier versions of IBDNS, behaviour could only be configured based on the queried domain name. This proved to be insufficient. Faulty behaviour needed to be triggered when an incoming query met specific criteria that went beyond the queried domain name.

To address this, version 0.5.0 introduces a new configuration file format. It now allows rules to be defined. So, if an incoming DNS query matches one or more criteria expressed in the mini-language, the server will trigger the corresponding failure mode.

For example, the rule below could not be expressed in the previous configuration system. It indicates that the server should not respond to EDNS queries if the queried name (“QNAME”) is breaks-on-edns.test or one of the subdomains and the query contains an EDNS option with the identifier 65,500.

In short, one of the goals of IBDNS is to be able to reproduce bugs on demand that have been observed in other authoritative name servers. This new system provides much finer control over IBDNS’s behaviour, allowing it to simulate these faulty servers much more faithfully.

What is the Diátaxis approach, and why is the IBDNS documentation designed around it?

Diátaxis is a methodology for writing technical documentation. Its main characteristic is that it makes a clear distinction between tutorials, guides, explanatory documents, and reference material.

IBDNS is designed to offer numerous configuration options whose purpose and function must be rigorously documented. Which is why I decided early in the development process to adopt the Diátaxis approach for the documentation.

For IBDNS, reference documentation is the most important of the four Diátaxis categories, particularly when it comes to configuration options. Each parameter is carefully documented. It begins with a summary of the possible values, followed by a detailed description of its effects. It then identifies the violated specifications and the consequences, before concluding with how the parameter can be used.

The idea is to reproduce the faulty behaviour of some authoritative name servers in an edge case. For example, it is possible to have records at zone.example and records at the subdomain key._domainkey.zone.example (for a DKIM key, for example).

In this case, _domainkey.zone.example is a name that exists but contains no records. This is known as an empty non-terminal (or ENT). So, a query for _domainkey.zone.example, should return a NOERROR response code. Instead, there are some servers that incorrectly return NXDOMAIN, as if the name does not exist, indicating a bug in the server.

Unfortunately, this is a common bug that clients must be able to handle. For example, they should cache only the fact that _domainkey.zone.example does not exist rather than treating the entire subtree as non-existent.

How has IBDNS been used in practice?

In October 2025, some colleagues and I took part in a DNS hackathon in Stockholm organised by Internetstiftelsen, DNS-OARC and Netnod. The hackathon was an opportunity to work with IBDNS, and I gave a lightning talk on the topic at RIPE 91 in late October 2025.

The project I worked on involved implementing a proposed DNS extension that would allow a client to request that the server return the server time in its response
(draft-liman-dns-utcstamp-00). This extension makes it possible to diagnose problems caused when one server in a cluster is not synced to the same time.

I worked with the specification’s author to implement it in the IBDNS server while he implemented the client side with a modification to dig. With the extension, dig was able to display the time returned by the server.

Because the specification was so simple, I had plenty of time to start adding support for EDNS in IBDNS, which was a prerequisite for the next steps. I then implemented the specification itself and added the failure modes, as follows:

• Omit the time from the response even if the client requested it.
• Return the time even if the client didn’t request it.
• Return the special value to signal that the time information is missing.
• To be sneaky, apply a time offset (set in the configuration file) relative to the time returned by the server.
• Even more sneaky, return random bytes in place of the correct time.

This made it possible to verify that the modified dig could handle these failure modes. The first time, when I suggested testing on the domain that returns random bytes, the client crashed because the code was not robust enough. But he was able to correct and test it completely on his own.

In the end, we had two implementations of the extension on the server: in BIND and in IBDNS.
Plus a client-side implementation in dig.

The hackathon demonstrated that IBDNS is a useful tool for testing DNS clients and for development when working with a new DNS extension. That’s also where Ibby was born, the IBDNS mascot shown at the top of this post.

Conclusion

We’ve seen how IBDNS has evolved since Afnic officially announced its release as open-source software. There are still a lot of items on the roadmap, and we also have plans to expand the range of failure modes it offers.

In the meantime, whether you are developing a DNS client or a DNS test tool or you are simply interested in the server’s architecture, you can explore the IBDNS GitLab repository at Afnic Labs.