On Tue, 19 Aug 2014, Paul Hoffman wrote:
I wonder this 'MUST' may be too strong (or I don't fully understand
the sense of this MUST). Since the upstream recursive resolver may or
may not support the TLS extension, the DNS forwarder may end up giving
up the resolution altogether. But depending on the stub clients'
policy it may be still better to provide encryption between the stub
and the forwarder.
Good catch. Proposed replacement to handle the case where the recursive
resolver doesn't do TLS:
A stub resolver cannot tell whether it is sending queries to a
recursive resolver or to a DNS forwarder. Therefore, a DNS forwarder
that acts as a TLS server for DNS requests MUST also attempt to act as a TLS
client for queries to its upstream recursive resolvers, but MAY
use the normal DNS protocol on port 53 if an upstream recursive
resolver does set up a TLS session.
A resolver at a coffee shop is mostly concerned about protecting the DNS
in the public wifi, and might not worry at all about its DSL uplink,
especially when it has no real reason to trust its own uplink. So I
would just make it very generic:
a DNS forwarder that acts as a TLS server for DNS requests SHOULD
attempt to use TLS with its upstream resolver(s) to maximize the
anonymity of its stub clients.
Sure, let's be explicit. Proposed addition to the policy section:
If a recursive resolver does not respond on port 443 or set up a TLS session,
the stub resolver MAY use the normal DNS protocol on port 53.
MAY sounds a little odd here. If there is no preconfiguration for
authenticating this resolver, I don't think we should advise
stubs to refuse to do DNS completely, which is what the MAY is
suggesting as a valid option. (this is breaking the "opportunistic
security design pattern recommendation advise" :)
How about:
If a recursive resolver for which an authentication method is
available does not respond on port 443 or fails to set up a TLS
session, the stub resolver SHOULD NOT use that resolver over
unencrypted DNS using port 53. If no authentication method is
available for the recusive resolver, the stub resolver SHOULD
fallback to using cleartext DNS on port 53.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
