Welcome To My Journey

I have created this blog to record the things I learn as I progress in my studies of the Windows Operating System. My focus will primarily be the latest Operating System offerings by Microsoft, but much of the content below may also apply to earlier versions. I invite you to join me as I explore and learn about Microsoft Windows!

Friday, October 28, 2011

Cleaning Up Metadata and SRV Records

In the last video, I showed how to clean up the metadata for a Domain Controller that’s no longer able to participate in your AD forest.  In this video, which follows from the previous post, I want to show one additional bit of cleanup that will be necessary.  In the video below, I briefly describe the need to manually cleanup SRV records as part of the overall metadata cleanup effort.  After the video, I provide a deeper overview of SRV records and how to read one:

SRV Records and DNS

Most of you probably know how must Active Directory depends on DNS.  In fact, AD can’t function without it because DNS is how Active Directory services are located within an environment.

To allow Active Directory services to be located, DNS uses a particular type of record known as an SRV record.  SRV records are not specific to Active Directory or even Microsoft.  These records are used by servers to advertise the types of services they have available for clients to use.  For example, Active Directory provides LDAP, Kerberos and Global Catalog services (among others) and advertises this through DNS SRV records.

These records, located in the forward lookup zone for your Active Directory domain, come from a file called NETLOGON.DNS.  On a domain controller, this file is populated during the DCPROMO process.  NETLOGON.DNS is located at the following location on your domain controller:

%systemroot%\Windows\System32\Config\netlogon.dns

If DNS is configured to accept dynamic updates, these records will also be added to DNS.  However, if DNS doesn’t accept dynamic update it will be necessary to send this file to your DNS team so they can enter the files directly.

Understanding SRV Records

When you first look at an SRV record, it can be a bit confusing.  To help with that, I’ve provided the following walk-through of a few SRV records that are used by DCs to advertise services.

First, let’s look at the list of SRV records available for W2K8-DC1.W2K8Forest.com (note that some of these are wrapped onto multiple lines here, but they should be viewed as one line):

_ldap._tcp.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.pdc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.467fe6a7-28e3-475f-9739-b11684cc1bf3.domains._msdcs.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
61657dc6-742e-4fae-98cb-60ddb9406c41._msdcs.W2K8Forest.com. 600 IN CNAME W2K8-DC1.W2K8Forest.com.
_ldap._tcp.dc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.gc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 3268 W2K8-DC1.W2K8Forest.com.
_gc._tcp.W2K8Forest.com. 600 IN SRV 0 100 3268 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.DomainDnsZones.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.ForestDnsZones.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.Dallas._sites.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.Dallas._sites.gc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 3268 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.Dallas._sites.dc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_gc._tcp.Dallas._sites.W2K8Forest.com. 600 IN SRV 0 100 3268 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.Dallas._sites.DomainDnsZones.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_ldap._tcp.Dallas._sites.ForestDnsZones.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.
_kerberos._tcp.dc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 88 W2K8-DC1.W2K8Forest.com.
_kerberos._tcp.Dallas._sites.dc._msdcs.W2K8Forest.com. 600 IN SRV 0 100 88 W2K8-DC1.W2K8Forest.com.
_kerberos._tcp.W2K8Forest.com. 600 IN SRV 0 100 88 W2K8-DC1.W2K8Forest.com.
_kerberos._tcp.Dallas._sites.W2K8Forest.com. 600 IN SRV 0 100 88 W2K8-DC1.W2K8Forest.com.
_kerberos._udp.W2K8Forest.com. 600 IN SRV 0 100 88 W2K8-DC1.W2K8Forest.com.
_kpasswd._tcp.W2K8Forest.com. 600 IN SRV 0 100 464 W2K8-DC1.W2K8Forest.com.
_kpasswd._udp.W2K8Forest.com. 600 IN SRV 0 100 464 W2K8-DC1.W2K8Forest.com.
W2K8Forest.com. 600 IN A 192.168.1.40
gc._msdcs.W2K8Forest.com. 600 IN A 192.168.1.40
DomainDnsZones.W2K8Forest.com. 600 IN A 192.168.1.40
ForestDnsZones.W2K8Forest.com. 600 IN A 192.168.1.40

Now let’s select a few records from this list and analyze them.

_ldap._tcp.W2K8Forest.com 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com

This is a generic LDAP SRV record.  The information it’s conveying is broken out as follows:

  • SERVICE (_ldap): this lets us know that W2K8-DC1 is providing the LDAP service
  • PROTOCOL (_tcp): this lets us know that W2K8-DC1 is providing this service through the TCP protocol
  • NAME (W2K8Forest.com): this is the domain for which this record is relevant
  • TTL (600): this is the default time to live (TTL) of the record (in seconds)
  • CLASS (IN): this represents the standard Internet Class for DNS
  • RESOURCE RECORD (SRV): this tells us that the record is intended to help clients locate services on the network (in this case, the LDAP service)
  • PRIORITY (0): this is the DNS priority for the server.  Clients will try to connect to servers that have a lower number before they attempt to use those with a higher number (in this case, a lower number equals a higher priority).
  • WEIGHT (100): This allows for load-balancing of the servers providing the listed service.  If you have newer and faster servers that can handle more client connections, you might want to set a higher weight (a server with a record that has a higher weight has a greater likelihood of being chosen over a lower weight).
  • PORT (389): This represents the port that will be used by the server.  So if a client makes an LDAP request to W2K8-DC1, it will need to do so through port 389.
  • TARGET (W2K8-DC1.W2K8Forest.com): This is the fully qualified domain name of the server providing the listed service
61657dc6-742e-4fae-98cb-60ddb9406c41._msdcs.W2K8Forest.com. 600 IN CNAME W2K8-DC1.W2K8Forest.com.

Though this isn’t strictly an SRV record (it’s a CNAME record), it’s important to mention since it’s found in the netlogon.dns file.  What this record does is allow the DCs to talk with each other.  The relevant components are as follows:

  • DSAGUID (61657DC6-742E-4FAE-98CB-60DDB9406C41): this is the globally unique identifier of the DSA (directory system agent), which is the DC.
  • RESOURCE RECORD (CNAME): identifies this record as a canonical name record, providing translation (in this case) between the server GUID and the known computer name.
  • TARGET (W2K8-DC1.W2K8Forest.com): The fully qualified domain name of the DC.

There are a few special terms in the netlogon.dns file that deserve a bit more attention.  Those are explained below:

  • _gc: This indicates that the server is providing the Global Catalog service
  • _pdc: This indicates that the server owns the Primary Domain Controller Emulator role within the domain.  The PDC Emulator is one of the Single Master Operator roles that was explained in an earlier post.
  • _msdcs: This is used exclusively for Active Directory Domain Controllers.  It is necessary because services like Kerberos and LDAP aren’t specific to Microsoft, thus clients need a way to identify the Microsoft implementation of these services.

Site-Specific Records

Briefly, I want to make sure and mention an element that appears in some of the SRV records.  Take a look at the record below:

_ldap._tcp.Dallas._sites.W2K8Forest.com. 600 IN SRV 0 100 389 W2K8-DC1.W2K8Forest.com.

Notice that it contains a reference to “Dallas._sites”.  The purpose of this added element is so that clients can specify which Active Directory site they’re in (a site is defined here) and can leverage the resources that are closest to them.  Without these records, DNS might direct a client to use a resource at the other end of a slow network link, but with site-specific records clients can be directed to resource that will provide the most optimal experience.

NOTE: This highlights the importance of always keeping each of your IP Subnets updated and properly linked to sites in Active Directory.

DomainDnsZones and ForestDnsZones

These represent the Application partitions used when DNS is integrated and replicated via Active Directory.  DomainDnsZones are used for information replicated within a domain and ForestDnsZones are used for replicating information between domain controllers within the forest.

The records above are:

DomainDnsZones.W2K8Forest.com. 600 IN A 192.168.1.40
ForestDnsZones.W2K8Forest.com. 600 IN A 192.168.1.40

These are made available for DCs that are seeking other domain controllers that host these partitions (which DCs host an Application partition is specified when the partition is created).  In this case, these records indicate that these partitions can be contacted at the IP address 192.168.1.40 (the IP Address of W2K8-DC1).

Summary

SRV Records can be a very detailed topic and it’s important to spend time getting to know them.  Below I’ve provided several links that provide additional reading on this important topic.

As I said in the previous post, sometimes bad things happen that allow us to share information with each other.  Hopefully this has been helpful.

Articles that will be useful for further reading on this topic:

Posted by at