On Aug 19, 2014, at 11:12 AM, 神明達哉 <[email protected]> wrote:
> 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. This was just a leftover from a pre-draft when I was trying to deal with passing validation responses from resolver as well. It should simply have read "A stub resolver MAY..." > - 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. 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. > - 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. 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. --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
