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 (
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:
_imaps._tcp.gmail.com. 86400 IN SRV 5 0 993 imap.gmail.com. _submission._tcp.gmail.com. 86400 IN SRV 5 0 587 smtp.gmail.com. _caldavs._tcp.gmail.com. 86400 IN SRV 5 0 443 calendar.google.com.
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.
_jabber._tcp.gmail.com. 900 IN SRV 5 0 5269 xmpp-server.l.google.com. _jabber._tcp.gmail.com. 900 IN SRV 20 0 5269 alt1.xmpp-server.l.google.com. _jabber._tcp.gmail.com. 900 IN SRV 20 0 5269 alt2.xmpp-server.l.google.com. _jabber._tcp.gmail.com. 900 IN SRV 20 0 5269 alt3.xmpp-server.l.google.com. _jabber._tcp.gmail.com. 900 IN SRV 20 0 5269 alt4.xmpp-server.l.google.com.
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,
_imaps._tcp.gmail.com uses a SRV record to
imap.gmail.com, which we can then go on to resolve to:
imap.gmail.com. 79 IN CNAME gmail-imap.l.google.com. gmail-imap.l.google.com. 254 IN A 18.104.22.168 gmail-imap.l.google.com. 254 IN A 22.214.171.124 imap.gmail.com. 252 IN CNAME gmail-imap.l.google.com. gmail-imap.l.google.com. 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
_xmpp-client._tcp.arin.net and attempted to resolve it, you'd see:
$ dig +short _xmpp-client._tcp.arin.net [nothing]
You need to explicitly ask to be told about SRV records, instead:
$ dig +short _xmpp-client._tcp.arin.net SRV 5 0 5222 jabber.arin.net. $ dig +short jabber.arin.net 126.96.36.199 $ dig +short jabber.arin.net AAAA 2001:500:4:13::4
SRV is at the core of Farsight's robustness for uploads and site to site data
transfer. The tool
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
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:
$ dnsdb_query.py -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.
← Blog Home