At Tue, 19 Aug 2014 11:32:54 -0700, Paul Hoffman <[email protected]> wrote:
> > 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..." Ah, okay. > > - 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 [...] > 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. This works for me (I realize there's a followup discussion regarding the possibility of downgrade attacks, on which I don't have a strong opinion yet). > > - 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. Works for me, too. -- JINMEI, Tatuya _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
