Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

[Ralf Weber <[e-mail]>]

Moin!

On 05 Jul 2014, at 18:11, Joe Abley <[e-mail]> wrote:
> TL;DR: there are way more cons than pros to this proposal. The pros listed are weak; the cons listed are serious. I don't see a net advantage to the DNS (or to perceived performance of the DNS for any client) here. This proposal, if implemented, would represent non-trivial additional complexity with minimal or no benefit. I am not in favour of it, if that's not obvious.
> 
> As noted previously, I am not against documenting and discussing the merits of slaving the root zone on resolvers (in some fashion). My preference would be for a draft called something like "draft-ietf-dnsop-slaving-root-on-resolvers-harmful", which could borrow much of your section 5.1 and 5.2 to make its argument.
Oh like draft-ietf-dnsop-reflectors-are-evil that became RFC5358, but still hasn't stopped Google and others offering open resolving service to the internet. Granted there are a lot of open DNS proxies out there that should be taken down, but I assume there are some companies offering resolving services that are valuable to Internet users.

> I remain very much *not* in favour of making changes to the DNS specification that don't have a clear benefit to balance their costs.
I think there is a difference between the precise specification and what you can do with your DNS software. While it may not be within the spec you can setup an auth server today that slaves the root zone and use a stub on your resolver to point to that root zone. That's how I run my setup at home because I don't want to my queries to be part of the DITL collection and I know that others do that because they have very bad connectivity to the root servers and in general. 

I think if we think of the resolver having another auth root server at localhost the logic is easier to understand makes much more sense as DNSSEC protections would kick in even if someone managed to inject a bad zone. 

The draft doesn't require every resolver to slave the zone, but merly is an information that this is a possible way to do it and I assume that large resolver operators would benefit from it and the CPEs you mention that even haven't implemented EDNS0 wouldn't matter anyway.

It in the end of course comes down to do we want to document what is out there  anyway or do we want to hide our heads in the sand. Especially for an operational group I would prefer the former.

So long
-Ralf