from what I comprehend the current unbound syntax supports one root at a time, e.g. either ICANN roots or alt-roots such as OPENNIC, but not 2 roots in parallel. It seems currently not possible to have 2 root-hint files, 2 name . as auth-zone or 2 name . as forward-zone. To get alt-roots subdomains resolved alongside the ICANN setup is currently a bit cumbersome and a transfer of the alt-root to local is not feasible.
Not sure what the future of DNS holds but is seems that with blockchain and such there might be some traction on alt-root and thus I was wondering whether there is any plan to support alt-roots simultaneously, if such is technically viable and would make sense? Something along theses lines:
To quote Charles Babbage: "I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."
How do you distinguish “.” from “.”?
How do you distinguish “.TLD” in the root from “.TLD” in the alt-root?
Which root hints would you use?
Which KSK would you use?
Your question doesn't even make sense. How would unbound know to resolve
TLD1 via root, and TLD2 via alt-root?
TLD for respective zones are stored in the respective root zone files and thus are distinguishable.
How do you distinguish “.” from “.”?
As initially mentioned with a syntax e.g. name: . and alt-name: .
How do you distinguish “.TLD” in the root from “.TLD” in the alt-root?
From the root zone file provided by the respective root and as initially mentioned with a syntax e.g. name: . and alt-name: .
Which root hints would you use?
The ones provided by the respective root and as initially mentioned with a syntax e.g. root-hint and alt-root-hint.
Which KSK would you use?
Have not looked into DNSSEC ecosystem for blockchain domains or OPENNIC domains. Yet I would assume that they would leverage their own KSK for domains that ICANN does not handle.
Ideally there should not be any overlapping of subdomains between the ICANN root and the alt-root and I would not see why/how there should be. There is ICANN has its root/tld and then there is alt-root with its root/tld, unrelated to each other.
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.
With OPENNIC there is already another (aka alt) root zone in existence. Not sure about the upcoming blockchain domains, whether being more the traditional design or rather similar to onion or different altogether. And currently OPENNIC does resolve those blockchain domains, aside those IANA/ICANN, whilst the IANA/ICANN current implementation is limited to their model. With different root zones in existence unbound can currently handle only one.
I don't see that Unbound needs any modifications to consult a different root zone on a different set of servers, though.
With different root zones in existence unbound can currently handle only one.
Yes. This constraint is however inherent in the meaning of "root" and
not simply a restriction of inbound.
Depends what the definition of root is. Suppose that today’s perspective would be the root of ICANN/IANA but really it can be any root such as OPENNIC and thus the question for alt-root in unbound. Who knows maybe other roots spring up too.
But perhaps the consideration of alt-root in the traditional sense it already obsolete in case the blockchain domains gain traction. Just read that there is no root in the traditional sense but rather a decentralized domain registry in the blockchain itself. Apparently it is claimed that there would be no need for DNSSEC.
Will be interesting to see how that would should shape the development of resolvers.
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 agree with Joe, two roots are not workable without giving up away
security and performance of both.
Try to think of how RFC 8198 would be implemented for two roots at the
same time ...