[Dnsmasq-discuss] DNS-over-TLS

[Matt Taggart]

Hi,

Have you seen this draft for adding TLS to DNS?

https://tools.ietf.org/html/draft-ietf-dprive-start-tls-for-dns-01

What would it take to implement in dnsmasq?
Both as a server and as a client.

I am thinking the client support would initially be more interesting,
as upstream DNS servers begin to implement, then at least the requests
dnsmasq forwards would be encrypted. That would solve most of the
problem for the home router situation, local queries to dnsmasq would
be unencrypted(but on the private network) but as they are forwarded
upstream(over a public network) they would be encrypted. Also it will
take some time for all the other various clients that talk to dnsmasq
to add support. (but knowing dnsmasq supports it will encourage others
to implement)

I think adding this to dnsmasq would be the single largest thing that
could be done for increasing adoption and possibly for increasing
metadata privacy on the internet.

I can help coordinate testing, test servers, documentation, etc. if
such an effort is started.

Thanks,

[Lonnie Abelbeck]

Post by Matt Taggart
Hi,
Have you seen this draft for adding TLS to DNS?
https://tools.ietf.org/html/draft-ietf-dprive-start-tls-for-dns-01
What would it take to implement in dnsmasq?
Both as a server and as a client.

Take a look at DNSCrypt:
https://dnscrypt.org

We use dnscrypt-proxy as a DNS forwarder in front of dnsmasq (on the same box) and it works brilliantly.

Lonnie

[Simon Kelley]

I have a few, fairly orthogonal, reponses to this.

First to, "What would it take to implement in dnsmasq?"

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. Lonnie's
example using DNSCrypt is probably the most sensible way to implement
this, as least to start with.

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.

Third "should it go in dnsmasq".

Probably, eventually. We're pretty stretched implementing and
maintaining a whole slew of well-established protocols. There's not much
slack for experimental stuff in the stable releases.

Sorry, that's not what you want to hear.

I really should post my critique to the WG mailing list.


Cheers,

Simon.

Post by Matt Taggart
Hi,
Have you seen this draft for adding TLS to DNS?
https://tools.ietf.org/html/draft-ietf-dprive-start-tls-for-dns-01
What would it take to implement in dnsmasq?
Both as a server and as a client.
I am thinking the client support would initially be more interesting,
as upstream DNS servers begin to implement, then at least the requests
dnsmasq forwards would be encrypted. That would solve most of the
problem for the home router situation, local queries to dnsmasq would
be unencrypted(but on the private network) but as they are forwarded
upstream(over a public network) they would be encrypted. Also it will
take some time for all the other various clients that talk to dnsmasq
to add support. (but knowing dnsmasq supports it will encourage others
to implement)
I think adding this to dnsmasq would be the single largest thing that
could be done for increasing adoption and possibly for increasing
metadata privacy on the internet.
I can help coordinate testing, test servers, documentation, etc. if
such an effort is started.
Thanks,

[Matt Taggart]

Hi Simon,

Thanks for the comments. Here is a little more info I found.

Post by Simon Kelley
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.

Post by Simon Kelley
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-PROTOCOL.
txt

but I don't yet understand the differences.

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/

Post by Simon Kelley
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

[Simon Kelley]

Post by Matt Taggart
Hi Simon,
Thanks for the comments. Here is a little more info I found.

Post by Simon Kelley
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.

Post by Matt Taggart

Post by Simon Kelley
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

TOCOL.
txt

Post by Matt Taggart
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.

Post by Matt Taggart
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/

Post by Matt Taggart

Post by Simon Kelley
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.


Cheers,

Simon.