.@ Tony Finch – blog

At Cambridge since approximately I don’t know about 25 years ago or more, we have encouraged sysadmins to set up stealth secondary DNS servers. This has a couple of advantages:

It has a disadvantage too:

DNSSEC and stealth servers

Disappointingly, DNSSEC does not help with this stealth secondary setup, and in some ways hurts:

Work in progress

We have been living with this unsatisfactory situation for nearly 10 years, but things are at last starting to look promising. Here are a few technologies in the works that might address these problems.

DNS-over-TLS for zone transfers

To provide on-the-wire security for zone transfers, we need a one-sided alternative to TSIG that authenticates the server while allowing the client to remain anonymous. In theory SIG(0) could do that, but it has never been widely implemented.

Instead, we have DNS-over-TLS which can do the job admirably. The server side can be implemented now with a simple configuration for a proxy like NGINX; the client side needs a little bit more work.

Built-in support for RFC 7706

Authenticating the server isn’t quite enough, since it doesn’t provide end-to-end validation of the contents of the zone. It looks like there is interest in adding native support for DNSSEC authenticated zone transfers to the open source DNS servers, so they can support RFC 7706 without the lash-ups and bogosity pitfalls.

I would like to see this support in a generalized form, so it can be used for any zones, not just the root.

Catalog zones

To simplify the setup of stealth secondaries, I provide a Cambridge catalog zone. This makes the setup much easier, almost comparable to a forwarding configuration. If only we could do this for trust anchors as well…

DLV delenda est

Before the root zone was signed, isc.org created a mechanism called “DNSSEC lookaside validation”, which allowed “islands of trust” to publish their trust anchors in a special dlv.isc.org zone, in a way that made it easy for third parties to use them.

Now that the root is signed and support for DNSSEC is widespread, DLV has been decommissioned. But if we tweak it a bit, maybe it will gain a new lease of life…?


DLV acted as a fallback, to be used when the normal chain of trust from the root was incomplete. I would like to be able to set up my own local DLV, to be used as a replacement for the normal chain of trust, not a fallback. The advantages would be:

DLV on the edge

That sounds nice for recursive DNS servers, but for DNSSEC to be really successful we need validation on end-user devices. And that undermines the robustifications I just listed.

But if your validating stub resolver supports localized DLV, and it has been configured by a group policy or similar configuration management system (like those corporate TLS trust anchors some enterprises have) then you have won those advantages back.


I want:

I mentioned this last feature to Evan Hunt at the IETF 101 London meeting. I feared he would think it is too horrible to contemplate, but in fact he thought the use case is quite reasonable. So I have written this down so I can give these ideas a wider airing.