12. The Present and the future of resolvers and DNS related features #

Let me briefly review some important features and topics related to DNS, stub resolvers, and dual-stack applications. While these are beyond the scope of this series, they are worth mentioning.

12.1 New DNS record: HTTPS #

DNS has introduced a new and interesting resource record called HTTPS. This record addresses problems related to web service clients. Typically, when a client has only a domain name without additional information, it connects using plain text port 80. The server usually redirects to port 443 with HTTPS and sets an HSTS header. However, this initial plain text request-response has security issues and is vulnerable to Man-in-the-Middle (MitM) attacks.

Another problem is speed: additional redirects are not cheap, and the client often upgrades to HTTP/2 or even HTTP/3 afterward. All of this adds unnecessary latency to the client side.

To address these issues, the HTTPS record plays a canary role for existing HTTPS services. It provides supported ALPN protocols (such as HTTP/2 and HTTP/3) and returns A and/or AAAA addresses for connection in one response saving latency and packet rate.

For example;

$ dig @1.1.1.1 cloudflare.com HTTPS

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @1.1.1.1 cloudflare.com HTTPS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8180
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cloudflare.com.                        IN      HTTPS

;; ANSWER SECTION:
cloudflare.com.         51      IN      HTTPS   1 . alpn="h3,h2" ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5

;; Query time: 11 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Fri Aug 02 01:18:53 BST 2024
;; MSG SIZE  rcvd: 116

12.2. DNSSEC #

The Domain Name System Security Extensions (DNSSEC) is a feature of the Domain Name System (DNS) that authenticates responses to domain name lookups.

We can enable it with systemd-resolved for local stub resolver:

Note that DNSSEC validation requires retrieval of additional DNS data, and thus results in a small DNS lookup time penalty.

To verify and query DNSSEC keys you can continue using dig, but the recommended and more convenient tool is delv (man 1 delv).

$ delv @1.1.1.1 microsoft.com
; unsigned answer
microsoft.com.          130     IN      A       20.70.246.20
microsoft.com.          130     IN      A       20.76.201.171
microsoft.com.          130     IN      A       20.112.250.133
microsoft.com.          130     IN      A       20.231.239.246
microsoft.com.          130     IN      A       20.236.44.162

For failing test please use:

• dnssec-failed.org
• rhybar.cz

$ delv  @1.1.1.1 dnssec-failed.org
;; resolution failed: SERVFAIL

In systemd-resolved the default for DNSSEC is “allow-downgrade”, but it could be hardened to yes.

$ cat /etc/systemd/resolved.conf

[Resolve]
...
DNSSEC=yes
# DNSSEC=allow-downgrade
...

12.3 DNS over TLS (DoT), DSN over HTTPS (DoH) and DNS over QUICK (DoQ) #

DNSSEC provides data integrity and authentication, but the content of requests and responses remains in plain text. To address this issue, DNS over TLS (DoT) and later DNS over HTTPS (DoH) were introduced. The main difference between these two is the transport and port used. DoH is more private because it mimics regular HTTPS traffic (using 443 port and https transport), making it harder to detect and block.

The https://www.dnscrypt.org/ is a good starting point.

12.4 Oblivious DNS #

If we go further and consider privacy with DoT and DoH, there is a concern that a DNS forwarder knows too much about your requests. This led to the development of Oblivious DNS (oDNS), which introduces the concepts of an oDNS relay and an oDNS target. In this system, the client encrypts its request using the public key of the target and then proxies the encrypted request through the relay. Relay sends a request to the target without client identification information. This process helps to hide the client’s identity from the oDNS target and the request content from the oDNS relay.

For a great client with comprehensive documentation, see https://github.com/natesales/q

12.5. DNS Push Notifications #

There is an interesting and reasonable new RFC 8765 DNS Push Notifications, which suggests keeping an open connection between the DNS server and stub resolver to send push notifications when something changes. This idea could restore DNS as the mechanism for service discovery.