simon at thekelleys.org.uk
Tue Sep 8 21:41:10 BST 2015
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.
On 07/09/15 20:04, Matt Taggart wrote:
> Have you seen this draft for adding TLS to DNS?
> 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.
More information about the Dnsmasq-discuss