[dns-operations] DNS over TLS: slowly happening

[Hellqvist, Björn]

> [snip]
> >>
> >> 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.
> 
> Agreed that it is a bit of a policy mess for any organization that has data about
> IP addresses in some way that is possible to associate “natural persons” with
> data being collected. ISPs are in the same category - there is a relationship
> (typically due to payments required) between a household or person and the
> data that is visible on a particular circuit, or service such as DNS resolution.
> This inescapable pre-existing knowledge within the organization makes DNS an
> automatic GDPR landmine.

But as an ISP it is more clear that we have this data and are already aware of it and have already taken measures around it. 
(Or hopefully all organizations have)

> Not all third-party DNS recursive resolver providers have extra data with which
> they can correlate natural persons to DNS lookups. Almost all say they do not
> create such correlations even if they are able to, but ability and intent are often
> difficult to separate over time and commercial pressures. (I am admittedly
> biased on this point, speaking from the perspective of a non-profit.)
>
> Given the two points of GDPR-entangling ISP correlation ability, and the drive of
> third-party DNS providers to NOT have that correlation ability, it may be the
> case that some ISPs may find that offloading DNS resolution to external
> organizations who are naturally less informed about clients may remove some
> GDPR headache from their long list of compliance systems that they must
> manage. With encryption of the DNS, this outsourcing becomes even more
> useful as it is then possible for the ISP to claim it is not even possible to
> intercept the DNS lookups, further diffusing the points of pressure for any
> interest in that data from a policy compliance view. I have spoken to a few ISPs
> who have been quite interested in and have implemented this GDPR offload
> model, but of course this will vary significantly between organizations and their
> perceptions of the risks and payoff of outsourcing DNS.
>
> If the ISP outsources DNS, then one the last remaining privacy windows that the
> ISP has open is client traffic SNI, but hopefully that will change in the future. If
> and when SNI becomes invisible, then I see very few places where the transport
> provider has the opportunity to understand the content of traffic from end
> users except for IP address destination, which is becoming less useful as well
> with CDN delivery of data. I believe this is a good thing.

>From my understanding I don’t think it is so easy to just hand over everything to a third party and everything will magically be GDPR compliant.

If an ISP buys a Resolver function and needs logging of the activity, like for legal reasons, there is a possibility for the ISP to do the mapping. 
It is also then the ISP that still have the customer relation, and needs to have processes to make sure the third party obliged to the GDPR. 

And if an ISP is just giving out to third party DNS operators wo a contract, they should at least inform the customer regarding privacy leakage to the third party and what they can do with that data. 
For example to do analyzing and profiling for sexual preferences, political views, etc.      (Please note that I explicitly wrote 'can do', which does not imply on what actually are done or not)

I do not know if an ISP actively giving out third party DNS services, if they are still under the GDPR scrutiny. Probably yes since the resolver IP's will be given out by DHCP, so the ISP will be the enabler in some way. 

We probably need to wait for an injunction before we really know. GDPR is still leaving a lot for interpretation. 

If using the ISP resolver, then the customer have one trusted speaking partner and using the ISP resolver is still a way to anonymize to the rest of the world.

And as you know the privacy created by enabling DNS-over-TLS is just for eavesdropping the traffic stream. The DNS Resolver Provider will still be able to see everything. 
 
> > 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.
> 
> I’m sure you’ve seen the DNS Camel
> (https://datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-
> the-dns-camel-01)

Actually I have not. Unfortunately I have not been able to follow much the last year. 

Is there a video available as well? 

> DNS-over-TLS and DoH seems like a rare case where this balance might work
> out, though they are both very heavy straws from the operator viewpoint once
> at scale. Again, for organizations whose only job is to do recursive or
> authoritative DNS this is an expected burden, but ISPs or enterprise operators
> may find the increased complexity of running DNS something they are less
> inclined to want to do if they intend to stay current with best practices.

I hope not ISP's have problems following the best practices, since they should update the software regularly and new features will arrive. At least the larger ones. 

> > 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)
> 
> We have also found and in some cases communicated with operators of
> authoritative MS or BIND implementations were double-digit years old and
> which caused profoundly subtle and frustrating problems with resolution.
> Those (anecdotally) are becoming fewer in number, even in the last year there
> seems to be a much lower incidence of needing to do gymnastics to solve auth
> server problems, though there are of course still many new methods of broken-
> ness that continue to appear.

As a ISP on a national level, we do have a responsibility not to break anything that have a national importance. 
 
> I am encouraged by the progress made in encryption methods for stub
> resolvers since that is almost all “new” code to be written. This means that at
> least for a little while both the servers and clients will be in sync with features
> and functionality because of their newness and small community of authors and
> cross-testing that will be performed.
> Give it a year or two, a dozen implementations, and some vendor embracing-
> and-extending and then we’ll find divergence and we’re back on the camel
> ride. Enjoy the golden time now, I suppose, but this is the way of standards.

Don’t be so negative. The future is yet to be written. 

By doing analyzes and come up with real numbers, we might be able to steer this in a direction that is good.

It would be good if there was already written down test functions so one could test for one self. 
Or even better to have already made tools, then there might be more organizations running resolvers to run the tests. 

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