Your DNS is publishing a map of your infrastructure

DNS is usually described as the phone book of the internet. You have a name, you want an address, DNS gives you the address.

That description is incomplete in a way that matters for security. DNS also lets a client discover a service without knowing its name at all. You ask for _sip._udp.example.com and the response tells you where that organization runs voice-over-IP, on what port, across how many replicas.

This is a feature. It is genuinely useful. Administrators can move and reconfigure services without touching client configuration, and clients can autodiscover instances. It is also a reconnaissance surface that most organizations do not know they are exposing.

We scanned for it.

What we did

There are three relevant record types. SRV returns the hostnames and ports of service replicas for a given service and protocol. NAPTR helps a client work out which SRV names are valid to ask for. PTR, under the DNS-SD specification, lets a client enumerate distinct service instances rather than identical replicas, and optionally enumerate a zone’s service types outright.

That last one is the interesting part. Enumerating service types means asking a domain “what do you run” and getting an answer.

We built a scanner on the miekg/dns Go package, implementing SRV, NAPTR, and DNS-SD probes, and pointed it at the Tranco Top 1 Million. Exhaustive scanning is not practical, since there are over 12,000 registered service and protocol label pairs. So the scanner runs a probabilistic tuning phase first to estimate which services are actually popular, then does a complete scan against that reduced list.

What came back

The distribution was not what I expected. The most advertised services were calendar and contacts (caldav, carddav), voice (sip), chat (xmpp server and client), and mail (imap, pop3, smtp, submission). Then NAT traversal (stun, turn) and authentication protocols (kerberos, kpasswd, ldap, radius).

Read that list as an attacker rather than an administrator. It is a directory of where an organization keeps its calendars, its contact lists, its internal chat, its mail, and its authentication infrastructure, published voluntarily, queryable by anyone, no scanning of address space required.

Two findings on top of that.

A lot of it is not encrypted. Many advertised instances do not use TLS at all. Of the ones that do, a significant portion present invalid certificates. Calendar and contacts, the two most-advertised services in the whole dataset, are among the worst on this.

Almost none of it is authenticated at the DNS layer. 91.6% of domains advertising a service, and 89.9% of domains hosting one, do so without proper use of DNSSEC. The most common failure is not a broken signature. It is the absence of one, a missing RRSIG record.

Why the DNSSEC number is the one that matters

Without DNSSEC, a service discovery response is unauthenticated. An attacker positioned to answer the query controls where the client connects.

Follow the chain. A client wants to find its organization’s calendar server. It asks DNS. It accepts an unsigned answer. It connects to whatever host that answer names. If the service does not enforce TLS, or if the client tolerates an invalid certificate, which many autodiscovery clients historically have, the attacker now sits in the middle of the calendar sync.

Each of these three weaknesses is survivable alone. Unsigned DNS is bad but survivable if the endpoint has strict TLS. Weak TLS is bad but harder to exploit if the discovery answer is authenticated. What we found is the same domains failing both at once, at scale, on services that carry exactly the kind of data you would build a targeted attack on.

Service discovery amplifies this. Ordinary DNS misdirects a client to the wrong address for a name it already knew. Discovery misdirects a client to a service it was asking the network to name for it. The client has no prior expectation to check the answer against.

What to do about it

Sign your zones, and check that the signature is actually there. The dominant failure mode we found is a missing RRSIG, which usually means DNSSEC was configured somewhere and never completed, not that someone decided against it. This is a verification problem more than a policy problem.

Audit what your zone advertises. Most administrators have never enumerated their own SRV and PTR records from outside. Do it once. Anything published that does not need to be discoverable is a free gift to whoever scans you next.

If a service is advertised, it needs valid TLS. Discovery is precisely the case where a client cannot fall back on knowing the right hostname, so the certificate is doing all of the verification work.

What we did not answer

This was preliminary work, and there are three open threads.

Several of the most-advertised services, including caldav and carddav, are HTTP-based, so the HTTP authentication methods those instances actually use is the obvious next question. A large fraction of discovered services run over UDP, which makes amplification attack surface worth measuring directly. And the newer SVCB record adds another discovery mechanism the scanner does not yet probe.

Paper: SIPS, IPPS, or Oops! An Analysis of the Security and Privacy of DNS Service Discovery, USENIX Security 2024 (poster), with Mostafa Ahmed and Stephen Herwig.