DNS, the old standby of name resolution protocols, has been with us for a long time and will be for a long time to come. But like any “old standby” protocol, DNS has some imperfections. Like many early internet protocols, DNS was designed with an almost total lack of security.
Finding an IP address via DNS is like entering a crowded room and shouting, “Hey, does anyone know where this website is?” You might get an accurate answer to your question, but the process isn’t exactly private.
Technologies like Domain Name System Security Extensions (DNSSEC) protect part of the query process, reducing the chance of your DNS traffic being tampered with. If you make a DNS query using DNSSEC, you can be reasonably sure the response is coming from an authoritative name server, not a malicious actor. However, the requests and replies, the names of the websites you go to, or the API servers your phone calls out to are still vulnerable to being snooped on.
This is an increasingly scary thought when you consider just how many organizations—from your ISP to the government of an authoritarian country to advertisers—would love access to that data. And at the moment, they have it. But there’s a solution: an emerging technology called DNS over HTTPS (or DoH).
The Simplicity of DoH
DNS over HTTPS, when you get down to it, is very simple. Your DNS resolver makes a standard HTTPS get request to a DoH server, which responds with a DNS answer. As with all HTTPS traffic, the DNS query is encrypted, as is the response. This dramatically improves privacy.
An example of a DoH response (performed in a terminal) is shown here, to demonstrate how simple it is:
requester: [root@server]~# curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=AAAA'
response: {
"Status": 0,
"TC": false,
"RD": true,
"RA": true,
"AD": true,
"CD": false,
"Question": [{
"name": "example.com.",
"type": 28
}
],
"Answer": [{
"name": "example.com.",
"type": 28,
"TTL": 1005,
"data": "2606:2800:220:1:248:1893:25c8:1946"
}
]
}
DNS over HTTPS takes advantage of all the well-coded, well-tested HTTPS security technologies. Whatever security or certificate trust policy your organization enforces, you can now use the exact same policy to restrict what DNS servers your servers or client PCs can talk to, while protecting the privacy and integrity of the queries at the same time. This would also solve the problem of DHCP-provided DNS servers providing false answers, a common attack vector in embedded devices; that is, intercepting API calls by tricking DNS.
Consider, for example, using Wi-Fi at a cafe. DHCP hands out both the IP addresses and the DNS servers your device will use on the network. A compromised cafe Wi-Fi access point could be configured to hand out the address of a malicious DNS server. Web browsers using DoH can bypass the default system-assigned DNS server, and send their responses over an encrypted HTTPS stream to a known-good DNS server, avoiding compromise.
Deploying DoH
There are several possible ways to deploy DoH. One of the easiest is browser-based policies; either as a default setting, or as part of mobile device management (MDM) or administrative deployment suite. However, not all browsers support this. At the time of writing, Firefox is the only browser with built-in DoH support, though Chrome is expected to add this feature in the near future.
DoH support is somewhat contextual. Even where the browser supports DoH, other browser-based web applications may not honor this setting. Applications that don’t support DoH or don’t use the DoH setting coded into browsers will fall back to the insecure standard DNS protocol.
A better way, though still with caveats, would be system-wide deployment. The OS on a client’s PC, phone, or other devices can be configured to consult a DoH-enabled upstream server for all DNS queries, which protects (in most cases) against the application issue. However, most OSs don’t natively support DoH yet, and so the use of an intermediary DNS->DoH proxy, most probably running on the local system, must be considered. This raises a number of issues for organizations with strict application approval policies or nonstandard systems, which can be handily solved by the final, and most wide-spread, means of deployment—network-wide.
In a network-wide deployment of DoH, the organization’s internal DNS server is configured to connect to a DoH-enabled provider, ensuring integrity and privacy for DNS queries organization-wide. This can also be used across VPNs and IP tunnels to protect DNS queries of remote workers’ devices. An organization’s security target should be that working from home introduces no more vulnerabilities or security issues than working in the office.
DNS over HTTPS should be able to massively increase security, privacy, and integrity of DNS queries both on a local network and on the internet, something we desperately need, especially in this age of IoT and smart devices. Eventually, DNS over HTTPS will be standard on internal networks, too, maintaining a chain of trust from browser, to DNS server, to gateway, to web server; keeping the user of such a chain safe from attackers and privacy invasion—an increasingly common tactic by advertisers and ISPs who can sell browsing history and DNS data to the highest bidder.