On 12 Dec 2018, at 21:23, Dave Warren via Unbound-users <[email protected]> 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. Joe
