On Mar 5, 2014, at 11:07 AM, Francis Dupont <francis.dup...@fdupont.fr> wrote:
>> From discussions with Stephane Bortzmeyer and Mark Andrews...
>
> First I come back to the fact there are two different problems
> (aka divide and conquer):
> * stubs <-> resolver
> * resolver <-> auth servers
>
> I consider the first one to be already solved, cf. the Microsoft
> deployed solution which puts clients, local networks, the resolver
> (also the Microsoft Domain Server :-), in the same area and uses
> IPsec to protect it. You can do other ways but IMHO we can assume
> you don't need confidentiality with far or untrusted resolvers.
> Or with other words you don't need confidentiality with 8.8.8.8
>
I strongly disagree, my hotel list 8.8.8.8 as one of the resolvers available on
the
network, the answers from the 8.8.8.8 there are nothing like the answers I get
from 8.8.8.8 on the IETF network.
I NEED confidence that I'm talking to the real 8.8.8.8 if the only way to get
that is
encryption then I support it.
I'm not sure if Microsoft solution works when one attaches to new networks like
the IETF network.
The stub <--> recursive [validating] resolver
is the one more important to protect as the that is where it is easier to lie.
On the other one
recursive resolver <---> auth servers
I would prefer that before we start talking about encryption is we agree on
label stripping by recursive resolvers as that minimizes the leak of
information to
root/tld servers.
Olafur
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
