Freigeben über

qUICKLY Explained: DNS SRV Records, Purpose and Functionality

  • Artikel

Hello everyone, "q" here, now you are wondering what is this q or who it is? Well a dear friend of mine and manager back at Chrysler WHQ (2000-2008) used to call me Q cause though my name starts with Q (Qasim) but the U after Q is MIA, plus I always liked it when he called me q, sorta like the "q" in Star Wars Trek (many thanx B.) who has control of time and mass and everything else. So from now on, I will use q to quickly write my blogJ. Today, we will quickly cover DNS SRV records, why you ask.  Well, when I visit customers (region specific), I notice that there is often no clear understanding of what the SRV resource records are, who creates it, why and when they are needed and above all which ones are they. So, today, we will learn about DNS SRV records briefly aka quickly.

                      We all know that DNS provides hostname resolution and that this service is critical to Active Directory. It allows domain controllers as well as domain members to locate services in the domain. One of those services is Client / User authentication; and as we all know - Active Directory is a distributed database, one domain controller needs to find another in order to replicate the changes it makes to its local copy of AD Database (NTDS.DIT). DNS provides specific types of records for such services; these records are called SRV or Service Resource Records. SRV records map the name of a service to the server offering this service. Clients and domain controllers use these SRV records to find the IP addresses of authenticating domain controllers and replicating partners. I don't need to remind you that a DNS Server must allow dynamic updates to the zone where SRV records are to be created by domain controllers in a domain. DNS maintains zones and these zones allow Secure dynamic updates by default. If a DNS Server does not or is configured to NOT allow any dynamic updates, these SRV records will not be registered by domain controllers automatically. We will discuss this some other time.

                      Once you promote a server to a domain controller using DCPROMO, a text file containing all the appropriate records the domain controller will register in DNS gets created. This text file is in the %systemroot%\system32\config and is called NETLOGON.DNS. Whenever a domain controller starts, the NETLOGON service registers these records or refreshes these records in the primary zone held by the DNS. This way, you will always have the SRV records registered dynamically with the DNS Server. There are other means to do the same, for instance, you can stop and start the NETLOGON service manually or nltest /dsregdns etc.

So now, let's see what these records are and their function.

  • _ldap._tcp.<DNSDomainName> - Allows a client to locate a domain controller in the domain named by <DNSDomainName>. A client searching for a domain controller in the domain contoso.com would query the DNS server for _ldap._tcp.contoso.com
  • _ldap._tcp.<SiteName>._sites.<DNSDomainName> - Allows a client to find a domain controller in the domain and site specified (e.g., _ldap._tcp.lab._sites.contoso.com for a domain controller in the Lab site of contoso.com).
  • _ldap._tcp.pdc._ms-dcs.<DNSDomainName> - Allows a client to find the PDC emulator (FSMO) role holder of a domain. Only the PDC of the domain registers this record.
  • _ldap._tcp.gc._msdcs.<DNSForestName> - Allows a client to find a Global Catalog (GC) server. Only domain controllers serving as GC servers for the forest will register this name. If a server ceases to be a GC server, the server will deregister this record.
  • _ldap._tcp. ._sites.gc._msdcs.<DNSForestName> - Allows a client to find a GC server in the specified site (e.g., _ldap._tcp.lab._sites.gc._msdcs.contoso.com).
  • _ldap._tcp.<DomainGuid>.domains._msdcs.<DNSForestName> - Allows a client to find a domain controller in a domain based on the domain controller's globally unique ID. A GUID is a 128-bit (8 byte) number that generates automatically for referencing Active Directory objects.
  • <DNSDomainName> - Enables a client to find a domain controller through a normal Host record.

You can also use the NETLOGON.DNS file to import the records to non-Microsoft DNS Servers that support SRV records but do not allow dynamic updates. At this point we will not discuss weights, priority or port numbers for these services. Another qUICK explanation is required for that ;)

And a picture is worth a 1000 words

 

Cheers J

Comments

  • Anonymous
    January 01, 2003
    Very informative article. Thanks a lot.

  • Anonymous
    January 01, 2003
    updated - much appreciated. :)

  • Anonymous
    October 07, 2010
    Think you meant the Q in Star Trek.  ;-)  Just saying..I love both too though.

  • Anonymous
    October 30, 2010
    Good to see these blogs. Can you do one on GNZ? I'd like to learn this new type of zone in a mix environment.

  • Anonymous
    March 23, 2011
    Q, hmmm, can you q our problems away? Happy to see you explaining some of the grey areas in AD.

  • Anonymous
    August 29, 2012
    The comment has been removed

  • Anonymous
    November 20, 2013
    the SRV record for the PDC emulator (FSMO) role holder is _ldap._tcp.pdc._msdcs.<DNSDomainName> not _ldap._tcp.pdc._ms-dcs.<DNSDomainName> But otherwise very nice article. thanks.

  • Anonymous
    April 30, 2014
    Thanks for this article. Very easy to understand.