DNS

The WolfTech Active Directory domain is using split DNS zones.  This means that multiple DNS suffixes are supported within the single Active Directory Domain.  This also means that departmental OU admins have certain responsibilities for maintaining DNS suffixes for their departmental networking devices:

  1. No computers should be in the “wolftech.ad.ncsu.edu” DNS zone except the WolfTech domain controllers and other central Active Directory infrastructure servers.
  2. All computers within an OU should have a valid DNS suffix.  You will get a daily report from ADToolkit should any of your computers not be registered in DNS correctly.
  3. It is preferable (but not required) that departmental OUs use 1 DNS suffix for all computers in their OU.
  4. We have delegated to computers the ability to update their DNS name in Active Directory.  This requires that we maintain a list of authorized DNS suffixes for the domain.  This list is specified in the msDS-AllowedDNSSuffixes attribute. To view this attribute:
    1. Open the Active Directory Users and Computers with Advanced Features enabled (or use ADSI Editor).
    2. Right click the wolftech.ad.ncsu.edu object and choose Properties.
    3. Click the msDS-AllowedDNSSuffixes attribute and click View.
    4. This attribute can only be updated by Domain Admins.
  5. For a computer to register its DNS name in Active Directory, its DNS suffix must be provided to it by a group policy (and must have the the appropriate delegated permissions).  Preferably, the DNS suffix for the departmental OU should be specified in the <DEPT>-OU Policy. This setting is located in:
    • Computer Configuration\Administrative Templates\Network\DNS Client\Primary DNS Suffix
  6. To make it easier to locate a machine using only the hostname, a list of DNS suffixes commonly used on your network should be specified in group policy. This setting is located in:
    • Computer Configuration\Administrative Templates\Network\DNS Client\DNS Suffix Search List

 

Troubleshooting:

  • Kerberos issue with DNS entries swapped for 2 AD computers
  • DNSHostName Attribute not updating

 

Disjoint Namespace in a Single Domain
There can be times when you need to have machines with different DNS suffixes than the domain name.  Perhaps a specific OU needs to have machines using a specific DNS suffix or its needed during a domain migration.  Either way, the only interface to edit the allowed DNS suffix list in AD is by editing the domain root object using adsiedit.  Here’s the technet article:
Technet: Enabling a Disjoint Namespace

Delegating SELF:’Validated write to DNS host name’ and ‘Validated write to service principal name’ to computer objects
By default, a computer in AD does not have the rights to modify its “dNSHostName” attribute of the computer’s AD computer object.  Which means if that value and the computers’s actual DNS record doesn’t match the domain name, queries using the NetBios name will fail to resolve. This happens even if you uncheck the “Change primary DNS suffix when domain membership changes” checkbox while adding the server to the domain unless you change permissions to allow it to update its own “dNSHostName” attribute.

Replication
“Service Discovery” includes other Domain Controllers.  Inter-Domain Controller replication requires having correct DNS information.  Because of the way client machines will try multiple domain controllers at login time and when getting policy, it is possible that you will not notice failing replication because of incorrect DNS until you have had a domain controller failure, at which point, you have already lost the information in the domain database. So making sure you have appropriate DNS entries is very important.  You can use dcdiag (included in 2008, a download in 2003) to verify correct DNS information.

 

SRV Records
Active Directory makes use of DNS SRV records for locating domains and specific services offered by them. It also makes use of Dynamic DNS Registration to automatically register services and hosts into DNS, if the DNS configuration supports that.

Specific Roles

  • PDC: The Primary Domain Controller (PDC) role has an SRV record associated with it. It is the “_ldap._tcp.pdc._msdcs.fakedomain.ncsu.edu.” line from the example below.  When moving the PDC role in Active Directory Users and Computers, the domain controller will attempt to dynamically update DNS.  If the domain’s SOA DNS server doesn’t support DDNS SRV updates, then the AD database will be out of sync w/ DNS as to which DC is the PDC.
  • KMS: Microsoft’s new volume licensing model (using KMS and MAK keys) makes use of SRV records for autodiscovery of the licensing server.  More documentation can be found.

Example!
Below are the (fake) DNS SRV records for the FAKEDOMAIN.NCSU.EDU domain and the A records for the DOMAINCONTROLLER and the domain itself:
Name Resolution in Active Directory 2000 – detailed description of what the below records mean.
domaincontroller                IN              A       152.XXX.XXX.XXX
fakedomain.ncsu.edu. 600        IN              A       152.XXX.XXX.XXX

_ldap._tcp.fakedomain.ncsu.edu. 600 IN SRV 0 100 389 domaincontroller.fakedomain.ncsu.edu.
_ldap._tcp.pdc._msdcs.fakedomain.ncsu.edu. 600 IN SRV 0 100 389 domaincontroller.fakedomain.ncsu.edu.
_ldap._tcp.987234e-980f-23ed-7897-987234dfeed4.domains._msdcs.fakedomain.ncsu.edu. 600 IN SRV 0 100 389 domaincontroller.fakedomain.ncsu.edu.
1c6f4542-980f-23ed-9987-987234dfeed4._msdcs.fakedomain.ncsu.edu. 600 IN CNAME domaincontroller.fakedomain.ncsu.edu.
_ldap._tcp.dc._msdcs.fakedomain.ncsu.edu. 600 IN SRV 0 100 389 domaincontroller.fakedomain.ncsu.edu.
_ldap._tcp.gc._msdcs.fakedomain.ncsu.edu. 600 IN SRV 0 100 3268 domaincontroller.fakedomain.ncsu.edu.
gc._msdcs.fakedomain.ncsu.edu. 600 IN A 152.XXX.XXX.XXX
_kerberos._tcp.dc._msdcs.fakedomain.ncsu.edu. 600 IN SRV 0 100 88 domaincontroller.fakedomain.ncsu.edu.
_kerberos._tcp.fakedomain.ncsu.edu. 600 IN SRV 0 100 88 domaincontroller.fakedomain.ncsu.edu.
_gc._tcp.fakedomain.ncsu.edu. 600 IN SRV 0 100 3268 domaincontroller.fakedomain.ncsu.edu.
_kerberos._udp.fakedomain.ncsu.edu. 600 IN SRV 0 100 88 domaincontroller.fakedomain.ncsu.edu.
_kpasswd._tcp.fakedomain.ncsu.edu. 600 IN SRV 0 100 464 domaincontroller.fakedomain.ncsu.edu.
_kpasswd._udp.fakedomain.ncsu.edu. 600 IN SRV 0 100 464 domaincontroller.fakedomain.ncsu.edu.
_ldap._tcp.MyChosenSiteName._sites.fakedomain.ncsu.edu. 600 IN SRV 0 100 389 domaincontroller.fakedomain.ncsu.edu.
_ldap._tcp.MyChosenSiteName._sites.gc._msdcs.fakedomain.ncsu.edu. 600 IN SRV 0 100 3268 domaincontroller.fakedomain.ncsu.edu.
_kerberos._tcp.MyChosenSiteName._sites.dc._msdcs.fakedomain.ncsu.edu. 600 IN SRV 0 100 88 domaincontroller.fakedomain.ncsu.edu.
_ldap._tcp.MyChosenSiteName._sites.dc._msdcs.fakedomain.ncsu.edu. 600 IN SRV 0 100 389 domaincontroller.fakedomain.ncsu.edu.
_kerberos._tcp.MyChosenSiteName._sites.fakedomain.ncsu.edu. 600 IN SRV 0 100 88 domaincontroller.fakedomain.ncsu.edu.
_gc._tcp.MyChosenSiteName._sites.fakedomain.ncsu.edu. 600 IN SRV 0 100 3268 domaincontroller.fakedomain.ncsu.edu.
Many of these SRV records are shared between multiple implementations of Kerberos (which AD uses).  MIT’s implimentation documentation on KDC location via SRV records.

Domain Topology
In Active Directory a Forest is the top-level container. A Forest, just like in real life, is a collection of (domain) trees.

Forest
A forest is a collection of one or more domain trees that share a global catalog, schema, and directory configuration, as well as <strong>automatic two-way transitive trust relationships</strong>.This is why a Forest is the security boundary in Active Directory.  A security boundary in Active Directory is a container where no one external to the container can take control away from administrators within the container.  The reason this is important is because of the implication for a domain, as a domain is NOT a security boundary. Within a Forest it is not possible for an administrator in one domain to prevent a rogue administrator from another domain from accessing data in their domain.

Domain Tree
A domain tree is a collection of domains arranged via a common namespace and share a common schema, security trust relationships, and a Global Catalog. Every domain in a Domain Tree is in the same Forest.

The namespace uses DNS.  Theoretically some Active Directory domains on campus would have the following structure:
ncsu.edu
/   |    \
/    |     \
ad ecew2k  acsad
/  \
engr  wolftech
This, however, is not the case.
Currently there is no ncsu.edu or ad.ncsu.edu domains, and engr.ad.ncsu.edu, wolftech.ad.ncsu.edu, ecew2k.ncsu.edu, and acsad.ncsu.edu are each in their own Forest. This is due to the distributed nature of IT on NC State’s campus. New domains are supposed to be created in the ad.ncsu.edu namespace for ease of managing DNS for the various Active Directory domains.

Domain
A Domain is intended to be a partition of the Forest that contains all of the resources, computers, and users who are members of a logical unit and thus form a namespace.  This namespace is the Domain name or DNS suffix. A Domain is the logical unit for Directory Services Replication and Authentication.

Sites
A Domain can have multiple Sites.  Sites are defined by groups of subnets and are managed using Active Directory Sites and Services.  Each site has a set of SRV records associated to it to allow the targeting of domain controllers for authentication, and possibly other AD aware applications.  The idea is that you have domain controllers in each site, and they replicate over the slow connection between them, but client machines do no attempt to authenticate against another site unless there are no domain controllers available in the current site.  The “_ldap._tcp.MyChosenSiteName._sites.gc._msdcs.fakedomain.ncsu.edu.” SRV record above is an example of a site specific SRV record.  Sites can also be used for targeting things like DFS targets, printers published in AD, and System Center Configuration Manager (SCCM) sites.