Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

[Brian Dickson <[e-mail]>]

On Tue, Nov 26, 2019 at 10:13 AM Stephane Bortzmeyer <[e-mail]>
wrote:

> On Tue, Nov 26, 2019 at 09:51:14AM -0800,
>  Brian Dickson <[e-mail]> wrote
>  a message of 98 lines which said:
>
> > However, if the only place the client is able to establish an
> > encrypted path to is a forwarder, this leave open the possibility
> > that the forwarder->(forwarder->[...])->resolver might involve one
> > or more unencrypted connections.
>
> I'm not sure I understand the problem. This case is just an instance
> of a more general problem "the machine you talk with may betray you
> and no amount of cryptography will help here". The resolver can send a
> copy of all your requests to the NSA (or its chinese equivalent), or
> it could use a forwarder over an unencrypted connection. What's the
> difference?
>
>
The difference is whether the problem is fundamentally unsolvable vs a
solvable problem.

Clearly, a resolver which betrays your trust deliberately can't be fixed
with any technology, it's a layer-8 or layer-9 problem.

However, a forwarder chain may not be intentionally insecure, and may only
be the result of naive designs or lack of vendor support.

The resolver at the end of the forwarder chain may actually be trustworthy,
so having a way of talking directly to it, solves the issue.

It also does so in a way that does not adversely affect the DNS ecosystem,
and in fact doesn't adversely affect the resolver itself.

A forwarder (or chain of forwarders, or tree of forwarders rooted at the
resolver) sends every query to the resolver. Connecting directly to the
resolver does not change that load, it merely bypasses middle boxes that
are value-subtract devices.

If anything, DNS resolution should improve, since it would (in theory, at
least) reduce latency, and possibly reduce loss caused by (DNS) application
queueing compared to strict network-level (hardware) queue use.

Brian