[dns-operations] DNS over TLS: slowly happening

[Hellqvist, Björn]

> > Good to see someone from the resolver community post on this list!
> > Usually most of us are from the (cc)TLD or hosting community.

I have been here for years, only that I am quite quiet and only absorb the information from you, all the DNS gurus. :)
I attend the DNSORC events, and even try to be there physically whenever it is held in Europe. 

> > On Tue, Jun 26, 2018 at 11:17:46AM +0000, Hellqvist, Björn wrote:
> >> Have anyone done any real research with real-world numbers on the server
> side when using DNS-over-TLS?
> >
> > Somewhat:
> > https://ripe76.ripe.net/presentations/92-RIPE76_DNS_Privacy_measuremen
> > ts.pdf and
> > https://ripe76.ripe.net/presentations/95-jonglez-dns-tcp-ripe76.pdf
> >
> > These numbers are not entirely 'real world' though.
> 
> We are waiting to hear about some more funding to extend our study as, yes,
> it is basic. Also, with this kind of testing there are so many more dimensions to
> consider to model the ‘real world’ than when profiling DNS-over-UDP….

Have someone written down a list of any test cases that can be used?

> >
> >> And what happens during an attack and each client opens up a large
> >> number of new unique connections?  Or if a vendor introduce a bug
> >> that does not reuse the TCP connection and open up a new one each
> >> time and not closing the unused one?
> >
> > I personally recommend having a proxy do the dnsdist termination, this
> > means that at worst the proxy fails. This has also been measured in
> > the presentations above.
> 
> I’d also recommend this approach for a large scale deployment.

What does that matter if there is a DNS Proxy failing or a DNS resolver? 
It will be the same result, DNS will be down for the customer.

And wouldn’t a proxy have more or less the same limitation as a server?
Especially if we look at server based proxies, like dnsdist. 

> >
> >> Although we should aim to privacy, we should not jump in to a
> >> solution where operators actively will disable it due to resource and cost
> limits.
> >
> > I'm afraid that if service providers will not make a move, the
> > browsers of their subscribers will, and start prefering the DNS of
> > their vendor or preferred partner, like CloudFlare.
> >
> > You mention disabling things, but DNS over HTTPS is specifically
> > designed to be hard to disable.
> >
> > So the service provider community may not have a lot of choice, unless
> > they are fine with third parties taking over their customers DNS (this
> > is a common choice in Africa for example).
> 
> I completely agree with Bert and John here. The move to browsers doing their
> own DNS directly using DoH (probably to preferred providers) is happening
> whether we like it or not. It is a hard argument to persuade users to switch
> back to an unencrypted transport to their ISP when browsers are ‘protecting
> their DNS’ (or however it is sold).

So if a browser do a DNS-over-HTTPS and utilize say google and the customer is logged in on a google account. 
Then it could probably fall under GDPR/EPR, since it can be tracked to a real person, right?
And GDPR/EPR can be quite a mess. 

Also I do not say we should not do privacy on DNS. DNS-over-TLS might not even be a real problem and we might even consider implementing it, just for fun.
We are no strangers when trying out new features, we tried to implement DNS Cookies last autumn. But the real world is not really ready for it. 
There are a lot of old Authoritative DNS installations out there. The oldest we got in contact with had a 17 years old MS DNS installation. (They have now changed to BIND after we pointed this out)

But it would have been good to see some numbers on its limitation. And it might be that we do not find the problems until it is implemented and there is substantial volumes. 

Thanks Sara, both presentations gave some inputs. 

BR,
Bjorn Hellqvist
Senior System Specialist (Internet & DNS)
Telia Company
Solna, Sweden