A few weeks ago a Tweet with a poll from Bert Hubert of PowerDNS crossed my timeline. PowerDNS is one of the mainstream DNS recursor/Authoritative Name Server applications. In the Tweet he stated that he’s ‘blown away’ by Mozilla wanting to give all Firefox DNS queries to CloudFlare as a default setting.
The Tweet stated that Mozilla is moving DNS to HTTP over DNS (DoH) with help from its partner CloudFlare.
I find the resemblance with Homer’s ‘Doh!’ striking, because in my opinion DoH doesn't actually solve a real problem. On the contrary, it creates a problem. In this blog I’ll dive into the potential risks of Mozilla moving DNS to HTTP over DNS.
What is DNS?
Imagine you’d want to visit the Fox website to find out more about Homer and the rest of the Simpson family. https://www.fox.com/the-simpsons/. As the internet is built around IP numbers rather than names, the website name needs to be translated to reach the right server.
‘Behind the scenes’ the following actions are happening:
- Browser asks your OS resolver where to find www.fox.com (its IP address):
- OS resolver looks in its local storage, does not find it and asks a configured resolver for the same thing:
- Configured resolver will look in its local storage, does not find it and asks the root TLD for the same thing:
- Root TLD responds where to find .com’s main resolver
- Configured resolver will ask .com’s main resolver where to find www.fox.com (AUTH DNS)
- .com’s TLD responds where to find fox.com’s resolver (AUTH DNS)
- Configured resolver will ask fox.com’s resolver where to find www.fox.com
- fox.com's TLD responds where to find www.fox.com (its IP address)
- Configured resolver stores this in its local storage and returns the IP to you browser
- Browser sets up a TCP session towards the returned IP on port 443 (https) and starts negotiation for a secure connection.
Basically DNS is nothing but a means of finding a website's IP.
DNS over HTTP: The shift to profiling and ‘personalised’ content
According to various sources the following issue is being tackled, primarily driven by issues found in the US and other countries, where no laws exists to prevent tampering and/or harvesting DNS requests to monetise traffic.
In these countries and regions your DNS request adds to the treasure chest of ISPs by either selling a profile of you based on your DNS requests, or by showing ‘personalised’ content on pages based on this request and a profile that’s been made of your earlier DNS request history.
How you could be profiled as a hacker
When you visit sites to find information about cyber security such as Infosecurity, Hackerspace and Blackhat for example, the combination of those website visits and information gathered, might result in you being flagged as a hacker. That information could then be sold to sites which deliver lock-picking kits, or other companies that have hackers as a target audience.
The problem is: requesting an IP is privacy sensitive
Back to visiting the fox.com website.
When you request the IP address of a website, that website's name is known by the OS, configured resolver(s), networks its traverses, Root TLD, more specific root TLD (.com) and domain TLD (fox.com).
All these institutions have the ability to track where your request for this website visit came from. This means they all have a choice to sell this information, or use it as ‘data-for-user-profiling’ as well as advertisement purposes.
They could also be in a position to alter the response and redirect you to another location. A great example for such a redirect is the corporate captive portal, which tells you that you’re not able to visit XYZ as it is against company policy.
I asked Infoblox, core partner of Infradata and a specialist in secure DNS, DHCP, and IPAM (DDI) solutions, what their thoughts are on the DNS over HTTP subject."“Infoblox is very interested in both DoT and DoH, because they address a last mile security problem that DNS has suffered from since the beginning. However, we're also concerned that the use of DoT and DoH can subvert on-premise security mechanisms such as Response Policy Zones.” – Infoblox"
Click to tweet
Infoblox has expressed concern about last mile security, while in fact the current DoH proposal seems to be to default to CloudFlare. Which is not part of the last mile (yet), handing them all the options to start profiling in a centralised way.
Apart from the data leakage and security detection implications, it seems this also centralises a fundamental part of the internet, making it more vulnerable for foreign agencies to intervene.
I can however relate to the urge for a more secure way of communicating between client and DNS server; hence DoT (DNS over TLS) could also be a great alternative to DoH. It all hinges on centralised vs decentralised, user choice and user awareness.
Who do you trust?
In a poll shared by Bert Hubert on Twitter, he asked who users trust more when it comes to providing a private & neutral DNS services. With 240+ votes, the results are clear. Most respondents trust their service provider more than CloudFlare.
So which parties are involved here when it comes to using such profiling abilities:
- Your browser vendor
- Your OS vendor
- Your company
- Your ISP
- Transit and Peering providers
- ISP which is hosting the website
- ICANN root TLD
- ICANN/VERISIGN More Specific Root TLD (.com)
To repeat Bert Hubert’s question: How much do you trust each of these parties with your request for information to reach fox.com?
Protection against tampering/injecting content
Parties tamper with your requests to insert content into your web pages. This mainly happens in the US, but in the EU there now is a law against such practices called the law of ‘net-neutrality’.
As DNS is used to find the location of any content, you can also use DNS to block the ‘reaching out to’ element of this content by name or by providing an alternative page.
An example would be the captive portals you find at at restaurants, hotels, train stations, etc. In order to use their free service, you have to agree to behave yourself when navigating to websites.
As the DoH protocol uses DNS to find the DoH resolving server this Captive portal or Pay-wall will still function as before. Blocking content by DNS name is prevented after the pay-wall or captive portal has already allowed you access.
Bear in mind that the DNS used to lookup the DoH server could still be tampered with and could be redirected to a similar server run by the parties which already are trying to divert traffic from you.
What’s in it for the user?
Well, your DNS traffic will be redirected somewhere. This can be redirected to your company's DNS resolver, your ISP’s resolver, open resolvers like Cloudflare/OpenDNS/Google or through DNS over HTTP towards CloudFlare.
Your threat prevention mechanisms may not function as well after this DoH protocol is turned on by default as some rely on this.
From a network engineer’s perspective, I wouldn’t rely on the default DoH settings. It will also send internal DNS requests to these foreign parties. Instead, I would recommend you either:
- Reconfigure your browser policies
- Redirect these known URLs to your own DoH server by using dnsdist for example, the OpenSource resolver from PowerDNS. In case you’re wondering, this does mean that having more or less privacy with this solution is a debatable topic, depending on the scale of your organisation.
- Block these URLs on your network edge
When will the Firefox adoption of DoH take place?
According to Mozilla, Firefox will lead the implementation and adoption of DoH. In fact, it is already available in their nightlys and will be mainstream in release nr 63, which will be automatically deployed around October 23rd.
As yet, no details have been shared about whether this function will be turned on by default, but the tone has been set to do so, by selecting a DoH handler near you which Mozilla believes is good for you. The point is: you have to decide for yourself who you trust and configure your Mozilla Firefox settings according to your business (and ethical) policies, as well as in compliance with your country's privacy regulations.
Hilmar Burghgraaff - October 15 2018
Networking Solution Architect