Besides the common routing protocols, the Domain Name System (DNS) is one of the longest serving infrastructure protocols on the Internet. As the number of participants on the jointly developed Internet (initially ARPANET and later NSFNET) began to grow, the manual overhead involved in maintaining the hostname file (/etc/hosts) exploded. The first draft defined in RFC882 and RFC883 turns 40 next year.

Fortunately, traditional attacks such as DNS spoofing and cache poisoning are practically impossible today. DNS has seen several enhancements since its introduction, which retrospectively reflects a good design that is obviously extensible in many directions. The problem now is the unmanageable number of top-level domains, country domains in different languages that use different character sets, DNS over TCP for particularly large queries and responses, and many other major and minor extensions. Most resolvers now secure their queries to the authoritative name servers with DNS security extensions (DNSSEC) and other technologies to avoid receiving undesirable spoofed responses.

DNS also forms the basis for protecting many other application protocols today: The main examples are HTTP for issuing certificates for web access and SMTP for securing email communication with DMARC.

Privacy and Manipulation

Whereas DNS itself has become significantly more secure, the unencrypted route between clients and resolvers is left as an attack vector for hackers and snoopers. The data is routed by the User Datagram Protocol (UDP) without protection. One issue that has not yet been fully resolved is the privacy of DNS requests. Clients also need to be able to trust the resolvers to deliver correct responses – think protection against cache poisoning and censorship – and to keep client data confidential, or preferably not store the data at all.

DNS requests map users' web activity in a fairly accurate way and are therefore an open invitation to abuse: whether in the form of DNS server operators storing queries and reselling them for advertising purposes, or providers messing around with the unencrypted data flowing through their networks. The most important argument in this discussion is therefore trust, which raises the question of trusting or mistrusting your own Internet provider; associations that provide protection against censorship [1] or offer data protection [2]; or large DNS providers such as Cloudflare [3], Google [4], or Quad9 [5]. Quad9, by the way, deliberately filters DNS responses to protect users against malicious domains that propagate malware or phishing.

Even if the provider of the DNS resolver were trustworthy, communication with the provider would still be unencrypted, which is why different protocols protect the connection between client and server. As early as 2016, DNS over TLS (DoT) was defined as a protocol that secures name resolution requests with TLS over TCP. Therefore, the requested domain is only visible to the DNS server to which the request is addressed. To compensate for potential speed disadvantages, the TCP connection is kept alive after the request and reused for the next request. Communication is routed through port 853 and is encrypted on the network, but recognizable as DNS traffic through the port.

DNS over HTTPS

In addition to DoT, another encryption method, DNS over HTTPS (DoH), was launched. Released in 2018, the protocol is designed to protect user privacy extensively, going even further than DoT. The DNS request is sent by HTTPS to a web server that operates a matching API. Most implementations let you choose between different response types. The most commonly used examples are probably application/dns-json and application/dns-message . The curl utility lets you see at the command line how a query appears:

curl -s -H ,accept: application/dns-json' "https://cloudflare-dns.com/dns-query?name=linux-magazine.com&type=A" | jq .

The jq here makes for nicer output formatting, the -s suppresses the status output for curl, and -H specifies the Accept header and chooses JSON output in the request. I used the Cloudflare DNS server for this example. Of course, you can choose an alternative server depending on your preferences. When using application/dns-message , the server expects a Base64-encoded message that is equivalent to a classic (binary) DNS query. The response is again not so pretty for viewing on the console; it contains binary data to match the request.

Secret DNS Requests

Because DoHs are ordinary HTTPS requests, they are also indistinguishable on the outside. If a web server provides both web page content and DoH, name resolution queries can no longer be distinguished even on packet filters or firewalls unless you also examine the TLS connections there.

Therefore, external DNS sources can be used behind restrictive firewalls, possibly bypassing active DNS filters. Firefox already made DoH the default for users in the US on Cloudflare servers in 2020. You can enable DoH in the browser settings if you like and can also enter an alternative server.

When you enable DoH in your browser, the system's settings are preserved as a fallback because DoH does not work if, for example, you are in a hotel behind a captive portal. Name resolution by DNS will normally work, but HTTP(S) connections are blocked until you log in. By the way, you might experience problems even with DoT if the redirect to the captive portal relies on DNS hijacking.

DoH also can be used to attack corporate networks. JavaScript and dynamic queries (Ajax) allow queries to an internal DoH server for gathering additional information about the corporate network. The appropriate CORS headers in the DNS server responses could prevent this attack. Today, many companies use client DNS queries in their monitoring to check for malware infestation, for example. Such mechanisms can no longer be easily used with DoH if the malware of the future also implements DoH against standard servers from Google or Cloudflare.