The PowerDNS Recursor has a proven track record — it has been serving recursive answers for millions of users for many years, with very few complaints. To preserve this robustness that people have come to rely on, any major changes should happen very carefully. In this blog post, we aim to explain our plan for adding DNSSEC to the Recursor, without compromising our current stability.
It is because of this robustness that we have decided that, at least initially, DNSSEC validation for the PowerDNS Recursor will be a separate project and a separate daemon. As it turns out, there are also technical and development benefits to this split. Eventually, from a functional standpoint, the split might become a technical detail that need not bother the administrator.
Traditionally (unbound, BIND), DNSSEC validators have had the recursor and the validator in a single process, providing some performance benefits (pass around pointers instead of sending packets, some cache sharing, grabbing DS records while iterating downwards, the list goes on). However, this combination may increase complexity of both parts if they are coupled too closely — although we have also seen issues in other implementations that appear to stem directly from a lack of information sharing between the two.
The DNSSEC RFCs (4033/4034/4035 and 6840) explicitly designate various roles that can be implemented in separate applications. While, as said, current implementations do not separate these roles, they can be told (through configuration or through DNS query flags) to stick to specific roles.
Our plan is two-fold.
One, we will upgrade the PowerDNS Recursor to perform, in words inspired by RFC 4033, the role of a ‘Non-Validating Security-Aware Resolver’. This is the role that other DNSSEC-aware recursors play when they receive ‘Checking Disabled’ queries. In other words, the Recursor supports all relevant DNSSEC records (RRSIG, DS, NSEC[3]), understands how they interact, and knows when to send those records along with query results. The current Recursor [3.3/3.5.x], as used in production by many parties, is a very lean communication machine that prefers to spend time waiting on the network, instead of doing calculations, and the design reflects this. As such, adding cryptography operations to the Recursor would destroy many of the benefits of the current design. Because of this, there will be no crypto in the Recursor — at least for now.
Two, we will build a Validator that is a client to a Security-Aware Resolver, expecting no validation from it. This validator does no recursion of its own, relying on the Resolver it is pointed to for that. In that sense, it is a bit like a ‘Validating Security-Aware Stub Resolver’, except that it takes queries from clients. This is similar to running other validating recursors in a forwarding mode. The validator receives queries from clients, collects all the data it needs to decide on the security of an answer (keeping in mind the four security states defined in RFC 4033 section 5 or RFC 4035 section 4.3), and returns a useful response to the client.
In theory (and, from what we have seen so far, also in practice!) this means that either part can be replaced with another validating recursor (like BIND or Unbound) and the system as a whole will keep operating. This allows individual developers to focus on one side of the PowerDNS Validating Recursor equation at a time, while relying on proven code for the other side. In the end, we will provide robust implementations of both sides, of course.
We are currently experimenting with implementation details on both ends, making sure our behaviour checks out with both reality and the relevant standards, and making sure we interoperate with the existing validators and existing authoritative implementations. As our code is in heavy flux right now, we are holding off on releasing for just a bit. We hope to release a stable base for the new Validator and the modified Recursor within a few weeks, and we cordially invite the community to join us at that time — either to make things or to break them! Implementing a full DNSSEC validation stack means ticking a lot of boxes, and we do not expect to tick them in a few weeks.
If you have questions, please let us know in the comments, via Twitter (@PowerDNS), via IRC or via our mailing lists. If there is demand, we will post a follow-up article with some more technical details.
