joeware - never stop exploring... :)

Information about joeware mixed with wild and crazy opinions...

DNS SRV Records

by @ 12:31 am on 12/2/2018. Filed under tech

Active Directory location capability is all based on open standards based DNS SRV records which are designed to offer location capability for ANY services. The DNS SRV record RFC is RFC2782 which you can find at https://www.ietf.org/rfc/rfc2782.txt. There are two main components of the SRV process for domain controllers; registration and lookup.

First the domain controllers figure out what SRV records need to be registered for its services depending on various configurations in Active Directory and the registry of each domain controller. Applications aren’t involved in this process at all, they simply need to be able to lookup the results in DNS. The main issues that can occur on this side are DNS systems that aren’t properly allowing dynamic registrations or Active Directory admins misconfiguring sites and subnets and/or registry keys (directly or via GPO).

Second the clients that need to access Active Directory query DNS for the service’s SRV records in the specific sites that they need domain controllers OR look at the global set of service SRV records for all of Active Directory.

The service SRV records are significantly different from other well-known DNS record types such as A/HOST records or CNAME records in that there is a bunch of information packed into the records that allow for a fairly robust high availability service location system. They are exactly the same in that they can be dynamically updated and queried using open standards based DNS APIs.

SRV Record Components

Service SRV records can have multiple hosts and the following components are the publicly available pieces in DNS that make up each SRV record:

Record Name

  • The actual name of the service record in DNS that you specify to look up the record.
  • This is broken up of several components itself
  • _<SERVICE>.<PROTOCOL>.<NAME>
  • SERVICE: The service prefix for specified service such as LDAP.
  • Note that there is no requirement for a service name to be prefixed with an underscore but they usually are. All of the SRV records published by AD are prefixed with an underscore.
  • PROTOCOL: The protocol the record is for such as TCP or UDP.
  • NAME: The DNS Zone the record lives in such as domain.com
  • Ex: _ldap._tcp.k16tst.test.loc

    • Priority

    • The relative priority of the specified host for the record. The lower the value the more preferred the host. These values are for picking which hosts should be targeted first.
    • Ex: 0

    Weight

    • The relative weight of the specified host for the record. The higher the value the more preferred. These values are for balancing load between multiple hosts with the same priority.
    • Ex: 100

    Port

    • What port the service is available on for this specific host.
    • Ex: 389

    Svr HostName

    • The canonical hostname of the target of the record.
    • Ex: k16tst-dc1.k16tst.test.loc.

      In addition to the above, each record also has a TTL specified for it. This controls how fast the records age out and changes will get updated down through the hierarchy of DNS servers and client caches. The lower the value the more “dynamic” the records can be to offer up different options, etc. Additionally the lower the value the higher the DNS Lookup and replication load there is on the systems as well.

      Priority and Weight

      Most of the components of a service SRV record should, generally speaking, be self-explanatory. The priority and weight are a little different as their proper use may not be obvious.

      Each service record can have multiple SRV entries associated with it for each unique instance of the service. The priority and weight give hints on how the entries should be used.

      The priority is a numeric value where the lowest value has the great preference. Use all of the entries with a priority of 0 before all of the entries with a priority of 1 before all of the entries with a priority of 10 before all of the entries with a priority of 100, etc. If none of the instances with the lowest priority are responding, drop to the next lowest priority, etc.

      The weight is a numeric value where the highest value has the greatest preference. Unlike with priority all of the weights of the similar priority entries that are available are collected together and normalized to an overall value of 100% and that gives a ratio / percentage of how requests to each service instance should be balanced. Obviously, this should also be used dynamically in terms of which records are actually for available services at the time of use. This becomes more clear with the examples.

      Ex 1: Say you have three instances of the service each with a priority of 0 and weight of 100 then you should balance the requests across all three instances equally, 33.333% per instance. If one of those instances becomes unavailable then you should balance the requests across the two remaining instances at 50% per instance.

      Ex 2: Say you have three instances of the service each with a priority of 0 but two have a weight of 40 and one has a weight of 20 then out of every 10 requests 4 should go to service instance 1, 4 should go to service instance 2, and 2 should go to service instance 3. If service instance 2 with a weight of 40 becomes unavailable then for every 10 requests 7 should go to service instance 1 and 3 should go to service instance 2.

      Ex 3: Say you have three instances of the service each with priority of 0 and weight of 100 and one instance of the service with a priority of 1 and a weight of 100. Requests to the service should be split three ways between the instances with a priority of 0. If all three instances become unavailable and ONLY after all three instances become unavailable then all request should go to the service instance with a priority of 1.

      AD Service SRV Records

      The SRV records you will see for AD include

      • _ldap – LDAP service SRV records including normal LDAP and Global Catalog LDAP.
      • _gc – LDAP server records used only for Global Catalog LDAP.
      • _kerberos – Kerberos KDC service SRV records.
      • _kpasswd – Kerberos Password Change service SRV records.

      Here is an example of a complete set of records for the PDC of the root domain in a multi-domain forest with multiple sites. You can see the same information for any specific domain controller by looking at the C:\Windows\System32\Config\netlogon.dns file on each domain controller. In fact if you are missing AD SRV records in DNS this is the first place to look to troubleshoot.

      _ldap._tcp.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.Default-First-Site-Name._sites.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.pdc._msdcs.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.98fd1190-e167-4734-a585-7981238a135e.domains._msdcs.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
b306bddc-2945-4a7d-b7ce-0bc829c55c5a._msdcs.k16tst.test.loc. 600 IN CNAME K16TST-DC1.k16tst.test.loc.
_ldap._tcp.dc._msdcs.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.gc._msdcs.k16tst.test.loc. 600 IN SRV 0 100 3268 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.k16tst.test.loc. 600 IN SRV 0 100 3268 K16TST-DC1.k16tst.test.loc.
_gc._tcp.k16tst.test.loc. 600 IN SRV 0 100 3268 K16TST-DC1.k16tst.test.loc.
_gc._tcp.Default-First-Site-Name._sites.k16tst.test.loc. 600 IN SRV 0 100 3268 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.DomainDnsZones.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.ForestDnsZones.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.RODCSite._sites.gc._msdcs.k16tst.test.loc. 600 IN SRV 0 100 3268 K16TST-DC1.k16tst.test.loc.
_gc._tcp.RODCSite._sites.k16tst.test.loc. 600 IN SRV 0 100 3268 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.RODCSite._sites.DomainDnsZones.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.RODCSite._sites.ForestDnsZones.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_kerberos._tcp.dc._msdcs.k16tst.test.loc. 600 IN SRV 0 100 88 K16TST-DC1.k16tst.test.loc.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.k16tst.test.loc. 600 IN SRV 0 100 88 K16TST-DC1.k16tst.test.loc.
_kerberos._tcp.k16tst.test.loc. 600 IN SRV 0 100 88 K16TST-DC1.k16tst.test.loc.
_kerberos._tcp.Default-First-Site-Name._sites.k16tst.test.loc. 600 IN SRV 0 100 88 K16TST-DC1.k16tst.test.loc.
_kerberos._udp.k16tst.test.loc. 600 IN SRV 0 100 88 K16TST-DC1.k16tst.test.loc.
_kpasswd._tcp.k16tst.test.loc. 600 IN SRV 0 100 464 K16TST-DC1.k16tst.test.loc.
_kpasswd._udp.k16tst.test.loc. 600 IN SRV 0 100 464 K16TST-DC1.k16tst.test.loc.
k16tst.test.loc. 600 IN A 192.168.0.75
gc._msdcs.k16tst.test.loc. 600 IN A 192.168.0.75
DomainDnsZones.k16tst.test.loc. 600 IN A 192.168.0.75
ForestDnsZones.k16tst.test.loc. 600 IN A 192.168.0.75
_ldap._tcp.joenetlogontestsite._sites.gc._msdcs.k16tst.test.loc. 600 IN SRV 0 100 3268 K16TST-DC1.k16tst.test.loc.
_gc._tcp.joenetlogontestsite._sites.k16tst.test.loc. 600 IN SRV 0 100 3268 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.joenetlogontestsite._sites.DomainDnsZones.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.joenetlogontestsite._sites.ForestDnsZones.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.joenetlogontestsite._sites.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_kerberos._tcp.joenetlogontestsite._sites.dc._msdcs.k16tst.test.loc. 600 IN SRV 0 100 88 K16TST-DC1.k16tst.test.loc.
_ldap._tcp.joenetlogontestsite._sites.dc._msdcs.k16tst.test.loc. 600 IN SRV 0 100 389 K16TST-DC1.k16tst.test.loc.
_kerberos._tcp.joenetlogontestsite._sites.k16tst.test.loc. 600 IN SRV 0 100 88 K16TST-DC1.k16tst.test.loc.

      One Last Thing…

      I love this model. I think it is extremely intelligent and useful. Microsoft was brilliant for their involvement in SRV records and use of it in this way. It takes you out of the hole you can be in by depending on any given machine to always be available whether that machine is a domain controller, a network switch, a Virtual IP / Load Balancer, whatever. This is an inexpensive globally redundant mechanism using functionality available in every network that when it is used properly is very useful and just outright awesome.

      That being said I am also very disappointed because Microsoft didn’t use it for LDAPS or Global Catalog LDAPS records nor have an option to use it for ADLDS or even for the ADWS service that now runs on Domain Controllers and ADLDS servers for the AD PowerShell Cmdlets. Come on Microsoft. On the positive side, because it is all based on open standards, you can (and I have) write scripts/tools to add/remove additional records as you see fit.

      If you haven’t checked it out before, check out DNSSrvRec which is pretty much a quick and dirty tool that I wrote over a decade ago that allows you to quickly add and/or delete SRV records. You can find it at https://www.joeware.net/freetools/tools/dnssrvrec. It is so QnD there is a super obvious typo bug that is seen as soon as you run it, but don’t worry, it doesn’t impact its functionality. You will note that the usage examples illustrate how to add _LDAPS records but I use this to this day for troubleshooting and temporally removing or fixing the normal AD SRV records when things are broken.

         joe

      Rating 4.82 out of 5

      Comments are closed.

      «
      »

      [joeware – never stop exploring… :) is proudly powered by WordPress.]