The Magic of SRV Records




Some DNS record types are very common, including (but not limited to):

Record Type   Function
A             Maps domain name to IPv4 address
AAAA          Maps domain name to IPv6 address
CNAME         Maps one domain to another
NS            Defines a domain's name server
PTR           Maps an IP address to a domain name
MX            Defines a domain's mail exchanger
TXT           Returns some specified text content

Another DNS record type, one that's less-common/less-well-known is the SRV record. SRV records are defined in RFC 2782 from February 2000, co-authored by Farsight's very own Dr. Paul Vixie.

Overview / Review

SRV records are found at standardized names (_servicename._protocol.domain), and define both the port number and the domain name used by a service. For example, SRV records for some popular Google services look like:       86400 IN SRV   5 0 993  86400 IN SRV   5 0 587     86400 IN SRV   5 0 443

In this case, the port numbers are the "expected ones" for the respective services, but that may not always be true. SRV records allow sites to redefine services for delivery over an alternative port if that's locally necessary or desirable.

There may be multiple SRV records for a given service at a given domain. In that case, the priority values associated with the SRV record will be used to determine which record gets tried first. Lowest numeric values have the highest priority/get tried first. 900 IN SRV 5  0 5269 900 IN SRV 20 0 5269 900 IN SRV 20 0 5269 900 IN SRV 20 0 5269 900 IN SRV 20 0 5269

SRV records also have the ability to use weights (see RFC2782 at page 2 and at page 4). The original intent for the weight field is that if you had one machine that was three times as powerful as one of your other systems, you could reflect that in the SRV record weights, allowing those systems to be more efficiently utilized. In reality, as is often the case, all servers are interchangeable/equally powerful, and the weight field is just set to zero/isn't really used.

Got A SRV Record? That's Really Just The First Step

It may be self-obvious, but mapping the domains mentioned in SRV records down to an actual IPv4 or actual IPv6 address will require additional processing. That is, after retrieving an SRV record, you need additional work to actually get an IP address. For example, uses a SRV record to point at, which we can then go on to resolve to:          79     IN   CNAME 254	IN   A 254	IN   A          252    IN   CNAME 127    IN   AAAA     2607:f8b0:400e:c04::6d

Occasional Confusion When SRV Records End Up Getting Used

Because most people don't even know that SRV records exist, it is common for there to be confusion if a site uses them.

If manually chasing SRV records with dig or similar tools, you need to explicitly ask to see the SRV records. For instance, if you discovered the name and attempted to resolve it, you'd see:

$ dig +short

You need to explicitly ask to be told about SRV records, instead:

$ dig +short SRV
5 0 5222

$ dig +short
$ dig +short AAAA

DNSDB Robustness

SRV is at the core of Farsight's robustness for uploads and site to site data transfer. The tool wrapsrv allows anyone to take a simple TCP host connection and enables an administrator to leverage SRV records to add opportunities to retry after failures. The wrapsrv tool is part of the sie-passivedns-sensor code.

Finding SRV Records in DNSDB

If you use DNSDB, many SRV records can be found. For example, if a user who has API access to DNSDB wanted to find Active Directory domain controllers, he could look for _ldap._tcp.pdc._msdcs.domain names with the command:

$ -l 1000000 -r _ldap._tcp.pdc._msdcs.\*/SRV > active-directory.txt

That command returns over 5,000 known Active Directory domain controllers from over 2,000 unique effective top level domains. If all those AD domain controllers are in fact Internet accessible, that would be a potential source of concern since many Microsoft users believe that it is "not a good idea" to expose AD domain controllers on public networks unless it is absolutely necessary.

Joe St Sauver, Ph.D. is a Scientist with Farsight Security, Inc.