[Dnsmasq-discuss] DNS-over-TLS

Simon Kelley simon at thekelleys.org.uk
Wed Sep 9 23:05:14 BST 2015

Hash: SHA256

On 08/09/15 23:58, Matt Taggart wrote:
> Hi Simon,
> Thanks for the comments. Here is a little more info I found.
> Simon Kelley writes:
>> It actually not that easy to do. DNS-over-TLS happens, by
>> necessity, over TCP. Your interesting client support scenario
>> would require that dnsmasq receive queries over UDP and forward
>> then over TCP-with-TLS. Dnsmasq is optimised to forward
>> DNS-over-UDP queries very efficiently. It does a passable job
>> forwarding DNS-over-TCP. The architecture pretty much precludes
>> receiving over UDP and then forwarding over TCP, which is a
>> problem, as that's exactly what's needed for the TLS case.
> Good point.

Actually, maybe not, see below.
>> Lonnie's example using DNSCrypt is probably the most sensible way
>> to implement this, as least to start with.
> I think DNSCrypt may be different than what the IETF WG is working
> on (aka 'dprive'?)
> https://github.com/jedisct1/dnscrypt-proxy/blob/master/DNSCRYPT-V2-PRO
> but I don't yet understand the differences.

The differences are not relevant to my point, which is that dprive
could be implemented the same way, as a proxy running on the same box
to which dnsmasq forwards queries.
> Also there there is T-DNS
> https://ant.isi.edu/tdns/index.html
> (maybe an implementation of what the WG is working on?) This blog
> post has some interesting links
> http://www.gabriel.urdhr.fr/2015/02/14/recursive-dns-over-tls-over-tcp
- -443/
>> Second, "is the proposed mechanism worth implementing".
>> Frankly, it sucks. The problem is that it specifies the same
>> simple framing for DNS queries and answers over TCP that's used
>> in RFC1035. The requestor sends the query, preceded by its
>> length, then listens for the answer, again preceded by its
>> length. The effect is that you need one TCP connection for DNS
>> query in-flight. But now you need a TLS negotiation for each one
>> too. Imagine you open a typical busy web page, it has 50
>> different DNS resolutions to do, and they all get fired off at 
>> once. The DNS resolver now needs 50 TLS connections to your ISPs
>> DNS server, or it has to start serialising the DNS resolution.
>> Once you have you 50 answers, your DNS resolver is mandated to
>> keep the connections around, so that it doesn't need to open
>> them again when you go to the next page. So your ISP's DNS
>> server, instead of doing stateless UDP, has to hold 50 TLS
>> connections for every customer. Really? The hardware suppliers
>> will be pleased. Much, much better to define a method to 
>> multiplex multiple questions and answers over _one_ TLS stream.
> I think the WG has thought of some of these things, some of it is 
> addressed in these slides
> https://www.ietf.org/proceedings/91/slides/slides-91-dprive-5.pdf
Yeah, I posted on the mailing list, and was gently corrected :)

Given that DNS-over-TLS mandates pipelining, then I'm fairly sure it
would be possible to implement it in dnsmasq. I see that as a
medium-term goal, when it's standardised, and there exist
implementations that dnsmasq could talk to.



Version: GnuPG v2.0.22 (GNU/Linux)


More information about the Dnsmasq-discuss mailing list