support for parallel alt-roots?

Joe Abley jabley at
Thu Dec 13 05:27:04 CET 2018

On 12 Dec 2018, at 21:23, Dave Warren via Unbound-users <unbound-users at> wrote:

> To me it seems that even if there is an overlap, the problem is trivially resolved by the fact that the roots are defined in some order (in the configuration file). Start with the first root, if there's no TLD hit then move on down the list until you either get an answer or run out of alt-roots.
> Also consider, we can already define a zone with a fallback-enabled parameter to check a local zone and if it fails then resolve the record as normal, supporting alternate roots would not be dramatically different.
> Whether it's a good idea or not, I'm not sure. Personally I have no use for alternate roots outside of .onion (which is obviously a completely different beast).

Right, I think it's useful to think of ONION as a naming resolution switch that happens to be in a weird place, rather than a TLD. Another example is LOCAL -- if an application (or a name resolution library linked to an application) sees a name that ends in LOCAL, it knows not to use the DNS to look it up but rather use Bonjour instead. If you're a particularly pedantic type of person you can think of LOCALHOST as being another example.

The trouble with merging namespaces in the DNS is that the root of the namespace in the DNS has some assumptions wrapped around it, like an intact, signed NSEC chain. Really you can't merge or consult two root zones at run-time; what you're doing is constructing a new root zone for a new namespace that happens to have a non-null intersection with other namespaces.

I personally have no reason to make my life difficult by doing this, and I have no users I hate enough to inflict this kind of ticking timebomb on them, but there are no DNS style police here and if someone wants to make their own root zone, I say go for it. You only live once.

I don't see that Unbound needs any modifications to consult a different root zone on a different set of servers, though.


More information about the Unbound-users mailing list