On 13. 12. 18 5:27, Joe Abley via Unbound-users wrote:
> 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 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 ...

Petr Špaček  @  CZ.NIC

> 
> 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

Reply via email to