There has been a lot of fuzz around DNS over HTTPs shortnamed (DOH) lately. For those that haven’t read about what is going on or what DoH is, you can read more on Mozilla’s blogpost here about the subject –> https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/ and also Google’s approach here –> https://security.googleblog.com/2019/06/google-public-dns-over-https-doh.html
DOH as a protocol has already been rolled out to Firefox and Chrome (more as experimental features…)
Firefox https://support.mozilla.org/en-US/kb/firefox-dns-over-https
Is it important to remember that by default, Firefox will send all DNS requests to Cloudflare which they’ve partnered with and not your local ISP which you might have configured for your home devices.
Chrome: chrome://flags/#dns-over-http this flag should be availble for Chrome build 67.
And also more and more DoH providers are coming as well. Because to use DoH you need a supported vendor which supports DoH. –> https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers
So what is the issue with regular DNS?
Now the main issue with regular DNS is that queries and responses are sent over UDP or TCP without encryption. This is vulnerable to eavesdropping and spoofing (including DNS-based Internet filtering). Responses from recursive resolvers to clients are the most vulnerable to undesired or malicious changes, while communications between recursive resolvers and authoritative name servers often incorporate additional protection. Therefore many have implemented DNS based protection as well to provide secure lookup such as Cisco Umbrella and have DNS monitoring in place in their enterprise.
So does DoH help?
DoH is essentially sending DNS traffic across over HTTPS (Therefore encrypted), Think of it as a JSON API to make DNS lookups. A simple HTTP GET request and a predictable JSON response format, all via a provider such as Google. DOH is a direct substitution for the DNS over UDP step that allows a client-side stub resolver to pass queries to a recursive resolver and receive responses, where the IP and UDP wrappers are replaced with HTTPS wrappers. There is value in using a TCP channel that does not have the issues with UDP fragmentation that we see in the DNS today.
Example of a HTTP Header using DOH
:method = POST :scheme = https :authority = dnsserver.suchascloudflare.net :path = /dns-query accept = application/dns-message content-type = application/dns-message content-length = 33 <33 bytes represented by the following hex encoding> abcd 0100 0001 0000 0000 0000 0377 7777 0765 7861 6d70 6c65 0363 6f6d 0000 0100 01
DoH has some pratical benefits.
- Widely available and well-supported HTTPS APIs simplify implementation for both Public DNS services and potential clients.
- An HTTPS service provides web apps with access to all DNS record types, avoiding the limitations of existing browser and OS DNS APIs, which generally support only host-to-address lookups.
- Clients that implement QUIC UDP-based HTTPS support can avoid problems like head-of-line blocking that can occur when using TCP transport.
- With the further investment into HTTP/3 we are also essentially moving HTTP traffic over UDP for increased performance.
Now the bigguest issues (which can read more about here –> https://www.zdnet.com/article/dns-over-https-causes-more-problems-than-it-solves-experts-say/) is essentially how can we reuse DoH on the existing DNS investments? including existing DNS servers and security and monitoring software?
What about Performance?
Based upon some tests that have been performed by others, there seems to be little performance hit on DNS lookup’s. Even during the initial stages, where ISP’s and other telco providers support DoH and much of the DNS traffic needs to go to supported DoH providers such as Cloudflare or Google DNS
https://samknows.com/blog/dns-over-https-performance if you want to try it out you can also setup a cloudflare agent which can be run on most OS which allows you do spin up a DNS proxy which sends request to 1.1.1.1 using DoH, which you can find here –> https://developers.cloudflare.com/1.1.1.1/dns-over-https/cloudflared-proxy/
Great how to use this in my enterprise?
The biggest issue now is most enterprise security products do not support DoH, many solutions which are built upon DNS filtering or have DNS monitoring in place will not be able to see this type of traffic. This becomes an issue in many cases, infected or compromised endpoints will do DNS lookups to multiple fake DNS domains to connect co C&C or to download more payload. If they now are using DoH instead of regular DNS lookup any firewall where we do not have inspection (or that we have TLS 1.3 and we don’t even have the option to do inspection) this makes it difficult to inspect or gain control over)
As seen here there is now even malware that already uses the new protocol to hide (https://www.zdnet.com/article/first-ever-malware-strain-spotted-abusing-new-doh-dns-over-https-protocol/)
So much of the current limitation now from an enterprise standpoint is that the protocol is fairly new and is still in the starting phases. Since Mozilla and Google has already implemented this in their browser will work fine for many consumers to increase privacy but enterprises will not be ready anytime soon to implement this product without making some big adjustments to their network infrastructure and securty ecosystem. But fortunelty the browsers have a backup in place. If the switch fails or the DoH resolver doesn’t answer in a timely manner, Chrome and Firefox will automatically switch back to using the classic DNS resolver service built in the OS.
Again we see that the browser vendors such as Firefox and Chrome (and also Cloudflare) and making rapid changes (such as http/3) and implementing these new features into their products Much of the work that get’s done is to increase browsing and increase security from an enduser perspective. Guess its time for enterprise products to try and keep up with the pace?