home tags events about login
one honk maybe more

benjojo posted 29 Jun 2026 08:44 +0000

The DNS Resolver landscape is somewhat fascinating in that I think by the time you get to the point where you are close to wanting to build a DNS Resolver/Recursor you have already figured out it's hard to get right (in terms of spec compliance), and basically impossible to get right if you care (or need to care) about DNSSEC validation.

It was surprising to find that there are not really any stable/serious memory safe DNS resolvers, Hickory seems to be littered with bugs (Some not strictly it's fault and more the fact that some DNS Auths do not like QName Minimisation, but from what I can tell has a very spotty situation with DNSSEC

For what it is worth, my general views on DNSSEC's usefulness has not changed (I do not think DNSSEC is "juice worth the squeeze"), but there are compliance situations that force the existence of DNSSEC...

It's just frustrating that the closest to spec-compliance state of the art DNS resolver is Unbound

It's also shocking there is basically no DNS RFC "-bis" document that rolls up all of the (must at least 100) RFCs into a somewhat coherent document, I wonder if the rubicon has been crossed where no one will ever agree on what a RFC -bis would even look like.

nlnetlabs@social.nln.. replied 29 Jun 2026 10:41 +0000
in reply to: https://benjojo.co.uk/u/benjojo/h/18rlVq6kyhhv7z4G5s

@benjojo While we love working in Rust, designing and building a #DNS resolver for the modern era is a massive undertaking.

Simply rewriting Unbound in Rust is a non-starter. We are taking gradual steps in reinventing our DNS stack by putting ldns in maintenance mode and investing in our domain library, and sunsetting OpenDNSSEC by launching Cascade.

Doing an authoritative server in Rust is definitely in the cards. Then, we can imagine putting all puzzle pieces together for a new resolver.

jtk@infosec.exchange replied 30 Jun 2026 16:48 +0000
in reply to: https://benjojo.co.uk/u/benjojo/h/18rlVq6kyhhv7z4G5s

@benjojo It may be practically impossible to create a perfectly "compliant" resolver on specs alone.

There have been numerous ambiguities on how to handle certain conditions for which there was no formal guidance. Sometimes this gets fixed, sometimes it's just wisdom passed down informally.

Some have resorted to looking at how BIND (or other implementation) have handled certain cases to decide how to do something. Even with DNSSEC, some behavior has been open to interpretation.

These inconsistencies are mostly unimportant to the average user, but there are probably lots more drafts and RFCs that could be written clarifying all these things.

benjojo replied 01 Jul 2026 14:36 +0000
in reply to: https://infosec.exchange/users/jtk/statuses/116840076950958220

@jtk I've come to learn that DNSSEC is one of the worst offenders of things being extremely hard to understand, and I wouldn't care if it wasn't for the fact that in some situations it's hard mandated for compliance in some schemes, with serious penalties if your DNSSEC code does something wrong...

notecharlie@social.b.. replied 29 Jun 2026 14:07 +0000
in reply to: https://benjojo.co.uk/u/benjojo/h/18rlVq6kyhhv7z4G5s

@benjojo DNS at its core is what, maybe 4 standards? That admittedly, not all of the DNS servers even implement (looking at you, djb). Everything else besides dnssec is just best-practice or nice-to-haves (like nsupdate).

I know that cloudflare and likely google DNS are using internal implementations: I've found bugs in cloudflare's implementation before.