Solving the security problems of encrypted DNS
Double-Edged Sword
Dynamic Name Service (DNS) is a fundamental Internet service. As soon as you enter a computer name (e.g., www.mozilla.org ), DNS finds the corresponding IP address, 63.245.208.195 in this case. Without DNS you would have to know IP addresses by heart and enter them directly in your web browser's address bar.
The DNS data packets pass through the network without encryption or signatures. Only a 16-bit random number, intended to ensure the assignment of the request and response, provides rudimentary protection. The requesting client accepts the first incoming response with the correct random number and stores it temporarily in its cache. An attacker need only respond faster than the official DNS server to redirect the request. Inserting fake DNS entries in the cache is known as DNS cache poisoning.
Because all DNS traffic is unencrypted, it can be monitored and evaluated – by the provider or by your employer, among others. If an admin is looking to block undesirable access to servers that distribute malware in this way, unencrypted DNS can be advantageous.
About DNS Security
DNSSEC [1] is an established, but still not sufficiently widespread, standard for generating signed and therefore verifiable DNS responses. Providers and organizations that use at least this standard to thwart attacks, such as DNS spoofing and DNS cache poisoning, would be very desirable. At the moment, however, an overriding concern seems to be that using it makes DNS even more prone to error. Many large enterprises therefore still currently do without DNSSEC.
DNSSEC does not encrypt the content data (confidentiality) and only signs the data (integrity). Essentially, two keys are required per domain: one to sign the domain data (marked with code 256; typically 1024 bits) and a second to sign the keys (code 257; typically 2048 bits). The keys can be displayed with
dig <domain> DNSKEY
(Listing 1). With some versions of dig
, the reverse parameter order also works. To enable a trouble-free key change, old and new keys can be used at the same time.
Listing 1
Displaying Keys
01 ;; ANSWER SECTION: 02 mozilla.org. 6074 IN DNSKEY 257 3 7 03 Av//szWRDSGz3g4JkiuQqws79YZ6nwxk0f9PF9MCQSYrRGd0f4Vuuouf 04 aKdeFvdeY4x9tGmh7FQ51Qi6EEr9LLy2Q8qTtEuN2fJ4PnWBNRfKwhWb 05 SNQWvq1jwhsXlsAelLz7tO5kptI7TO16p2ncpnhJqfzT5mWJ4nK76YPZ 06 lu+MZlIYJOMv/OQWD2nVmsjXeO0dnsrL8MyC5wdyPy2gbksWBscsbwN2 07 34APEYO48B6sovy2fuTVWnj7LDsEh3NzrhjGYlhWmtvrXg3mlFelz/MZ 08 XrK6uAlp6206Hc669ylfhIcD9d7w0rc9Ms1DFCh5wzVRbnJJF51mW2nC 09 mh5C8E7xSw== 10 mozilla.org. 6074 IN DNSKEY 256 3 7 11 AwEAAcY1VDPtMAXJPEwna184sRuU6QGYWnccTAyJhpzYQ+AsfK8eZVYS 12 iA2g8G24ZIvMrzOp6KQdx0XET6/QIO5xD7B0QH9YNXatVsXtzce+9Q9X 13 klmc78oKRKrVw969aEX91kjRXf6pjRXckJxXdXetxzuL6/E4bMKjQCGX 14 yJI20TGx
Confirming the keys follows a hierarchy. The DNS root servers have provided support for DNSSEC and corresponding keys since 2010. They use them to sign the keys, which in turn are used to sign keys for the top-level domains. The key of the top-level domain (e.g., .org ) is then used to sign the keys of the other domains (e.g., mozilla.org ). This hierarchy can be visualized easily with tools like DNSViz [2] (Figure 1).
The command
$ dig mozilla.org +dnssec +noall +answer +multi
displays the signature in the DNS response (RRSIG ) (Figure 2). Manual verification only works in a multistage, complex process, so a DNSSEC-compatible resolver makes sense here (see the "Pi-hole DNSSEC Resolver" box).
Pi-hole DNSSEC Resolver
If you want to use the security advantages of DNSSEC, you need a DNS resolver that can verify the DNS signatures. The easiest way to do this is with Pi-hole [3]. As the name suggests, a Raspberry Pi is all you need on the hardware side, although the software also runs on Debian, Ubuntu, Fedora, or CentOS. A Docker container is also available. Pi-hole was originally an ad blocker, but it is also very useful for filtering malware. Thanks to a good web interface, Pi-hole is easy to configure. If you check the software's query log (Figure 3), you will immediately see which domains use DNSSEC (here, mozilla.org ) and which do not (e.g., firefox.com ). For the domains that use DNSSEC, manipulated entries would be detected and blocked.
Alternatively, you can easily check whether DNSSEC is in use by running nslookup
against a test address, even on Windows. If DNSSEC is not in use, the request for sigfail.verteiltesysteme.net
will return an IP address, because the faulty signature was not verified. Otherwise, only sigok.verteiltesysteme.net
will return an IP address, whereas the query for sigfail.verteiltesysteme.net
will result in a SERVFAIL
error (Figure 4).
In principle, the key distribution mechanism for DNSSEC can also distribute keys for any other application, such as TLS, IPsec, email encryption, and so on. A separate protocol field exists for this purpose during key transmission.
Privacy
The confidentiality of DNS queries can only be ensured by encrypting DNS traffic. One solution for this is DNSCrypt [4], which exchanges unmodified DNS packets in encrypted form over port 443 but does not use the HTTPS protocol. Numerous DNS providers support DNSCrypt.
Another possibility is DNS over TLS (DoT) [5], which routes DNS traffic over a TLS-encrypted connection on port 853. One of the protagonists of this protocol is Google. Android supports DoT from version 9 "Pie" without additional software, and now that the small GL-iNet [6] router and others support DoT, it is likely to become more widespread in the small office and home office. Public DNS servers for this protocol include Google, Cloudflare, Quad9, and Digitalcourage. By the way, routing to port 853 opens up a simple option for blocking DoT on a firewall.
A better way to protect the privacy of DNS users, and one that is currently the subject of heated debate, is DNS queries over HTTPS (DoH) [7]. Mozilla Firefox version 62 and newer support this method; in the USA Mozilla has started to enable it by default. Additionally, some software packages redirect the complete DNS resolution of the operating system via DoH. The problem with this action is that your own local DNS server is no longer used, but that of a large provider such as Cloudflare, Google, or Quad9.
For the sake of completeness, DNSCurve [8], as put forward by Daniel J. Bernstein, also has to be mentioned, although it does not play a major role.
Side Effects
Until now, DNS was a service that was configured in the operating system and used by all applications. However, thanks to the efforts of web browser (Chrome, Firefox) and email client (Thunderbird) makers to encrypt DNS, name resolution is migrating to the application, where it is set up by users instead of the administrator.
In most cases, the DNS server can be configured for the operating system via DHCP. For devices over which admins have no control (bring your own device, BYOD), you can block external DNS servers on the firewall, forcing these clients to use the local DNS server. In this way, content filters (malware blockers) and DNS servers for internal resources (split horizon) can also be implemented in these cases.
However, if encrypted DNS comes into play, every option for blocking unwanted content or scanning DNS traffic for domains that distribute malware is thwarted. This is not always in the interests of an enterprise, university, research institution, authority, or the like.
A further problem for users also arises when DNS needs to run in split horizon mode; then, the DNS server handles queries differently depending on whether they come from inside or outside the local network. However, because both DoH and DoT always query an external DNS server, a user on the internal network always receives the external DNS response which means intranet pages would no longer be accessible if names pointed to different addresses on the local network, compared with externally.
On the other hand, domain names that only the internal DNS server knows are no problem. With the default settings you can tell clients to query the internal DNS server by the classic DNS mechanism if the DoH request does not return an answer. However, an experienced user could change the configuration so that their device never queries the internal DNS server. Enterprise-internal would then no longer be accessible for the user of the application with DoH.
Although protective measures such as DoH and DoT make sense on public networks (e.g., WiFi in hotels or on airplanes), a university, research institute or public authority must carefully consider whether it wants to walk down that road. Currently, Firefox (version 62 or newer) and Thunderbird (version 60 or newer) support DoH, which is enabled in the settings by the user (Figure 5).
Android, which has supported DoT since version 9 "Pie," is enabled in Settings | Network & Internet by selecting the Private DNS option. The default setting is Automatic , which means that Android will use DoT if possible; otherwise not.
Buy this article as PDF
(incl. VAT)