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.

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).

Figure 1: Visualizing the key hierarchy for www.mozilla.org courtesy of the DNSViz online service.

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).

Figure 2: The signature in the DNS response is transferred in the RRSIG field.

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.

Figure 3: The query log web interface shows whether DNSSEC is in use (SECURE) or not in use (INSECURE). A faulty signature would be tagged BOGUS.

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).

Figure 4: On Windows, you can use nslookup and a test address to check whether DNSSEC is in use. If not, the request for sigfail.verteiltesysteme.net returns an IP address, because the faulty signature is not checked.

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).

Figure 5: Enabling DoH in Firefox 70.

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.