3. Configuring DNS for AD
For many AD environments, Windows DNS is the DNS
of choice. Even if an alternative DNS service exists in the enterprise, a
Windows DNS server may be used to manage the Windows systems. This
discussion details configuring Windows DNS to support AD and
includes configuring AD Integrated Zones, configuring Dynamic DNS, and
using AD Application Partitions for DNS Zone information.
For a new AD domain to be created, DNS must be
available. (A server can be promoted to DC even if it cannot locate a
DNS server. However, its domain SRV and host record must be recorded in
DNS, and the DC must be able to locate its DNS server, or it will not be
able to function as a domain controller.) DNS requirements include the
following:
If the DC will be the first DC in the
root domain of the forest and the root domain is the first-level domain
(that is, it has no parent domain), then the DNS server can be created
at the same time as the domain is created, or a preexisting DNS server
can be used.
If the DC is not the first
DC in the root domain of the forest, or if the root domain is a child
domain of an existing domain, then DNS must be available.
Configuring DNS for AD requires attention to the
DC TCP/IP configuration and DNS server configuration You must configure
DNS information in the TCP/IP properties of each Windows DC (or Windows
server that is to become a DC), be able to configure domain records in
DNS (these records should be created automatically, but you must be able
to confirm that they are correctly configured and may need to manually
adjust them if automatic configuration fails), configure DNS delegation,
configure AD integrated DNS zones, and configure secure dynamic DNS.
The first step is correct configuration of the Windows server.
3.1. Configuring the server
In order for dynamic registration to occur, the
DC must have the location of its DNS server configured in its TCP/IP
properties. This configuration should be correct before the server is
promoted.If DNS is integrated with AD, only one DNS server's IP
address is necessary. Registration records will be replicated to other
AD integrated DNS servers automatically. If the domain records do not or
cannot be properly registered, you may need to do so manually. To do so
you will need to know what records for each DC should be in DNS. The
next section will address these issues.
|
When servers are promoted using the dcpromo
tool, the IP address of a relevant DNS server must be configured in the
server's TCP/IP records. The new DC's information can then be recorded
in DNS dynamically and can be replicated to other DNS servers. When DNS
is integrated with AD, zone information is replicated using AD. However,
when multiple DCs exist in the domain, unless they are properly
configured, it is possible for the phenomena of a DC island
to exist. That is, the DC is properly registering its DNS information
in DNS, but that information is not replicated to other DNS servers.
This can occur when
Windows 2000 DCs are part of the DC (in a 100% Windows Server 2003 DC domain this problem cannot occur). Multiple DCs in the forest root domain have the DNS service installed. The DC DNS server is a primary for the _msdcs.ForestDnsName domain. The DC DNS server is pointed to itself as the preferred or alternate DNS server.
When these circumstances occur, the DNS zone information on a DC may not have a CNAME record for dsaGUID._msdcs.ForestDnsDomain. This record is required for replication. For example, let's say that two DCs exist for the forest root domain nomoore.local:
DC1 and DC2. Let's also assume that each has the DNS service installed,
and each one points to itself as the DNS source. On each server, the
DNS records only include the dsaGUID._msdcs.nomoore.local
for itself. When there is an attempt to replicate from DC1 to DC2, DC1
will not find the dsaGUID record for DC2, and will not be able to
replicate.
To resolve the issue, a single DNS server in
the domain should be designated as the primary DNS server. All DCs
should point to this server as the source for DNS. In this example, if
DC1 is designated as the primary, DC2 should have the IP address of DC1
as its source for DNS and DC1 should point to itself. If additional DCs
are added to the domain, they should point to DC1 as the source of DNS.
The DCs can be configured with a secondary DNS server.
Another solution is to configure the primary
DNS services of a server before it is promoted to be a DC to point to a
DNS server that contains the domain controller locator CNAME record for dsaGuid._msdcs.ForestName.
Then, install the DNS service on the new DC and enable integrated AD
DNS. After replication has occurred, change the new DC to point to
itself as the primary or secondary DNS server. However, if there are IP
address changes to DCs in the root forest domain, you may need to point
all DCs to a single DNS server until these changes have replicated
before returning to this configuration.
|
3.2. Configuring domain records
When a DNS server that supports dynamic
registration is used to support AD, Windows Server 2003 and Windows 2000
DCs can automatically register all necessary host and SRV records with
DNS. It is not recommended that you manually configure DNS records for
DCs. However, if you must, you can locate the requirements by viewing a
properly registered domain, or by referring to the server documentation.
You should be aware that records for Windows Server 2003 DCs are
organized slightly differently than those for Windows Server 2000.
Dynamic registration occurs during the dcpromo
process, and again each time the DC reboots. However, you can also
request registration by using the ipconfig command ipconfig /registerDNS.
During dcpromo, a pop up indicates a successful attempt, and advises
you to refer to the logs where any problems will be recorded.
To view the newly created records, open and
expand the DNS zone records using the DNS console. Two zones are created
during the creation of a forest: the zone for the new domain (DNSDomainName) and the zone for the child domain (_msdcs.DNSDomainName). There are multiple containers in each zone. The pane on the left side of Figure 7-16 displays the expanded DNS structure for the forward lookup zones of the forest root domain nomoore.local.
(No reverse lookup zones are created by default. If you create
appropriate reverse lookup zones, PTR records can also be dynamically
registered.) The pane on the right side of Figure 2 shows the delegated zone record for the msdcs zone and displays its contents (the name of the name server that is authoritative for the delegated subdomain).
Refer to this figure as you explore Table 2 and 3. Table 1 lists and describes the types of SRV records that are created. Table 2 and 3
list and describe the DNS records that are created during this process.
In a production environment, additional sites may exist and, therefore,
one or more site-specific folders (in addition to the Default-First-Site-Name
folder) will also exist. The contents of their folders will be similar
to that described for the default site. The number of SRV records of the
same type in any one folder will depend on the number of DCs in the
domain or site. Also described in the table are the ForestDnsZones and DomainDnsZones containers. These containers provide host records for non-SRV-aware LDAP clients.
Table 2. Windows Server 2003 forward lookup zone DNS records (DNSDomainName)
| Folder | Record | Description |
|---|
| N/A | N/A | Contains all record types for this domain. |
| _msdcs.DNSDomainName | N/A | A Delegation record delegating authority for the _msdcs child domain to the zone _msdcs.domain.extension. |
| _sites.DNSDomainName | N/A | Contains site records for all sites. |
| Default-First-Site-Name. _sites.DNSDomainName | N/A | Contains site records for this default site. A similar container exists for each site. |
| _tcp. Default-First-Site-Name. _sites.DNSDomainName | N/A | Contains TCP records for services offered in this site. |
| _tcp. Default-First-Site-Name. _sites.DNSDomainName | _kerberos | Used by a client to locate a server running KDC services for domain DnsDomainName in the site Default-First-Site-Name. |
| _tcp. Default-First-Site-Name. _sites.DNSDomainName | _ldap | Used by clients to locate a server running LDAP service in the domain DNSDomainName in the site Default-First-Site-Name. |
| _tcp. Default-First-Site-Name. _sites.DNSForestName | _gc | Used by clients to locate a GC server for this domain. Only servers running LDAP and that are a GC for the forest DnsForestName will register here. |
| _tcp.DNSDomainName | N/A | Contains SRV records for each service in the domain that can be accessed via TCP. |
| _tcp.DNSForestName | _gc | Enables a client to locate a GC in DNSForestName. |
| _tcp.DNSDomainName | _kerberos | Used by clients to locate KDC in DNSDomainName. |
| _tcp.DNSDomainName | _kpasswd | Used by clients to locate the Kerberos Password Change server for the domain. (All Widows Server 2003 DCs offer this service.) |
| _tcp.DNSDomainName | _ldap | Used by clients to locate a LDAP server in the domain DNSDomainName. |
| _udp.DNSDomainName. | N/A | Contains SRV records for each service in the domain that can be accessed via UDP. |
| _udp.DNSDomainName. | _kerberos | Used by clients to locate KDC in DNSDomainName using UDP. |
| _udp.DNSDomainName. | _kpasswd | Used by clients to locate the Kerberos Password Change server for the domain using UDP. |
| DomainDNSZones | N/A | Contains information servers that store DNS records for this domain. |
| N/A | Host(A) | Provides a way for non-SRV-aware LDAP clients to find an LDAP server. |
| _sites.DomainDNSZones | N/A | Contains the folders for each site. |
| Default-First-Site-Name. _sites.DomainDNSZones | N/A | Contains TCP folder for the Default-First-Site-Name. |
| _tcp. Default-First-Site-Name. _sites.DomainDNSZones | N/A | Contains TCP records for this site (one for each DC). |
| _tcp. Default-First-Site-Name. _sites.DomainDNSZones | _ldap. | Used by clients to locate an LDAP server in site Default-First-Site-Name in DomainDNSZones. |
| _tcp.DomainDNSZones | N/A | Contains the TCP records for this site. |
| _tcp.DomainDNSZones | _ldap | Used by clients to locate LDAP server in DomainDNSZones. |
| ForestDnsZones | N/A | Contains information on each server that hosts forest records. |
| N/A | Host(A) | Provides a way for non-SRV aware LDAP clients to find an LDAP server. |
| Default-First-Site-Name. _sites. ForestDnsZones | N/A | Contains TCP folder for the Default-First-Site-Name. |
| _tcp.Default-First-Site-Name. _sites. ForestDnsZones | N/A | Contains TCP records for this site (one for each DC). |
| _tcp.Default-First-Site-Name. _sites. ForestDnsZones | _ldap | Used by clients to locate an LDAP server in site Default-First-Site-Name in ForestDnsZones. |
| _tcp.ForestDnsZones | N/A | Contains the TCP records for this site. |
| _tcp.ForestDnsZones | _ldap | Used by clients to locate an LDAP server in ForestDnsZones. |
| N/A | Start of Authority (SOA) | The FQDN of the authoritative server for this domain. |
| N/A | Name Server (NS) | The FQDN of every name server that hosts the zone records. |
| N/A | Host (A) | The computer and IP address for each computer in the domain. |
Table 3. Windows Server 2003 forward lookup zone DNS records (_msdcs.DNSDomanName)
| Folder | Record | Description |
|---|
| N/A | N/A | Only exists in for the root. |
| dc._msdcs. DNSDomainName | N/A | Contains site and TCP information for each site. |
| sites.dc.msdcs. DNSDomainName | N/A | Contains site information for all sites. By default, the first site (Default-First-Site-Name) records are included. These are defined below. A similar record structure is defined for each site. |
| Default-First-Site-Name. sites.dc.msdcs. DNSDomainName | N/A | Contains a _tcp subfolder. |
| _tcp.Default-First-Site-Name. sites.dc.msdcs.DNSDomainName | N/A | TCP-related site records |
| _tcp.Default-First-Site-Name. sites.dc.msdcs.DNSDomainName | _kerberos | Used by a client to locate a DC running the Windows Server 2003 KDC service for domain DNSDomainName in the site Default-First-Site-Name. |
| _tcp.Default-First-Site-Name. sites.dc.msdcs. DNSDomainName | _ldap | Used by a client to locate a server running LDAP in the Default-First-Site-Name site of the DNSDomainName. |
| _tcp.dc.msdcs.DNSDomainName | N/A | Contains TCP records for services provided by this forest. |
| _tcp.dc.msdcs.DNSDomainName | _kerberos | Used by a client to locate a DC running KDC service for domain DNSDomainName. |
| _tcp.dc.msdcs.DNSDomainName | _ldap | Used by a client to locate a DC running LDAP service for domain DNSDomainName. |
| Domains. _msdcs.DNSDomainName | N/A | Contains folders for each DC GUID. |
| dcGUID.domains. _msdcs.DNSDomainName | N/A | Contains protocol folders for this domain. |
| _tcp.domainGUID.domains. _msdcs.DNSDomainName | N/A | Contains TCP SRV records for this domain. |
| _tcp.doaminGUID.domains. _msdcs.DNSDomainName | _ldap. | Used by a client to locate a DC in the domain DNSDomainName on the basis of its GUID. (Usually only used when the domain name has been changed.) |
| gc._msdcs.DNSDomainName | N/A | Contains global catalog (GC) server information for all GCs in the forest. |
| sites.gc.msdcs.DNSDomainName | N/A | Contains site information for all sites. By default, the first site (Default-First-Site-Name) records are included. These are defined below. A similar record structure is defined for each site. |
| Default-First-Site-Name. sites.gc.msdcs.DNSDomainName | N/A | Contains a _tcp subfolder. |
| _tcp.Default-First-Site-Name. sites.gc.msdcs.DNSDomainName | N/A | TCP-related site records for GCs. |
| _tcp.Default-First-Site-Name. sites.gc.msdcs.DNSForestName | _ldap | Enables a client to locate a GC server for this forest located in this site. Only DCs acting as GCs for the forest names in DnsForestName register here. |
| _tcp.gc.msdcs.DNSDomainName | N/A | Contains TCP records for GC services provided by this forest. |
| _tcp.gc.msdcs.DNSDomainName | _ldap | Used
by a client to locate a GC server for this forest. Only DCs acting as
GCs for the forest names in DnsForestName register here. |
| _pdc.msdcs.DNSDomainName | N/A | Contains records for PDC emulators for the forest. |
| _tcp.pdc.msdcs.DNSDomainName | N/A | Contains TCP records for services provided by PDCs in this forest. |
| _tcp.pdc.msdcs.DNSDomainName | _ldap | Used by a client to locate the DC acting as the PDC emulator in the mixed-mode domain DNSDomainName. Only the PDC emulator of the domain registers this record at this location. |
| N/A | Name Server (NS) | The fully qualified domain name (FQDN) of every name server that hosts the zone records. |
| N/A | Alias (CNAME) | The GUID and FQDN for DCs in the domain. |
Note that the records are used to help locate
services and the domain controllers they reside on. Sites may include
member computers in this domain or users with accounts in this domain,
but may not include DCs for this domain. When this is the case, an SRV
record for the closest DC in the domain will be registered in DNS for
the site. The closest DC in the domain to a specific site is determined
by an examination of the replication cost matrix.
The replication cost matrix is just a way of comparing sites based on
the speed of the connection and the replication latency based on the
replication topology. You will recall that replication between sites is
based on the configuration of a site link, an object defined by
administrators to represent a path between two sites. One of the
properties of the site link is a cost that represents the speed of the
connection between the sites. The closest site to any domain is the one
whose access can be done at the least cost.
You should notice in Table 7-3
that many SRV records have the same purpose: the location of specific
services. Their duplication of records (located in different folders)
enables the lookup of services by different processes. For example,
during logon the NetLogon service attempts to find the KDC server in the
nearest site and appends site information to its query. Other processes
may attempt to use UDP instead of TCP. More information on the
algorithms clients use to select SRV resource records can be found in RFC 2782: A DNS RR for specifying the location of services (DNS SRV).
These SRV records are created for each domain in
the DNS zone that is authoritative for the domain. When your AD
infrastructure supports multiple domains, you must configure DNS to
support each of them. An organization's DNS infrastructure may consist
of multiple zones and multiple DNS servers, each of which support
different zones and different domains. You may need to configure DNS
domain delegation
in order to support a multiple domain forest infrastructure.
3.3. Configuring DNS delegation
If the parent zone will host the AD domain, the
records will reside there and there is no need for delegation. However,
if a unique zone is created to host the AD domain, then the DNS domain
must be delegated.
If the DNS domain is delegated, the DNS
infrastructure must have the DNS delegations necessary to enable name
resolution during domain controller location. A DNS delegation entry
must exist in the DNS zone that is the parent of the zone that will
support AD. These records are added by whoever administers the DNS
server hosting the parent zone.
To continue with our example, the domain nomoore.local
is the root domain in the forest. During its creation (that is, during
promotion using dcpromo for the first DC), DNS services were added to
the server and the zone information created for the zone. Figure 3 shows the zone information in the DNS console.
Let's create a new child domain that we'll call west.nomoore.local. The DNS domain records could be added to the chicago.local zone, or a second zone can be created. If the DNS records are added to the nomoore.local
zone, a DNS domain name record is created prior to running dcpromo. If a
second zone is desired, then a delegation record must be created in the
GV101 zone.
To create a delegation record, begin by opening
the DNS console. Right-click on the domain where the delegation record
should reside, in this case the nomoore.local domain. Select New Delegation and then click Next. Enter a name for the new domain, as shown in Figure 4.
Note that the FQDN of the domain is built in the uneditable text box
when the domain name is entered. In other words, you enter only the
domain name, not the FQDN of the new domain. Click Next.
Click the Add button and add a name server to
host the delegated zone and then click OK. If you use the browse
feature, when the server name is selected from the list provided, its IP
address is automatically added to the record. Repeat as necessary to
add additional name servers; when completed, click Next. Click Finish
and examine the entry in DNS as shown in Figure 5.
Note that the record created in the new delegated domain is of Name
Server type and includes the name of the server that will host DNS for
this zone. You can distinguish delegated domain records from domain by
the little certificate embedded in the domain folder.
3.4. Configuring AD-integrated DNS zones
Windows DNS servers can be configured to operate
in the traditional manner, requiring both primary and secondary DNS
servers whose zone file information is stored on the DNS server. The
Windows DNS server supports both SRV records and dynamic update.
However, when used in this manner, they do not support secure dynamic
updating.
Windows DNS can also store its data in the AD database. Each zone is stored in the AD container class dnsZone,
which contains a DNS node object for every unique name in the zone. In
this scenario, DNS data is replicated to all domain controllers in the
domain, unless AD application partitions have been configured for DNS
Zone information. Regardless, every domain controller that has DNS zone
information replicated to it has the potential to become a DNS server.
Traditional secondary DNS servers may be implemented and configured to
obtain zone information from the AD-integrated DNS server; however, in
many environments this is unnecessary. Traditionally, secondary DNS
servers are implemented to provide backup, redundancy, and load
balancing for zones. When DNS is AD integrated, multiple copies of the
zone information already exist, so separate standalone secondary DNS
servers are unnecessary. However, where multiple domains exist, or when
local DNS support is desired for sites that do not include DCs,
traditional secondary DNS servers may be implemented.
A Windows DNS server may be installed as an
AD-integrated DNS server, or modified after installation. The DNS server
service must be running on a DC to become integrated into AD.
To change the DNS server's status to
AD-integrated, begin by opening the Administrative Tools → DNS
Management console. Right-click on the domain and select Properties.
Click the Change button next to the Type: description. Click to select
"Store the zone in AD (available only if DNS server is a domain
controller)," as shown in Figure 6, then click OK. Finally, click OK to close the Properties pages.
3.5. Configuring and using secure dynamic DNS
Windows 2000, Windows Server 2003, and Windows
XP computers can register an IP address in a DNS server that supports
dynamic registration. This solves the problem created by DHCP whereby a
computer's IP address may change, thus requiring a change to DNS. When
DNS host records are manually configured, it may be difficult to keep up
with dynamically changing IP address. However, dynamic registration of
IP addresses creates another problem.
If rogue computers are assigned the same address
as an authorized computer, the rogue computer may register its
information in DNS, overwriting the name of the previous computer. Or,
if a rogue computer on the network is named the same as a legitimate
computer, it may register its name and IP address, thus effectively
changing the IP address for the registered computer and redirecting
traffic intended for the authorized computer to itself. If a rogue
computer can do this, it is a serious security issue because it creates
the potential for at least a denial-of-service attack, and at worst a
situation where sensitive data can be intercepted.
This problem can be mitigated if DNS is integrated with AD, by ensuring that only a secure
dynamic update is allowed. When a secure dynamic update is used, only
the registered host can change its registration information. To
configure secure dynamic updates, you must consider client DHCP
configuration, DHCP server configuration, and DC configuration.
Client configuration depends on the client's
operating system version. Only Windows XP Professional, Windows 2000,
and Windows Server 2003 can perform dynamic update. (By default, they
are configured to do so.) Earlier versions of Windows such as Windows NT
4.0 and Windows 98 use WINS for name resolution and cannot be
configured to dynamically update DNS. However, if these systems receive
their IP addresses from a Windows DHCP server, the DHCP server can be
configured to update DNS A (host) and PTR (pointer) records for them and
secure dynamic updates can occur.
To configure DHCP to register addresses for
clients, begin by clicking Start → Administrative Tools → DHCP to open
the DHCP console. Right-click the DHCP server to configure and select
Properties. Select the DNS tab. Select "Enable DNS dynamic updates
according to the settings below." Select "Always dynamically update DNS A
and PTR records," as shown in Figure 7. Click OK to close the Properties pages.
If multiple DHCP servers are used, you can run
into problems if the client obtains an address from a different DHCP
server. When the client first obtains and IP address, the DHCP server
registers the client information in DNS. Because it made the first
registration, this DHCP sever becomes the only one that can update the
client record. If a different DHCP server assigns the client an address
and attempts to update DNS, it fails. To allow all DHCP servers to
modify the client's address in DNS, make all DHCP servers members of the
DNSUpdateProxy Windows group.
To change Windows dynamic DNS to secure dynamic
DNS requires a single domain property change. Begin by clicking Start
and then click Administrative Tools. Click DNS to open the DNS console.
Right-click on the zone and select Properties. Select the General tab.
From the "Dynamic updates" drop-down list, select "Secure only," as
shown in Figure 8. Click OK to close the Properties pages.
