At Mon, 18 Aug 2014 10:59:22 -0700, Paul Hoffman <[email protected]> wrote:
> Greetings. I created a new proposal on a simple way to do DNS over > TLS between stubs and resolvers. Comments are appreciated. I have one few small comments. - Section 2.1 A security-oblivious stub resolver MAY use policy to allow unauthenticated encryption (which can possibly be intercepted by an on-path adversary) or authenticated encryption (which might prevent all DNS resolution if the server does not have correct authentication credentials) when contacting a recursive resolver using this protocol. Is this "security-oblivious stub" the concept defined in RFC 4033? If so, I think it's helpful to refer to the RFC explicitly. And, even if so, I'm not sure how the "security-oblivious"ness matters in this context. Some more explanation might be needed. - Section 2.2 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 act as a TLS client for queries to its upstream recursive resolvers. 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. - General: perhaps related to the above points, I wonder what the stub resolver should do if it finds the recursive server(s) don't support the TLS extension. It's probably just another policy matter (it can simply give up or live with resolution without encryption, etc), but I think it's worth noting explicitly. -- JINMEI, Tatuya _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
