Collecting and analyzing DNS logs should be at the top of your agenda regarding network monitoring. Everything that happens on the network tends to be reflected in DNS, and events that do not correlate with DNS are often suspect themselves. For example, if a host connects to an IP address directly without first receiving it as a DNS response. But in recent years, DNS has moved more and more to encrypted channels. Starting with DNS over TLS (DoT), DNS over HTTPS (DoH), and lately DNS over QUIC (DoQ).

Local recursive resolvers are usually configured via DHCP. Your ISP, or the network you connect to, will usually advertise one or two IP addresses to use as your resolver. As far as I know, DHCP cannot configure an encrypted resolver. But earlier today, @HQuest on X pointed out that iOS 17 implemented a new protocol, "Discovery of Designated Resolvers (DDR)". [1]

I took a look at my home network and, indeed, saw some related traffic. But first, a bit about DDR. RFC 9462 was last updated yesterday. So, it is a "hot of the press" protocol. But we often see protocol implemented before the RFC is finalized. 

The protocol uses "Service Binding (SVCB)" records. SVCB, just like HTTPS records, provides instructions to clients about how to connect to a particular service. This may include parameters like ports, application layer protocols, and encryption keys.

For DDR, three specific parameters are configured:

• The application layer protocol (DoT, HTTP2, QUIC ...).
• The port the resolver is listening on.
• A "DoH Path". This is a template that is used to create the URL to use for a DoH DNS query. For example, /dns-query{?dns}.

To discover a resolver, a client may query the SVCB record to _dns.resolver.arpa. The "resolver.arpa" domain is reserved for this purpose. Any resolver may now reply with information to use a specific encrypted resolver. 

The idea is that a resolver you have already configured via traditional means like DHCP may advertise that it is also reachable via DoH/Q/T. Cloudflare stated that they implemented experimental support for DDR in March of 2022, but my tests today did not get the expected response [2].

I do see, however, a good number of SVCB record requests for _dns.resolver.arpa in my local network. I also see requests for _dns.[domain name] hitting name servers for domains I own. These requests originate from PlanetLab, who may be researching the scope of DDR implementations.

So, what should you do to manage DNS on your network?

To reduce the chances of DDR being used, filter requests for _dns.resolver.arpa. It may be easiest to make your resolver authoritative for resolver.arpa. Optionally, you may want to add your SVCB record for _dns.resolver.arpa to direct clients to an authorized DNS server. You will still be able to get the data you need from logs collected by the resolver. At the same time, DNS traffic is a bit better protected on the local network.

Blocking the resolution of SVCB and HTTPS records may be an option, but I am unsure if that is a good idea as they start to see more use for protocols like QUIC unless you prefer to block QUIC as it does impede some network monitoring.

[1] https://datatracker.ietf.org/doc/rfc9462/
[2] https://blog.cloudflare.com/announcing-ddr-support/

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|