WHITE PAPER

Active Directory and Infoblox’s

DNS and DHCP Services
 Active Directory and Infoblox’s
DNS and DHCP Services

WHITE PAPER

1.0 Introduction
Active Directory is Microsoft’s current network directory offering, used mainly to provide authentication and
authorization services in an environment of computers running modern versions of the Windows operating
system. Active Directory stores authentication and authorization information in a distributed database hosted
on special servers called Domain Controllers. Access to this information is provided through the standard
LDAP and Kerberos protocols, as well as through some proprietary Microsoft protocols (to provide
backwards compatibility).

Active Directory divides users, computers and other network resources into several types of administrative
units. One of these administrative units is the domain. So that we don’t confuse this type of domain with the
related but distinct term in DNS, this paper will refer to these as Active Directory domains or AD domains. Each
Active Directory domain is served by one or more Domain Controllers.1

Active Directory domains are identified by names that consist of multiple labels separated by periods, just like
domain names in DNS. In fact, the names of Active Directory domains are also DNS domain names, since to
function properly,an AD domain requires that certain resource records be present at and below the
corresponding DNS domain name. For example, the AD domain domain.example requires the existence
of resource records attached to the DNS domain name domain.example, as well as many records in subdo-
mains of domain.example, as we’ll see.

These records are necessary mainly to allow computers that are members of an Active Directory domain to
locate the AD domain’s Domain Controllers. Unlike the directory technologies in Windows NT that preceded
AD, which used proprietary protocols such as WINS to locate services, Active Directory uses DNS as a location
broker. Domain Controllers can add records to DNS that direct member computers to the LDAP and Kerberos
servers within the AD domain.

Computers running modern Windows operating systems—namely Windows 2000, Windows XP and newer
Windows OSes—can also register themselves in DNS. They add records to DNS that map their names to their
addresses and their addresses back to names, a particularly handy capability in anetwork environment that
uses dynamic addressing. The names these computers register are usually related to the name of the AD
domain of which they’re members.

Given that Active Directory relies on DNS, Microsoft includes an implementation of a DNS server in its server
operating systems. Active Directory does not require the use of the Microsoft DNS Server, however; any DNS
server that supports a modest list of DNS RFCs can be used to provide the services that AD needs.

1
To be more precise, the authentication and authorization information about each AD domain is served by a set
of Domain Controllers.

1  © 2009 Infoblox Inc. All rights reserved. wp_dnsdhcp_ad_19feb09

 Active Directory and Infoblox’s
DNS and DHCP Services

WHITE PAPER

2.0 Dynamic Updates

Domain Controllers and other computers that are members of an Active Directory domain add the records that identify
themselves and the services they offer using DNS Dynamic Update, an extension to the original DNS specifications.
Dynamic update allows computers to automatically add resource records to and delete records from the DNS namespace.
For example, Domain Controllers send dynamic updates to add the records that enumerate the services they offer.
Computers running modern versions of Windows (Windows 2000 and newer) can send dynamic updates to register their
name-to-address and address-to-name mappings. Name-to-address mappings, also called forward mappings, are
registered by using dynamic update to add A records, while address-to-name mappings, also called reverse mappings,
are registered by adding PTR records.

To add a record to the DNS namespace, an updater must first decide which name server to send the update to. This
actually requires determining two pieces of information: Which zone in the namespace needs to be updated and which
name server is primary for that zone. DHCP servers based on ISC’s code require explicit configuration to tell them which
name server is primary for a given zone (though this configuration is automatic when the DHCP server sending updates
and the updated zone’s primary name server are part of an Infoblox grid). Windows DHCP clients and Microsoft DHCP
Servers, however, can discover which zone needs to be updated and which name server is primary for that zone.

The process used to determine this works as follows:

1. The updater (DHCP client or server) sends a recursive query for the SOA record attached to the domain name to
be updated. For example, if the DHCP client wants to register its address at the domain name host.domain.
example, it sends a query for the SOA record for host.domain.example.

2. The updater will usually receive a response indicating that no SOA record exists at that domain name2. This nega-
tive response, however, includes an SOA record for the zone that would have contained the record (had it existed).
The owner name of this SOA record (for example, domain.example) tells the updater which zone to update. The
MNAME of the SOA record tells the updater the domain name of the primary name server for the zone.

3. The updater sends an update to that primary name server, initially checking for the existence of the record it would
like to add to the zone. If the record exists, the process is complete.

4. If the record doesn’t exist, the updater sends another update to the primary name server, indicating which record to
add to the zone.3

If the primary name server isn’t available, a Windows updater will retry the update after five minutes. If this second
update fails, the updater will retry again after another 10 minutes. If this final update fails, the updater will wait 50 more
minutes, then begin the update process again.

2
Because only zones own SOA records, and the domain name of a host is rarely the domain name of a zone, too.
3
Consequently, publishing an SOA record with an MNAME field that does not accurately reflect the primary name
server for a zone will prevent Windows updaters from updating that zone.

© 2009 Infoblox Inc. All rights reserved. wp_dnsdhcp_ad_19feb09  2

© 2006 Infoblox Inc. All Rights Reserved. All trademarks property of their respective owners. wp_ad_19Jun06
 Active Directory and Infoblox’s
DNS and DHCP Services

WHITE PAPER

2.1 DYNAMIC UPDATE SECURITY

There are several methods for authenticating and authorizing dynamic updates. The simplest has the primary name
server that receives an update check the IP address from which the update was sent. The name server can allow updates
from certain IP addresses and deny all others. Unfortunately, this doesn’t provide adequate security for some environ-
ments, since dynamic updates are UDP-based, and spoofing the source IP address used in a UDP datagram is trivial.

Another method has the updater sign the update with a Transaction Signature (TSIG). As long as only the updater and
the name server receiving the update share a key, a correct TSIG record cryptographically proves the updater’s identity.
The name server can allow only updates signed by certain updaters.

Microsoft extended TSIG to let an updater and a name server in the same AD domain derive a key dynamically using the
AD domain’s Kerberos service. This variant of TSIG, called GSS-TSIG, lets any updater securely update any zone hosted
on a primary name server in the AD domain. Microsoft refers to updates signed by GSS-TSIG as Secure Dynamic Updates.

2.2 Resource Records Added by Domain Controllers

When initially promoted, and hourly thereafter, a Domain Controller will add a set of resource records to the DNS
namespace using standard dynamic updates. These resource records map the names of services within the AD
domain to the name of the Domain Controller and the ports on which the services are offered. Here’s an example
record for discussion:

owner name class type record-specific data (RDATA)

_ldap._tcp.domain.example. IN SRV 0 0 389 dc.domain.example.

While the syntax is a little obscure, the basic meaning of the record is this: “An instance of the LDAP
service for the AD domain domain.example is running on TCP port 389 of the host dc.domain.ex-
ample. The owner names (the left side; in this case, _ldap._tcp.domain.example) of all of the
records added by the Domain Controller end in the name of the AD forest.

A Domain Controller adds many other records, corresponding to the other services it offers and other
ways of identifying these services. The following table is a list of the owner names and types of these
records, along with a short description of the function of each.

Owner Name Record Description

Type
_ldap._tcp.ADDomainName SRV Identifies an LDAP server for the AD
domain
_ldap._tcp.Site._sites.ADDomainName SRV Identifies an LDAP server serving the
site Site for the AD domain
_ldap._tcp.dc._msdcs.ADDomainName SRV Identifies a Domain Controller for
the AD domain

3  © 2009 Infoblox Inc. All rights reserved. wp_dnsdhcp_ad_19feb09

 Active Directory and Infoblox’s
DNS and DHCP Services

WHITE PAPER
_ldap._tcp.Site._sites.dc._msdcs.ADDomainName SRV Identifies a Domain Controller
serving the site Site for the AD
domain
_ldap._tcp.pdc._msdcs.ADDomainName SRV Identifies the Primary Domain Control-
ler for the AD Domain
_ldap._tcp.gc._msdcs.ADForestName SRV. Identifies a Global Catalog server
for the AD Forest (not Domain)
_ldap.__tcp.Site._sites.gc._msdcs.ADForestName SRV Identifies a Global Catalog server
serving the site Site for the AD
Forest
_gc._tcp.ADForestName SRV Identifies a Global Catalog server
for the AD Domain
_gc._tcp.Site._sites.ADForestName SRV Identifies a Global Catalog server
serving the site Site for the AD
Domain
_ldap._tcp.DomainGUID.domains._msdcs.ADForestName SRV Identifies a DC with the GUID Domain-
GUID
_kerberos._tcp.ADDomainName SRV Identifies a Kerberos Key Distribution
Center (KDC) for the AD Domain
_kerberos._udp.ADDomainName SRV Identifies a Kerberos KDC for the AD
Domain
_kerberos._tcp.Site._sites.ADDomainName SRV Identifies a Kerberos KDC serving the
site Site for the AD Domain
_kerberos._tcp.dc._msdcs.ADDomainName SRV Identifies a Domain Controller running
a Kerberos KDC for the AD Domain
_kerberos._tcp.Site._sites.dc._msdcs.ADDomainName SRV Identifies a Domain Controller running
a Kerberos KDC serving the site Site
for the AD Domain
_kpasswd._tcp.ADDomainName SRV Identifies a Kerberos Password Change
server for the AD Domain
_kpasswd._udp.ADDomainName SRV Identifies a Kerberos Password Change
server for the AD Domain
ADDomainName A Identifies an LDAP server for the AD
Domain to legacy LDAP clients
gc._msdcs.ADForestName A Identifies a Global Catalog server for
the AD Forest to legacy LDAP clients
DSAGUID._msdcs.ADForestName CNAME Identifies a DC with the MSFT-DSA
GUID DSAGUID for the AD Forest

The presence and availability of these records in the DNS namespace is critical to the operation of Active Directory.
If these records are not added correctly or are not available, users in the AD domain may not be able to log in or
access the AD domain’s resources.

© 2009 Infoblox Inc. All rights reserved. wp_dnsdhcp_ad_19feb09  4

© 2006 Infoblox Inc. All Rights Reserved. All trademarks property of their respective owners. wp_ad_19Jun06
 Active Directory and Infoblox’s
DNS and DHCP Services

WHITE PAPER

2.3 The Relationship Between AD Domains and the DNS Namespace

All of the resource records in the previous section end in the name of the AD domain or the name of the AD forest.4
This suggests that, if a zone exists in the DNS namespace with the same name as the AD domain, the records will
be added to that zone. While this is generally the case, the rules that govern which zone or zones are updated are
actually slightly more complex.

To determine which zone in the DNS namespace a given resource record must be added to, examine the owner
name of the record in question.5 If the entire owner name (e.g., _ldap._tcp.domain.example) is the same
as the name of a zone, that zone must be updated. If the owner name isn’t the name of a zone, remove the first
label and first dot of the owner name (producing, in this example, _tcp.domain.example). If this is the same
as the name of a zone, that zone must be updated. If that name is not the same as the name of a zone, continue
removing leading labels and dots until the resulting name matches the name of an existing zone. If the process
doesn’t result in a match, the record falls into the root zone. If there’s no internal root zone in the DNS namespace,
the addition of the record will fail.

On networks served by Microsoft DNS Servers, it’s common for each AD domain to have a corresponding zone in
the DNS namespace, with exactly the same name. Sometimes the names of AD domainsare the same as the names
of zones in the organization’s “original” (i.e., pre-Active Directory) DNS namespace: For example, the name of
the company’s “apex” zone is corp.example, as is the name of the AD domain. In other cases, the organiza-
tion creates one or more subzones of the zones in their “original” namespace simply to contain records added by
Domain Controllers and records registered by computers in the AD domain. For example, the company’s “apex”
zone is corp.example, but the AD domain is called ad.corp.example.

Alternatively, on networks served by BIND or other non-Microsoft DNS servers, administrators sometimes create
several subzones of their company’s “apex” zone to contain just the records added by Domain Controllers. These
have the names:

• _msdcs.ADDomain
• _sites.ADDomain
• _tcp.ADDomain
• _udp.ADDomain

With Domain Controllers that run Windows 2003, this also includes the zones:

• DomainDNSZones.ADDomain
• ForestDNSZones.ADDomain

4
The name of the AD forest is often (but not necessarily) the same as or an ancestor of the AD domain’s name.
For example, an AD domain called corp.example might well be part of the corp.example forest.
5
The algorithm a Windows updater uses to determine which zone to update was described back in Section 2.0.
This process is offered here for the reader’s use, and should produce the same result.

5  © 2009 Infoblox Inc. All rights reserved. wp_dnsdhcp_ad_19feb09

 Active Directory and Infoblox’s
DNS and DHCP Services

WHITE PAPER

As the Domain Controllers’ update algorithm matches these “underscore zones” before the zone with the same
name as the AD domain, the underscore zones receive the updates rather than the apex zone. The administrator
can then deny updates to the apex zone (because allowing updates might present an unacceptable security risk)
while still allowing updates of the records required by Active Directory.6

2.4 Registration

Built into modern Windows operating systems is the ability to register their name-to-address and address-to-name
mappings by adding the necessary A and PTR records using dynamic update. In fact, Windows registers these
records by default.

In their default configurations, Windows servers (including Domain Controllers) and clients with statically defined
IP addresses will attempt to register both their forward (i.e., name-to-address) mappings and reverse (i.e., address-
to-name) mappings using dynamic update. Windows computers configured as DHCP clients, however, will only try
to register their forward mappings, by default. The DHCP server that issues a lease to the client is responsible for
registering that client’s reverse mapping.

This behavior can be modified through the use of the DHCP Client FQDN Option, Option 81.The DHCP server is
always responsible for updating a DHCP client’s reverse mapping, but the DHCP server may also assume respon-
sibility for updating the client’s forward mapping. A DHCP client can signal whether it intends to update its own A
record using a flag in Option 81. Its DHCP server may either grant the client’s preference or ignore it and perform
the update itself. The screen shot shown in Figure 1 shows where this is configured in Infoblox’s graphical user
interface. The radio buttons labeled DHCP server updates DNS only if requested by client and DHCP server always
updates DNS control the Infoblox DHCP server’s behavior.

Figure 1: Configuring Option 81 in the Infoblox GUI

6
Readers paying particularly careful attention may notice that one of the A records added by Domain Controllers
(attached to the owner name ADDomainName) doesn’t fall into any of these “underscore zones.” Microsoft has
assured us that the absence of this A record poses no operational problem to Active Directory, though Domain
Controllers will log their failures to update this record.

© 2009 Infoblox Inc. All rights reserved. wp_dnsdhcp_ad_19feb09  6

© 2006 Infoblox Inc. All Rights Reserved. All trademarks property of their respective owners. wp_ad_19Jun06
 Active Directory and Infoblox’s
DNS and DHCP Services

WHITE PAPER

Besides negotiating whether the DHCP client or server will register the client’s forward mapping, DHCP clients use
Option 81 to specify their fully qualified domain names. Similarly to the aforementioned flag, the DHCP server may
accept the fully qualified domain name from the client and use it in any forward and reverse mappings it registers on
the client’s behalf, or may ignore the client and register a (possibly different) fully qualified domain name for the client.7

A Windows computer specifies a fully qualified domain name that is the concatenation of its computer name and
its Primary DNS Suffix. On computers that are members of an Active Directory domain, the Primary DNS Suffix
defaults to the name of the AD domain.

Infoblox’s DHCP server, on the other hand, usually creates the client’s fully qualified domain name by appending
the domain name assigned to the client (in the DHCP Domain Name Option, Option 15) to the client’s hostname.
The hostname is usually derived from one of two DHCP options:

• The DHCP Client FQDN Option, Option 81: If the client sets this option, and the fully qualified domain name
the client specified contains a valid hostname as its first label, the DHCP server uses that label as the client’s
hostname.

• The DHCP Host Name Option, Option 12: If the client does not set Option 818, the DHCP server uses the value
of Option 12 as the client’s hostname.

However, if Infoblox’s DHCP server is configured to support Option 81 (see the earlier screenshot for the label
Enable Option 81 support), the server will use the fully qualified domain name specified by the DHCP client in any
updates that it performs.

Infoblox generally recommends the default configuration, in which the DHCP server assembles a client’s fully
qualified domain name and performs A and PTR updates on its behalf.

2.5 Name Collisions

Dynamic update security provides some assurance that unauthorized updaters can’t change zone data. Unfortu-
nately, this does not address the problem of an authorized updater accidentally overwriting records registered
on behalf of a DHCP client. For example, a DHCP server may add an A record on behalf of a client with the domain
name client1.domain.example. If the DHCP server later grants a different lease to a client that also claims
to have the hostname client1.domain.example, should it overwrite that A record? If it does, and the client
is actually a different computer, the original client1.domain.example will have lost its name-to-address
mapping. If the DHCP server refuses to overwrite the A record, and the client is really the same client1, after
moving onto a different subnet and receiving a new lease, the name-to-address mapping for client1.domain.
example will no longer be accurate.

7
Allowing a client to specify its fully qualified domain name can cause problems: A client may have its fully qual-
ified domain name set incorrectly, possibly by the client’s primary user. The administrator of the DHCP server is
less likely to specify the wrong domain name for the client.
8
Modern Windows clients—and even some older Windows clients, such as Windows 98—always set Option 81,
even when configured not to register in DNS.

7  © 2009 Infoblox Inc. All rights reserved. wp_dnsdhcp_ad_19feb09

 Active Directory and Infoblox’s
DNS and DHCP Services

WHITE PAPER

Infoblox DHCP servers support several methods to address this problem. The basicmethod is to add both an A
record and a TXT record to the client’s domain name when registering it. The A record, of course, is the client’s
name-to-address Infoblox DHCP servers support several methods to address this problem. The TXT record
includes a one-way hash of the client’s MAC address; it associates the client’s hardware identity with the
registered domain name.

Each time the DHCP server needs to register on behalf of a client, it sets a prerequisite on the update, effectively
saying, “Add this A record and this TXT record only if this domain name does not already own any A records.” If
there’s no A record attached to the domain name, there’s no name collision and the DHCP server is free to add the
records. However, if one or more A records exist, the DHCP server must be sure to delete the A records only if they
were added on behalf of the client it’s currently serving. To this end, it sends the same update with a different
prerequisite, saying, “Delete any old A records and add new records only if this domain name owns a TXT record
that shows that the client I’m serving is the same one the conflicting records were added for.” If the A record was
added on behalf of another DHCP client, or if the A record has no matching TXT record (for example, it’s an A record
that was added manually by an administrator), the update fails.

This method works well, except in cases where a client’s MAC address changes. Unfortunately, this is a common
occurrence on some networks, where notebook computers may connect to a wired Ethernet one minute and to
a wireless network the next. The Ethernet and wireless network interfaces have different MAC addresses, so the
DHCP server sees them as belonging to different computers.

Infoblox offers other, unique options to deal with this scenario, but each compromises some security. The most
useful option, configured with the setting Check Only (again, see Figure 1 in section 2.4), is very similar to the basic
method just described. The major difference is that only the existence of the TXT record is checked; the one-way
hash of the client’s MAC address is ignored. This means that when a DHCP client moves from a wired to a wireless
network, its DHCP server can overwrite its old A record. Unfortunately, it also implies that the DHCP server can
overwrite another DHCP client’s A record. It preserves the protection against overwriting manually added
records, however.

There’s one more issue related to roaming between networks (though unrelated to name collisions): When a
Windows DHCP client moves from a wirelessto a wired network (or back), it will often just renew its lease of an IP
address it previously used on the network. For example, a Windows client that switches from wireless to a wired
network may find that it last used the address 10.0.1.100 on the wired network interface. The client will try to
renew the lease of the address, saving it the trouble of starting the DHCP lease process from the beginning.

Unfortunately, most DHCP servers only update DNS on behalf of a client when a new lease is issued, not when a
lease is renewed. This can leave a client’s DNS records inconsistent with its current address: For example, though
the last records registered show an address on the wireless network, the client has since connected to the wired
network and renewed its lease there.

To deal with this situation, Infoblox DHCP servers can be configured to update a client’s DNS records when the
client renews a lease. While this increases the load on the name server processing the updates slightly, it helps
keep the namespace in step with the real state of the network.

© 2009 Infoblox Inc. All rights reserved. wp_dnsdhcp_ad_19feb09  8

© 2006 Infoblox Inc. All Rights Reserved. All trademarks property of their respective owners. wp_ad_19Jun06
 Active Directory and Infoblox’s
DNS and DHCP Services

WHITE PAPER

3.0 Architectural Decisions

Infoblox customers will likely have a number of choices in how to support their Active Directory deployments.
Some customers will continue to run Microsoft DNS Servers, for example, and these customers must decide
whether Microsoft DNS Servers, Infoblox name servers, or some combination of the two should act as authoritative
name servers for the zones critical to Active Directory. There are several possibilities, and advantages and
disadvantages to each.

One option is to migrate all AD-related zones to Infoblox name servers, and to either decommission the Microsoft
DNS Servers or use them solely as caching-only name servers. This solution offers a single, central point of
management for the entire DNS namespace and eliminates the need for administration of two sets of name servers.
(Caching-only name servers require almost no ongoing administration.) Infoblox DHCP servers can update clients’
A and PTR records securely, using TSIG-signed dynamic updates. Domain Controllers can be authorized to update
the zone corresponding to the AD domain, hosted on an Infoblox appliance, using GSS-TSIG—a capability most
BIND name servers lack.

The chief disadvantage of this solution is that only the primary name server for the AD zone (or zones) can process
dynamic updates. When configured to store a zone’s data in Active Directory’s database, any of the Microsoft DNS
Servers that are authoritative for that zone can process dynamic updates. This is referred to as a “multi-master”
configuration. However, this is often less of an advantage than it first appears: Updates are small (a single UDP
datagram) and usually sent very infrequently, from hourly (for Domain Controllers) to daily (for statically addressed
clients) or upon lease issuance. Consequently, updates constitute very little network traffic, so proximity to the
primary name server isn’t a major concern. If the primary is unavailable when an update is sent, the updater will
retry the update according to the algorithm described earlier (in Section 2.0). If there’s a critical need to ensure
that the primary is always available, a high availability pair can be used.

Another potential issue is distribution and survivability of name services. Some Infoblox customers use appliances
mainly in the core of their network, with Microsoft DNS Servers—often running on Domain Controllers—providing
local, recursive name service at the edge. Given the criticality of the data in the AD zone, they may require that the
data be distributed to all Microsoft DNS Servers so that computers at a site can locate a local Domain Controller
even if the site’s connection to the rest of the network is down.For these customers, there are two other options,
both of whichdistribute the AD zone to the Microsoft DNS Servers at the edge of the network.

The first leaves the AD zone on the Microsoft DNS Servers, integrated into Active Directory (that is, with zone data
stored in AD’s database). This configuration supports both multi-master dynamic updates and provides local
survivability, but requires the use of Microsoft’s DNS Console to manage the AD zone. If the zone is large (say most
of the company’s computers register in it), this could present a substantial disadvantage, as the DNS Console lacks
much of the functionality of Infoblox’s graphical user interface.

Breaking a single AD zone into a parent zone and underscore subzones may help reduce the drawbacks of this
option. Infoblox can manage the parent zone, which contains the bulk of the zone data, while the subzones are
delegated to the Microsoft DNS Servers, which contain the data clients need to locate Domain Controllers. The
subzones require very little maintenance, as Domain Controllers manage the zone entirely through dynamic update.
If this isn’t acceptable, an Infoblox name server (preferably a high availability pair) can act as the primary for the
AD zone, and the Microsoft DNS Servers can be configured as secondaries for the zone. This option provides local
survivability but doesn’t support multi-master dynamic updates.

9  © 2009 Infoblox Inc. All rights reserved. wp_dnsdhcp_ad_19feb09

 Active Directory and Infoblox’s
DNS and DHCP Services

WHITE PAPER

4.0 Aging and Scavenging

Windows clients—particularly notebooks—are often removed from networks abruptly. They may not have an oppor-
tunity to remove any resource records they may have registered. Consequently, these records can get stale, no
longer reflecting the true state of the network.

To cope with this problem, Microsoft implemented a mechanism in the Microsoft DNS Server called aging and scav-
enging.With aging and scavenging enabled, Microsoft DNS Servers mark each record added via dynamic update
with a timestamp showing the time of addition. Each time an updater tries to add the same record (e.g., the client
using an address sends its daily update to add the corresponding A record), the Microsoft DNS Server that receives
the update refreshes the timestamp with the current time.

If the Microsoft DNS Servers authoritative for a zone don’t see any refreshes to a dynamic record for a period of time
(by default, two weeks), they remove the record. This keeps dynamic data from becoming very stale (though obvi-
ously it allows it to become outdated).

For the most part, aging and scavenging isn’t necessary on a network served by Infoblox DHCP servers. If an
Infoblox DHCP server is configured to handle registering both A and PTR records on behalf of a client, it will auto-
matically remove the records upon expiration of the client’s lease, or if the client releases the lease.

If, however, a DHCP client is allowed to add its own A record, the Infoblox DHCP server won’t delete that record
upon lease expiration, and the record may become stale. Consequently, we recommend that the Infoblox DHCP
server assume the responsibility for adding both the A and PTR records for clients.

5.0 Active Directory Sites and Services

A single Active Directory domain may span an entire enterprise network, including many physical locations. To
help computers in the AD domain find the closest Domain Controllers, an administrator can use the Active Direc-
tory Sites and Services console to create sites and map subnets and Domain Controllers to these sites. Mapping
subnets to sites allows computers in the AD domain to determine which site they’re in. Once a computer has
discovered which site it’s in, it can send a DNS query to find out which Domain Controllers are closest to that site.

The mapping between subnets and sites is stored entirely within Active Directory’s database, not in DNS, and the
method member computers use to discover which site they’re part of doesn’t involve DNS, either. Basically, when a
member computer connects to a Domain Controller for authentication, the Domain Controller examines the comput-
er’s IP address and determines which site that IP address corresponds to. If the IP address belongs to a site the
Domain Controller serves, it fulfills the request. If the IP address belongs to a different site, the Domain
Controller replies with the name of the site the member is a part of. The member computer can then send a DNS
query to find a Domain Controller that serves that site. For example, a member of the AD domain domain.
example that finds it’s at the site Bayarea might look up SRV records for _kerberos._tcp.Bayarea._
sites.domain.example (as shown in Section 2.1) to find a Domain Controller. This is the only step of the
process that relies on DNS.

© 2009 Infoblox Inc. All rights reserved. wp_dnsdhcp_ad_19feb09

© 2006 Infoblox Inc. All Rights Reserved. All trademarks property of their respective owners. wp_ad_19Jun06

WHITE PAPER

For More Information:

+1.408.625.4200
1.866.463.6256
(toll-free, U.S. and Canada)
info@infoblox.com
www.infoblox.com

© 2009 Infoblox Inc. All rights reserved. wp_dnsdhcp_ad_19feb09