IT administrators have been working with and around Active Directory since the introduction of the technology in Windows 2000 Server. Windows 2000 Server was released on February 17, 2000 but many administrators began working with Active Directory in late 1999 when it was released to manufacturing (RTM) on December 15, 1999.
What is Active Directory DNS?
AD DS provides a built-in method of storing and replicating DNS records by using Active Directory-integrated DNS zones.
All of the records and zone data stored within the zone are replicated to other DNS servers by using the native AD DS replication service. Each DC stores a writable copy of the DNS zone data for namespaces for which they are authoritative. Active Directory-integrated zones also provide the ability to use secure dynamic updates, which supports controlling which computers may make updates and prevents unauthorized changes from being made.
DNS zone data is stored in an application directory partition. A forest-wide partition named ForestDnsZones is used for the zone data. For each AD DS domain, a domain partition is created named DomainDnsZones.
Typically, DNS implementations are used with a contiguous namespace.
For example, the Fully Qualified Domain Name (FQDN) of an AD DS domain might be corp.contoso.com, and the FQDN of a client in that domain would be client.corp.contoso.com. However, AD DS and Active Directory-integrated DNS zones support disjoint namespaces. In such a scenario, the FQDN of the AD DS domain might be na.corp.contoso.com, while a client FQDN could be client.corp.contoso.com. Notice that the “na” portion of the FQDN is not present in the client FQDN. There are several requirements and considerations when using a disjoint namespace.
For more information, see https://technet.microsoft.com/en-us/library/cc731125%28v=ws.10%29.aspx.
Three specific DNS components
AD DS requires DNS to function, and uses three specific components for the AD DS infrastructure:
- Domain controller locator.
The Locator is implemented in the Net Logon service and provides the names of DCs in an AD DS environment. The Locator uses address (A) and service (SRV) DNS resource records to identify DCs in an AD DS environment.
- Active Directory domain names in DNS.
The AD DS domain names in DNS are the FQDN that we discussed earlier.
- Active Directory DNS objects.
While DNS domains and AD DS domains typically have the same name, they are two separate objects with different roles. DNS stores zones and zone data required by AD DS and responds to DNS queries from clients. AD DS stores object names and object records and uses LDAP queries to retrieve or modify data. DNS zones that are stored in AD DS have a container object that is in the dnsZone class. The dnsZone object has a DNS node, which uses the dnsNode class. Each unique name in a DNS zone has a unique dnsNode object. For AD DS, this also includes individual functions. Therefore, one DC may have multiple roles, such as being a global catalog server, which is indicated in the dnsNode object.
DNS records in Active Directory
As mentioned earlier, DCs are identified by the SRV records in a DNS zone. Components of AD DS are stored in DNS using the following format in the _msdcs subdomain: _Service.Protocol.DcType._msdsc.DnsDomainName.
For example, the Lightweight Directory Access Protocol (LDAP) service of the Primary Domain Controller (PDC) in the contoso.com AD DS domain would be _ldap._tcp.pdc.contoso.com. The service and protocol strings use underscores (_) as a prefix to avoid potential collisions with existing resources or records in the namespace.
The Net Logon service requires 17 different SRV records to perform lookups. A full list of SRV records can be found at https://technet.microsoft.com/en-us/library/cc759550%28v=ws.10%29.aspx.
In addition to the SRV records, the Net Logon service also requires two A records for clients that may not be SRV-aware. This includes a record for the DnsDomainName, and a record for gc._msdsc.DnsForestName. This enables non-SRV-aware clients to look up a domain controller or global catalog server by using an A record.
Best practices
DNS is susceptible to security threats, such as foot printing, denial-of-service attacks, data modification, and redirection.
To mitigate these threats, DNS zones can be secured by using secure dynamic updates, restricting zone transfers, plus implementing zone delegation and DNS Security Extensions (DNSSEC). By using secure dynamic updates, computers will be authenticated through Active Directory, and security settings will be applied when performing a zone transfer.
Additionally, zone transfers can also be restricted to specific IP addresses within the network. Zone delegation can be approached by using two methods.
First, is to limit DNS changes to a single team or entity, with all changes tracked and approved. This method limits the amount of people making changes, but allows for a single point of failure.
Secondly, zones can be delegated to individuals who will be managing each component of a network or domain. While changes may still need to be approved and tracked, this spreads out risk among multiple people, and may limit damage if only one component becomes compromised.
DNSSEC
DNSSEC validates DNS responses by providing origin authority, data integrity, and authenticated denial of existence. Windows Server 2012’s implementation of DNSSEC meets the standards for RFC 4033, 4034, and 4035.
There are six resource record types that are used specifically with DNSSEC:
- Resource record signature (RRSIG)
- Next Secure (NSEC)
- Next Secure 3 (NSEC3)
- Next Secure 3 Parameter (NSEC3PARAM)
- DNS Key (DNSKEY)
- Delegation Signer (DS)
For more information on each of the record types and their use, see https://technet.microsoft.com/en-us/library/jj200221.aspx.
More information about Active Directory basisc you will find in our AD tutorial for begginners.
