How DNS Support for Active Directory Works

Updated: March 28, 2003

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with
SP1, Windows Server 2003 with SP2, Windows Server 2008, Windows Server 2008 R2

How DNS Support for Active Directory Works

In this section

• DNS Support for Active Directory Architecture

• DNS Physical Structure in Support of Active Directory

• DNS Support for Active Directory Processes and Interactions

• Network Ports Used by DNS in Support of Active Directory

• Related Information

Active Directory uses DNS as its domain controller location mechanism and leverages the
namespace design of DNS in the design of Active Directory domain names. As a result, DNS
is positioned within the discoverability and logical structure components of Active Directory
technology components.

Typically, a Windows Server 2003 DNS namespace is deployed to mirror an Active Directory
forest and domain infrastructure. In such a deployment, a partition of the DNS namespace
is set aside for Active Directory, where a DNS domain name such as corp.contoso.com is
used support the Active Directory forest root domain, and then subdomains of this name are
created to suit additional Active Directory domains as needed.

DNS Support for Active Directory Architecture

Active Directory is dependent on DNS as a domain controller location mechanism and uses
DNS domain naming conventions in the architecture of Active Directory domains. There are
three components in the dependency of Active Directory on DNS:

• Domain controller locator (Locator)

• Active Directory domain names in DNS

• Active Directory DNS objects

DNS Support for Active Directory Components

Component Description

Domain The Windows Server 2003 domain controller locator, implemented in

controller the Net Logon service, enables a client to locate a domain controller.
 locator The component contains the DNS–compatible and the Windows NT
(Locator) 4.0–compatible locators that provide interoperability in a mixed
Windows Server 2003– and Windows NT 4.0–based environment.

Active Directory Every Windows Server 2003 Active Directory domain has a DNS
domain names domain name (for example, contoso.com), and every Windows
in DNS Server 2003–based computer has a DNS name (for example,
win2kserver.contoso.com). Architecturally, domains and computers
are represented both as objects in Active Directory and as nodes in
DNS.
Because DNS domains and Active Directory domains share identical
domain names, it is easy to confuse their roles. The two namespaces,
although typically sharing an identical domain structure, store
different data and, therefore, manage different objects:
• DNS stores zones and resource records, and Active Directory
stores domains and domain objects. Both systems use a
database to resolve names.

• DNS resolves domain names and computer names to

resource records through requests received by DNS servers
as DNS queries to the DNS database.

• Active Directory resolves domain object names to object

records through requests that are received by domain
controllers either as LDAP search requests or as modify
requests to the Active Directory database.

Thus, the Active Directory domain computer account object is in a

different namespace from the DNS host record that represents the
same computer in the DNS zone.

Active Directory When DNS data is stored in Active Directory, each DNS zone is an
DNS objects Active Directory container object (class dnsZone). The dnsZone
object contains a DNS node object (class dnsNode) for every unique
name within that zone. These unique names include the variations
assigned to a specific host computer when it functions, for example,
as a primary domain controller or as a global catalog server. The
dnsNode object has a dnsRecordmultivalue attribute that contains a
value for every resource record that is associated with an object’s
name.
For more information about Active Directory DNS objects, see How
DNS Works.
Active Directory and DNS Domain Names
Active Directory domains have two types of names: DNS names and NetBIOS names. In
general, both names are visible to end users. The DNS names of Active Directory domains
include two parts, a prefix and a suffix. The DNS prefix is the first label in the DNS name of
the domain. The suffix is the name of the Active Directory forest root domain.
When a Windows NT 4.0 master user domain (MUD) is upgraded, the decision is made
whether or not to use the current NetBIOS name of the domain as a DNS prefix. If the
name is appropriate to represent the organizational structure of the enterprise and satisfies
the prefix naming rules in the table below, the name is typically kept. In this case, the
NetBIOS name of the domain is the same as the DNS prefix of the domain.

Registered DNS Name Prefix Rules

Rule Explanation

Select a prefix that is not Avoid names such as a business line or operating
likely to become outdated. system that might change in the future. Geographical
names are recommended.

Select a prefix that includes A-Z, a-z, 0-9, and (-), but not entirely numeric.
Internet standard characters
only.

Include 15 characters or less If you choose a prefix length of 15 characters or less,

in the prefix. then the NetBIOS name is the same as the prefix.
If the current NetBIOS name of the domain is inappropriate to represent the organizational
structure of the enterprise or if the current name fails to satisfy the prefix naming rules, a
new prefix is used. In this case, the NetBIOS name of the domain will be different from the
DNS prefix of the domain.

For each new Active Directory domain, a prefix that is appropriate for the organizational
structure of the enterprise and that satisfies prefix naming rules is used. Typically, the
NetBIOS name of the domain will be the same as the name of the DNS prefix.

The Active Directory forest root domain is also the name of the Active Directory forest. The
forest root name is a DNS name that consists of a prefix and a suffix in the form of
prefix.suffix. For example, an organization might have the forest root name
corp.contoso.com. In this example, corp is the prefix and contoso.com is the suffix.

The suffix is selected from a list of existing DNS names on the network. For the prefix, a
new name that has not been used on the network previously is selected. By attaching a new
prefix to an existing suffix, a unique namespace is created. Creating a new namespace for
Active Directory ensures that any existing DNS infrastructure does not need to be modified
to accommodate Active Directory.

Typically, the DNS names that are used in the Active Directory namespace are registered
with an Internet authority. Only registered names are guaranteed to be globally unique. If
two organizations register the same DNS domain name, or if an organization merges with,
acquires, or is acquired by another company that uses the same DNS name, then the two
infrastructures cannot interact with one another.

Note

• Using unregistered suffixes is not recommended. Using single label names, such as
.local, is not supported.
DNS Physical Structure in Support of Active Directory
The physical structure of Active Directory information in DNS is represented in DNS zones
and resource records, which, in turn, are typically stored in Active Directory as Active
Directory–integrated DNS zones. The DNS zones that support Active Directory domains can
also be stored in standard, file-based, DNS zones. In addition, the DNS dynamic update
protocol is utilized by Active Directory in order to make the registration of domain controller
DNS resource records automatic.

The following diagram illustrates the physical storage of Active Directory domain information
in DNS zones hosted on domain controllers, and in standard DNS zones hosted on member
servers.

DNS Physical Structure in Support of Active Directory

The following table describes the physical components in the Active Directory/DNS physical
structure.

DNS Physical Structure in Support of Active Directory Components

Active
Directory/DNS
Physical Structure
Component Description

Active Directory/DNS The DNS server used to support Active Directory must support
physical structure the SRV resource record and, ideally, the DNS dynamic update
requirements protocol. If the DNS server does not support the DNS dynamic
update protocol, the SRV resource records required to locate
 Active Directory domain controllers can be added to DNS
manually.

_msdcs DNS The Microsoft-specific subdomain enables location of domain

subdomain controllers that have specific roles in the Active Directory
domain or forest. Resource records for the DNS root domain of
a new Active Directory forest are stored in a _msdcs zone
instead of a subdomain, and that zone is stored in the forest-
wide application directory partition.

Domain controller SRV There are multiple DNS SRV resource records registered on
resource records behalf of domain controllers. A description of each resource
registered in DNS record is below.

DNS application In Windows Server 2003, the Active Directory–integrated DNS

directory partitions zones that support Active Directory domains can be stored in
Active Directory application directory partitions, which is a new
feature of Windows Server 2003. By default, the DNS root
domain of a new Active Directory forest is stored in the
domain-wide application directory partition for the forest root
domain.
DNS Support for Active Directory Physical Structure Requirements
In order for a DNS server to be able to support Active Directory, the server is required to
support the service (SRV) resource record type and the dynamic update protocol, as
described in the RFC 2136. Active Directory uses DNS as the location mechanism for domain
controllers, enabling computers on the network to obtain IP addresses of domain
controllers. During the installation of Active Directory, the service (SRV) and address (A)
resource records are dynamically registered in DNS. Both types of records are necessary for
the functionality of the domain controller locator (Locator) mechanism.

To find domain controllers in a domain or forest, a client queries DNS for the SRV and A
DNS resource records of the domain controller. The resource records provide the client with
the names and IP addresses of the domain controllers. In this context, the SRV and A
resource records are referred to as Locator DNS resource records.

When a domain controller is added to a forest, a DNS zone hosted on a DNS server is
updated with the Locator DNS resource records for that domain controller. For this reason,
the DNS zone must allow dynamic updates (RFC 2136), and the DNS server hosting that
zone must support the SRV resource records (RFC 2782) to advertise the Active Directory
directory service.

At the very least, the DNS server must support the SRV resource record; but the SRV
resource records can be added to DNS manually. After installing Active Directory, these
records can be found on the domain controller in the following location:
systemroot\System32\Config\Netlogon.dns.

Note

• The configuration of reverse lookup zones is not based on the Windows Server 2003
domain structure; instead, it is based on the range of IP addresses assigned to a
company. If a company is assigned B class IP addresses such as 172.56.X.Y., then a
reverse lookup zone of 56.172.in-addr.arpa. will be created. It might contain
 delegations to some other domains such as 1.56.172.in-addr.arpa., 2.56.172.in-
addr.arpa., etc. It is also possible to configure classless reverse lookup zones as
described in the RFC Best Current Practice paper “Classless IN_ADDR.ARPA
delegation.”

_msdcs Subdomain
To facilitate locating Windows Server 2003–based domain controllers, in addition to the
standard _Service._Protocol.DnsDomainName format, the Net Logon service registers SRV
records that identify the well-known server-type pseudonyms “dc” (domain controller), gc
(global catalog), pdc (primary domain controller), and “domains” (globally unique identifier,
or GUID) as prefixes in the _msdcs subdomain. This Microsoft-specific subdomain enables
location of domain controllers that have Windows Server 2003–specific roles in the domain
or forest, as well as the location by GUID when a domain has been renamed. To
accommodate locating domain controllers by server type or by GUID (abbreviated
“dctype”), Windows Server 2003-based domain controllers register SRV records in the
following form:

_Service._Protocol.DcType._msdcs.DnsDomainName

Note

• There are also site–specific DNS resource records that use a slightly different format.
For more information about site discovery, see “Domain Controller Location in the
Closest Site” later in this document.

The subdomain _msdcs.DnsDomainName is used to find an LDAP server that is running TCP
and also functioning in a particular Windows Server role. The name _msdcsis reserved for
locating domain controllers and Kerberos servers. The single keyword _msdcswas chosen to
avoid cluttering the DNS namespace unnecessarily. Other constant, well-known names (pdc,
dc, and gc) were kept short to avoid exceeding the maximum length allowed for a DNS
name.

Domain Controller SRV Resource Records

When a Windows Server 2003–based domain controller starts up, the Net Logon service
uses dynamic updates to register SRV and A resource records in the DNS database, as
described in Internet Engineering Task Force (IETF) RFC 2782, “A DNS RR for specifying the
location of services (DNS SRV).” Windows Server 2003 also uses secure dynamic update
using the GSS-TSIG algorithm, as described in RFC 3645, “Generic Security Service
Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG).”

The SRV record is used to map the name of a service (in this case, the LDAP service) to the
DNS computer name of a server that offers that service. In a Windows Server 2003
network, an LDAP resource record locates a domain controller.

When a workstation logs on to a Windows Server 2003 domain, it queries DNS for SRV
records in this general form:

_Service._Protocol.DnsDomainName

Because Active Directory servers offer the LDAP service over the TCP protocol, clients find
an LDAP server by querying DNS for a record of the form:
_ldap._tcp.DnsDomainName

Note

• The service and protocol strings require an underscore (_) prefix to prevent potential
collisions with existing names in the namespace.

Active Directory site-specific resource records are also used during logon. For more
information, see “Domain Controller Location in the Closest Site” later in this document.

SRV Records Registered by Net Logon

The list in the following table provides the definitions of the names associated with
registered SRV records. It also describes the lookup criteria supported by each record and
the checks performed by Net Logon as each record is registered.

In the descriptions of registered SRV records, DnsDomainName refers to the DNS domain
name that is used during creation of the domain controller when the domain tree is joined
or created (that is, when the computer runs the Active Directory Installation Wizard).
DnsForestName refers to the DNS domain name of the forest root domain.

An owner name is the name of the DNS node to which a resource record pertains. These
resource records are used by domain controller Locator. The following table lists the owner
names of the SRV records that are registered by Net Logon.

SRV Records That Are Registered by Net Logon

SRV Resource Record Description

_ldap._tcp.DnsDomainName. Enables a client to locate a server that is

running the LDAP service in the domain
named DnsDomainName. The server is not
necessarily a domain controller — that is, the
only assumption that can be made about the
server is that it supports the LDAP
application programming interface (API). All
Windows Server 2003–based domain
controllers register this SRV record (for
example, _ldap._tcp.contoso.com.).

_ldap._tcp.SiteName. Enables a client to locate a server that is

_sites.DnsDomainName. running the LDAP service in the domain
named DnsDomainName in the site named
SiteName. SiteName is the relative
distinguished name of the site object that is
stored in the Configuration container in
Active Directory. All Windows Server 2003–
based domain controllers register this SRV
record (for example,
_ldap._tcp.charlotte._sites.contoso.com.).

_ldap._tcp.dc._msdcs.DnsDomainNa Enables a client to locate a domain controller

me.
_ldap._tcp.SiteName.
_sites.dc._msdcs.DnsDomainName.
_ldap._tcp.pdc._msdcs.DnsDomainNa
me.
_ldap._tcp.gc._msdcs.DnsForestName
. (gc) server for this forest. Only domain
_ldap._tcp.SiteName.
_sites.gc._msdcs.DnsForestName.
_gc._tcp.DnsForestName.
_gc._tcp.SiteName.
_sites.DnsForestName.
(dc) of the domain named DnsDomainName.
All Windows Server 2003–based domain
controllers register this SRV record.
Enables a client to locate a domain controller
for the domain named DnsDomainName and
in the site named SiteName. All Windows
Server 2003–based domain controllers
register this SRV record.
Enables a client to locate the server that is
acting as the primary domain controller
(PDC) in the mixed-mode domain named
DnsDomainName. Only the PDC emulator
master of the domain (the Windows
Server 2003–based domain controller that
advertises itself as the primary domain
controller to computers that need a primary
domain controller) registers this SRV record.
Enables a client to locate a global catalog
controllers that are functioning as gc servers
for the forest named in DnsForestName
register this SRV record (for example,
_ldap._tcp.gc._msdcs.contoso.com.).
Enables a client to locate a global catalog
(gc) server for this forest in the site named
in SiteName. Only domain controllers that
are serving as gc servers for the forest
named in DnsForestName register this SRV
record (for example,
_ldap._tcp.charlotte._sites.gc._msdcs.contos
o.com.).
Enables a client to locate a global catalog
(gc) server for this domain. The server is not
necessarily a domain controller. Only a
server that is running the LDAP service and
functioning as the GC server for the forest
named DnsForestName registers this SRV
record (for example, _gc._tcp.contoso.com.).
In Windows Server 2003, a GC server is a
domain controller. Other implementations of
directory services (that are not Windows
Server 2003 implementations) can also
register servers as GC servers.
Enables a client to locate a global catalog
(gc) server for this forest in the site named
SiteName. The server is not necessarily a
domain controller. Only a server that is
running the LDAP service and functioning as

_ldap._tcp.DomainGuid.
domains._msdcs.DnsForestName.
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName.
_kerberos._tcp.SiteName.
_sites.DnsDomainName.
_kerberos._tcp.dc._msdcs.DnsDomai
nName.
the GC server for the forest named
DnsForestName registers this SRV record
(for example,
_gc._tcp.charlotte._sites.contoso.com.).
Enables a client to locate a domain controller
in a domain on the basis of its GUID. A GUID
is a 128-bit number that is automatically
generated for referencing objects in Active
Directory — in this case, the domain object.
This operation is expected to be infrequent;
it occurs only when the DnsDomainName of
the domain has changed, the
DnsForestName is known, and
DnsForestName has not also been renamed
(for example, _ldap._tcp.4f904480-7c78-
11cf-b057-00aa006b4f8f.domains.
_msdcs.contoso.com.).
All domain controllers register this SRV
record.
Enables a client to locate a server that is
running the Kerberos KDC service for the
domain that is named in DnsDomainName.
The server is not necessarily a domain
controller. All Windows Server 2003–based
domain controllers that are running an
RFC 1510–compliant Kerberos KDC service
register this SRV record.
Same as _kerberos._tcp.DnsDomainName,
except that UDP is implied.
Enables a client to locate a server that is
running the Kerberos KDC service for the
domain that is named DnsDomainNameand
is also in the site named SiteName. The
server is not necessarily a domain controller.
All Windows Server 2003–based domain
controllers that are running an RFC 1510–
compliant Kerberos KDC service register this
SRV record.
Enables a client to locate a domain controller
that is running the Windows Server 2003
implementation of the Kerberos KDC service
for the domain named in DnsDomainName.
All Windows Server 2003–based domain
controllers that are running the KDC service
(that is, that implement a public key
extension to the Kerberos v5 protocol
Authentication Service Exchange
subprotocol) register this SRV record.
 _kerberos.tcp.SiteName.
_sites.dc._msdcs.DnsDomainName.
Enables a client to locate a domain controller
that is running the Windows Server 2003
implementation of the Kerberos KDC service
for the domain that is named
DnsDomainName and that is also in the site
named SiteName. All Windows Server 2003–
based domain controllers that are running
the KDC service (that is, that implement a
public key extension to the Kerberos v5
protocol Authentication Service Exchange
subprotocol) register this SRV record.

_kpasswd._tcp.DnsDomainName. Enables a client to locate a Kerberos

Password Change server for the domain. All
servers that provide the Kerberos Password
Change service (which includes all Windows
Server 2003–based domain controllers)
register this name. This server must at least
conform to the Kerberos Change Password
Protocol. (For more information about this
draft, see the Microsoft Platform SDK.) The
server is not necessarily a domain controller.
All Windows Server 2003–based domain
controllers that are running an RFC 1510–
compliant Kerberos KDC service register this
SRV record.

_kpasswd._udp.DnsDomainName. Same as _kpasswd._tcp.DnsDomainName,

except that UDP is implied.
In addition to the SRV records listed in the table above, Net Logon also registers a DNS alias
(CNAME) record for use by Active Directory replication, in the format:
DsaGuid._msdcs.DnsForestName. The Locator does not use this record. This record enables
a client to locate any domain controller in the forest by looking up an A record. The only
information that is known about the domain controller is the GUID of the directory system
agent (DSA) object for the domain controller and the name of the forest in which the
domain controller is located. This record is used to facilitate renaming a domain controller.

If multiple domain controllers have the same criteria, multiple records exist with the same
owner name. A client that is looking for a domain controller with specific criteria would
receive all the applicable records from the DNS server. The client would pick one of the
returned records to select a domain controller, as described in RFC 2782.

Other SRV Record Content

The following information is also included in an SRV record.

SRV
Record
Field Description

Priority The priority of the server. Clients attempt to contact the server with the
lowest priority.
 Weight A load-balancing mechanism that is used when selecting a target host
from those that have the same priority. Clients randomly choose SRV
records that specify target hosts to be contacted, with probability
proportional to the weight.

Port The port where the server is listening for this service.
number

Target The fully qualified domain name of the host computer.

The algorithm by which clients interpret and select among SRV resource records is defined
in RFC 2782, “A DNS RR for specifying the location of services (DNS SRV).”

Host Records for Non-SRV-Aware Clients

Net Logon registers the following DNS A records for the use of LDAP clients that do not
support DNS SRV records (that is, clients that are non-SRV-aware). Locator does not use
these records.

Host (A) Records Registered by Net Logon

Host (A) Resource Record Description

DnsDomainName. Enables a non-SRV-aware client to locate any domain

controller in the domain by looking up an A record. A
name in this form is returned to the LDAP client through
an LDAP referral. A non-SRV-aware client looks up the
name; an SRV-aware client looks up the appropriate SRV
resource record.

gc._msdcs.DnsForestName. Enables a non-SRV-aware client to locate any global

catalog server in the forest by looking up an A record. A
name in this form is returned to the LDAP client through
an LDAP referral. A non-SRV-aware client looks up this
name; an SRV-aware client looks up the appropriate SRV
resource record.
Example of Registered Resource Records
The following example illustrates the combined information that is contained in A resource
records and SRV resource records.

A domain controller named Phoenix in the domain contoso.com has an IP address of

157.55.81.157. It registers the following A records and SRV records with DNS:

Copy Code
phoenix.contoso.com A 157.55.81.157
_ldap._tcp.contoso.com SRV 0 0 389 phoenix.contoso.com
_kerberos._tcp.contoso.com SRV 0 0 88 phoenix.contoso.com
_ldap._tcp.dc._msdcs.contoso.com SRV 0 0 389 phoenix.contoso.com
_kerberos._tcp.dc._msdcs.contoso.com SRV 0 0 88 phoenix.contoso.com.
When the appropriate SRV records and A records are in place, a DNS query for
_ldap._tcp.dc._msdcs.contoso.com returns the names and addresses of all domain
controllers in the domain.
For more information about A records, SRV records, DNS, and dynamic updates, see “DNS
Protocol” and “DNS Physical Structure” in How DNS Works.

DNS Application Directory Partitions

DNS zones stored in Active Directory replicate to Active Directory domain controllers
according to different replication scopes. In Windows 2000 Server, a DNS zone stored in
Active Directory is replicated to all domain controllers in the Active Directory domain.
Windows Server 2003 has added application directory partitions, which enable the DNS zone
to be stored in different replication scopes. The following table describes all of the
replication scopes available to a DNS zone stored in Active Directory.

Windows Server 2003 Active Directory Storage Options

Active Directory
Storage Option Replication Scope

Domain partition Active Directory domain partition for each domain in the forest.
DNS zones stored in this partition are replicated to all domain
controllers in the domain. This is the only Active Directory storage
option for DNS zones that are replicated to domain controllers
running Windows 2000 Server.

Forest-wide DNS DNS application directory partition for the entire forest. DNS zones
application stored in this application directory partition are replicated to all DNS
directory partition servers running on domain controllers in the forest. This DNS
application directory partition is created when you install the DNS
Server service on the first Windows Server 2003 domain controller
in the forest.

Domain-wide DNS application directory partition for each domain in the forest.
DNS application DNS zones stored in this application directory partition are
directory partition replicated to all DNS servers running on domain controllers in the
domain. For the forest root domain, this DNS application directory
partition is created when you first install the DNS Server service on
a Windows Server 2003 domain controller in the forest.
For each new domain in the forest (child domain), this DNS
application directory partition is created when you first install the
DNS Server service on a Windows Server 2003 domain controller
for the new domain.

Custom DNS DNS application directory partition for any domain controller that is
application enlisted in its replication scope. This type of DNS application
directory partition directory partition does not exist by default and must be created.
DNS zones stored in this application directory partition are
replicated to all DNS servers running on domain controller that
enlist in the partition.
As stated earlier, the Locator DNS resource records for an Active Directory domain are
stored in the _msdcs.DnsDomainNamesubdomain for the Active Directory domain. In
Windows Server 2003, when the DNS root domain of a new Active Directory forest is
created on a Windows Server 2003 domain controller, a DNS zone is automatically created
for the _msdcs.DnsForestName and stored in the forest-wide DNS application directory
partition, which replicates to all Windows Server 2003 domain controllers in the forest
running the Windows Server 2003 DNS Server service.

Note

• DNS zones stored in application directory partitions cannot be accessed by Windows

2000 Server domain controllers.

DNS Support for Active Directory Processes and Interactions

When a Windows Server 2003 member server is promoted to an Active Directory domain
controller by installing Active Directory, the Net Logon service registers the DNS resource
records necessary for network hosts and services to be able to locate the domain controller
on the network. When network hosts and services attempt to perform an operation (such as
joining a domain, for example) that requires an Active Directory domain controller, the
Locator mechanism is used to locate the domain controller through DNS. The following table
describes the processes and interactions involved in the registration and location of domain
controllers in DNS.

Active Directory and DNS Processes and Interactions

Process or
Interaction Description

Domain controller The Net Logon service registers DNS resource records on behalf of
DNS name the Active Directory domain controller in the DNS zone with the
registration same name as the Active Directory domain hosted by the domain
controller.

DNS delegation, DNS delegation resource records are created in the zone that is a
forwarders parent of the zone supporting the Active Directory domain. The
delegation enables the DNS name of the domain controller to be
resolved downward from the root of the DNS hierarchy.
DNS forwarders are another DNS feature that enable domain
controller location, and are commonly used for an Active Directory
client in one domain to locate a domain controller in another
domain.

DNS domain Network hosts and services use the DNS Locator mechanism to
controller location locate domain controllers in the Active Directory forest.
Domain Controller Name Registration
Every Windows Server 2003–based domain controller registers two types of names at
startup:

• A DNS domain name with the DNS service (for example, noam.contoso.com).

• A NetBIOS name with Windows Internet Name Service (WINS) or another transport-
specific service (for example, noam).
When a user starts a computer and logs on to a domain, the computer must do one of two
things:

• If the name of the logon domain is a DNS name, the computer must query DNS to
find a domain controller with which to authenticate.

• If the name of the logon domain is a NetBIOS name, the computer must send a
mailslot message to find a domain controller for the specified domain.

After the computer has found a domain controller, the information is cached so that a new
query is not required for subsequent logon sessions.

DNS Domain Name Registration

Active Directory supports dynamic registration of domain controller addresses in DNS. After
Active Directory has been installed during domain controller creation, the Net Logon service
dynamically creates records in the DNS database that are used to locate the server.
Dynamic update (described in RFC 2136) is a recent addition to the DNS standard; this
addition to the standard defines a protocol for dynamically updating a DNS server with new
or changed resource record values. Before the advent of this new protocol, administrators
had to manually create the records that are stored on DNS servers. The implementation of
DNS server that is included with Windows Server 2003 supports dynamic updates, as does
the Berkeley Internet Name Domain (BIND) version 8.x implementation of DNS.

Note

• By default, the Windows Server 2003 DNS Server service running on a domain
controller is configured to accept secure dynamic update only.

Every Windows Server 2003–based domain controller dynamically registers SRV records in
DNS. The SRV records enable servers to be located by service type (for example, LDAP) and
protocol (for example, TCP). Because domain controllers are LDAP servers that
communicate over TCP, SRV records can be used to find the DNS computer names of
domain controllers. In addition to registering LDAP-specific SRV records, Net Logon also
registers Kerberos v5 authentication protocol–specific SRV records to enable locating
servers that run the Kerberos Key Distribution Center (KDC) service.

Every Windows Server 2003–based domain controller also dynamically registers a single
host (A) resource record that contains the name of the domain (DnsDomainName) where
the domain controller is and the IP address of the domain controller. The host (A) resource
record makes it possible for clients that do not recognize service (SRV) resource records to
locate a domain controller by means of a generic host lookup.

NetBIOS Domain Name Registration

A domain controller registers its NetBIOS name (DomainName[1C]) by broadcasting or
directing a NetBIOS name registration request to a NetBIOS name server, such as a WINS
server. Registering the NetBIOS name makes it possible for Windows-based clients that are
not DNS-enabled to find the domain controllers that are running Windows Server 2003,
Windows 2000, Windows NT 4.0, or Windows NT 3.51. In this case, the client finds the
domain controller by sending a Net Logon mailslot request that is based on the NetBIOS
domain name.
Note

• NetBIOS recognizes domain controllers by the [1C] registration.

DNS Delegation, Forwarders

To fully support an Active Directory domain, the DNS infrastructure must have the DNS
delegations that are necessary to enable name resolution during domain controller location.
When an Active Directory domain is created, a DNS delegation entry must exist in the DNS
zone that is the parent of the zone supporting the Active Directory domain. The delegation
enables the name of the domain controller hosting the domain to be resolved by any host or
service in the DNS namespace. The delegation resource records must be added by the
network administrator who administers the DNS server hosting the parent zone. Alternately,
the parent zone could host the DNS resource records for the domain name and, in this case,
the delegation is unnecessary.

For example, if there is a DNS zone supporting the domain corp.contoso.com, then a
delegation for this name must exist in the parent zone contoso.com. When a DNS query for
the name is sent to the root of the DNS namespace, delegations can be followed until the
DNS server hosting the zone for corp.contoso.com is identified. Without this delegation, only
those network hosts and services configured with the IP address of the DNS server hosting
the zone for corp.contoso.com will be able to resolve its DNS name. All other network hosts
and services will be unable to resolve the name, and the domain controller will not be
available to them for such Active Directory operations as joining a domain, logging on to a
domain, or searching Active Directory.

When the Active Directory domain name is specified in the Active Directory Installation
Wizard, the wizard reads the delegation entry in DNS, prompts the user to install the DNS
Server service locally and configures the corresponding DNS zone automatically. Also, if the
computer is already configured with a preferred DNS server, the wizard will configure a
forwarder on the DNS Server service with the IP address of the prior preferred DNS server.

Forwarders are also commonly configured on the DNS server hosting a zone in support of an
Active Directory domain. Forwarders are used by a DNS server to forward queries for a
domain name about which it has no local data. If an Active Directory client in one domain
needs to access a resource in another Active Directory domain, it will need to locate a
domain controller in that domain. If the DNS server used by that client is unable to locate a
domain controller for the other domain using its local data, it can forward the client request
to another DNS server, such as the DNS server that hosts the zone for the Active Directory
forest root domain.

In summary, delegation enables name resolution in a descending direction from the root of
the hierarchy, and forwarders enable name resolution in a ascending direction toward the
root of the hierarchy.

Windows Server 2003 introduces an enhancement to forwarding called conditional

forwarders. When you use conditional forwarding, you can configure your DNS servers to
forward queries to different servers based on the domain name specified in the query. This
eliminates steps in the standard forwarding chain and reduces network traffic. When
conditional forwarding is applied, the DNS server hosting a zone in support of the one Active
Directory domain can forward queries to DNS servers hosting zones in support of the Active
Directory domain name specified in the client query.
Although root hints (resource records that list the DNS servers hosting the DNS root zone)
can also be used to facilitate domain controller location in place of forwarders, DNS
deployments commonly use forwarders for remote domain controller location to reduce the
complexity of administering root hints for both internal and Internet resolution.

For more information about delegation, forwarders, and root hints, see “How DNS Works.”

Domain Controller Locator

The domain controller locator (Locator) algorithm consists of two main parts:

• Locator finds which domain controllers are registered with a DNS server.

• Locator submits a DNS query to the DNS server to locate a domain controller in the
specified domain.

After this query is resolved, an LDAP User Datagram Protocol (UDP) lookup is sent to one or
more of the domain controllers listed in the response to the DNS query to ensure their
availability. Finally, the Net Logon service caches the discovered domain controller to aid in
resolving future requests.

Domain Controller Locator Process

Each Windows Server 2003–based domain controller registers its DNS domain name on the
DNS server and registers its NetBIOS name by using a transport-specific mechanism (for
example, WINS). Thus, a DNS client locates a domain controller by querying DNS, and a
NetBIOS client locates a domain controller by querying the appropriate transport-specific
name service. Because the code for the DNS-compatible Locator and the Windows NT 4.0–
compatible Locator is shared, both DNS clients and NetBIOS clients are supported.

The process that the Locator follows can be summarized as follows:

1. On the client (the computer that is locating the domain controller), the Locator is
initiated as a remote procedure call (RPC) to the local Net Logon service. The Locator
API (DsGetDcName) is implemented by the Net Logon service.

2. The client collects the information that is needed to select a domain controller and
passes the information to the Net Logon service by using the DsGetDcName API.

3. The Net Logon service on the client uses the collected information to look up a
domain controller for the specified domain in one of two ways:

• For a DNS name, Net Logon queries DNS by using the DNS-compatible
Locator — that is, DsGetDcName calls DnsQuery to read the SRV records and
A records from DNS after it appends an appropriate string to the front of the
domain name that specifies the SRV record.

• For a single label name, Net Logon performs domain controller discovery by
using the Windows NT 4.0–compatible Locator — that is, by using the
 transport-specific mechanism (for example, WINS).

Note

In Windows NT 4.0 and earlier, “discovery” is a process for locating a domain controllerfor
authentication in either the primary domain or a trusted domain.

1. The Net Logon service sends a datagram to the discovered domain controllers that
register the name. For NetBIOS domain names, the datagram is implemented as a
mailslot message. For DNS domain names, the datagram is implemented as an LDAP
UDP search.

2. Each available domain controller responds to the datagram to indicate that it is

currently operational and then returns the information to DsGetDcName.

3. The Net Logon service returns the information to the client from the domain
controller that responds first.

4. The Net Logon service caches the domain controller information so that it is not
necessary to repeat the discovery process for subsequent requests. Caching this
information encourages the consistent use of the same domain controller and, thus,
a consistent view of Active Directory.

Domain Controller Location in the Closest Site

During a search for a domain controller, the Locator attempts to find a domain controller in
the site closest to the client. When the domain that is being sought is a Windows
Server 2003 domain, the domain controller uses the information stored in Active Directory
to determine the closest site. When the domain being sought is a Windows NT 4.0 domain,
domain controller discovery occurs when the client starts and uses the first domain
controller that it finds.

Each Windows Server 2003–based domain controller registers DNS records that indicate the
site where the domain controller is located. The site name (the relative distinguished name
of the site object in Active Directory) is registered in several records so that the various
roles the domain controller might perform (for example, global catalog server or Kerberos
server) can be associated with the domain controller’s site. When DNS is used, the Locator
searches first for a site-specific DNS record before it begins to search for a DNS record that
is not site-specific (thereby preferentially locating a domain controller in that site).

A client computer stores its own site information in the registry, but the computer is not
necessarily located physically in the site associated with its IP address. For example, a
portable computer that was moved to a new location could contact a domain controller in its
home site, which is not the site to which the computer is currently connected. In this
situation, the domain controller looks up the client site on the basis of the client IP address
by comparing the address to the sites that are identified in Active Directory, and then
returns the name of the site that is closest to the client. The client then updates the
information in the registry.
The domain controller stores site information for the entire forest in the Configuration
container. The domain controller uses the site information to check the IP address of the
client computer against the list of subnets in the forest. In this way, the domain controller
ascertains the name of the site in which the client is assumed to be located, or the site that
is the closest match, and returns this information to the client.

Active Directory Site and Subnet Objects

A site is a collection of subnets that have high-speed connections. In Active Directory, a site
is defined by a site object in the cn=Sites,cn=Configuration,dc=ForestRootDomaincontainer.
A subnet is an addressed segment within a site and is represented by an object in the
cn=Subnets,cn=Sites,cn=Configuration,dc=ForestRootDomain container.

The site in which a domain controller is located is identified in the Configuration container by
the domain controller object that is located within the cn=Servers container beneath the
site object for a particular site. A domain controller can identify the site of a client by using
the subnet object in the Sites container. Each subnet object has a siteObject property
(“attribute”) that links it to a site object; the value of the siteObject property is the
distinguished name of the site object. This link enables a domain controller to identify
clients that have an IP address in the specified subnet as being in the specified site.

Subnet names in Active Directory take the form “network/bits masked” (for example, the
subnet object 172.16.72.0/22 has a subnet of 172.16.72.0 and a 22-bit subnet mask). If
this subnet had a siteObject property value that contained the distinguished name of the
Seattle site object, all IP addresses in the 172.16.72.0/22 subnet would be considered to be
in the Seattle site. The siteObject property is a single value, which implies that a single
subnet maps to a single site. However, multiple subnet objects can be linked to the same
site object. The directory administrator manually creates subnet objects and, hence, the
siteObject property value.

The Configuration container (including all of the site and subnet objects in it) is replicated to
all domain controllers in the forest. Therefore, any domain controller in the forest can
identify the site in which a client is located, compare it to the site in which the domain
controller is located, and indicate to the client whether that domain controller’s site is the
closest site to the client.

For more information about networks, subnets, and subnet masks, see “How TCP/IP
Works.”

IP Addresses Mapped to Site Names

During Net Logon startup, the Net Logon service on each domain controller enumerates the
site objects in the Configuration container. Net Logon on each domain controller is also
notified of any changes made to the site objects. Net Logon uses the site information to
build an in-memory structure that is used to map IP addresses to site names.

When a client that is searching for a domain controller receives the list of domain controller
IP addresses from DNS, the client begins querying the domain controllers in turn to find out
which domain controller is available and appropriate. Active Directory intercepts the query,
which contains the IP address of the client, and passes it to Net Logon on the domain
controller. Net Logon looks up the client IP address in its subnet-to-site mapping table by
finding the subnet object that most closely matches the client IP address and then returns
the following information:
 • The name of the site in which the client is located, or the site that most closely
matches the client IP address.

• The name of the site in which the current domain controller is located.

• A bit that indicates whether the found domain controller is located (bit is set) or not
located (bit is not set) in the site closest to the client.

The domain controller returns the information to the client. The response also contains
various other pieces of information that describe the domain controller.

The client inspects the information to determine whether to try to find a better domain
controller. The decision is made as follows:

• If the returned domain controller is in the closest site (the returned bit is set), the
client uses that domain controller.

• If the client has already tried to find a domain controller in the site in which the
domain controller claims the client is located, the client uses that domain controller.

• If the domain controller is not in the closest site, the client updates its site
information and sends a new DNS query to find a new domain controller in the site.
If the second query is successful, the client uses the new domain controller. If the
second query fails, the client uses the original domain controller.

• If the domain that is being queried by a computer is the same as the domain to
which the computer is joined, the site in which the computer resides (as reported by
a domain controller) is stored in the computer registry. The client stores this site
name in the DynamicSiteName registry entry in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters.
Therefore, the DsGetSiteName API returns the site in which the computer is located.

You can override the dynamically determined value using the registry, but you should never
change dynamically determined values. To override the dynamic site name, add the
SiteName entry with the REG_SZ data type in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. When a
value is present for the SiteName entry, the DynamicSiteName entry is not used.

Note

• Editing the registry directly can have serious, unexpected consequences that can
prevent the system from starting and require that you reinstall Windows
Server 2003. There are programs available in Control Panel or Microsoft Management
Console (MMC) for performing most administrative tasks. These programs provide
 safeguards that prevent you from entering conflicting settings or settings that are
likely to degrade performance or damage your system. Registry editors bypass the
standard safeguards that are provided by these administrative tools. Modifying the
registry is recommended only when no administrative tool is available. Before you
make changes to the registry, it is recommended that you back up any valuable data
on the computer. For instructions about how to edit registry entries, see Help for the
registry editor that you are using.

If the domain being located is the same as the domain to which the computer is joined and
the computer has not physically moved to a different site since the last query, the
dynamically determined site name in the registry is the actual site in which the computer is
located. Thus, the client finds a domain controller in the correct site without having to retry
the operation. On the other hand, if the site name in the registry is not the current site of
the computer (for example, if the computer is portable), the domain controller location
process serves to update the site information in the registry.

Automatic Site Coverage

There is not necessarily a domain controller in every site. For various reasons, it is possible
that no domain controller exists for a particular domain at the local site. By default, each
domain controller checks all sites in the forest and then checks the replication cost matrix. A
domain controller advertises itself (registers a site-related SRV record in DNS) in any site
that does not have a domain controller for that domain and for which its site has the lowest-
cost connections. This process ensures that every site has a domain controller that is
defined by default for every domain in the forest, even if a site does not contain a domain
controller for that domain. The domain controllers that are published in DNS are those from
the closest site (as defined by the replication topology).

For example, given one domain and three sites, a domain controller for that domain might
be located in two of the sites, but there might be no domain controller for the domain in the
third site. Replication to the domain that does not have a domain controller in the third site
might be too expensive in terms of cost or replication latency. To ensure that a domain
controller can be located in the site closest to a client computer, if not the same site,
Windows Server 2003 automatically attempts to register a domain controller in every site.
The algorithm that is used to accomplish automatic site coverage determines how one site
can cover another site when no domain controller exists in the second site.

Determining Site Coverage on the Basis of Site-link Cost

Site coverage is determined according to site-link costs, and domain controllers register
themselves in sites accordingly. For example, given one domain and sites A, B, and C, site A
has no domain controllers for the domain. If a client in site A attempts to locate a domain
controller, which domain controller should be returned? The answer depends on which site
covers site A for the domain.

In the example, a site link exists between site A and both of the other sites — that is, the
connections between domain controllers in site A, site B, and site C are configured for
replication over site links in Active Directory Sites and Services. Costs are associated with
site links based on the expense of transferring data over the connections. The administrator
uses the speed of the connection between sites to assign a cost to the communication link,
and replication uses the cost to establish the least expensive route for replication traffic.
Site A and site B are connected by site link AB. Site A and site C are connected by site
link AC, with the following costs:

Site link AB cost = 50.

Site link AC cost = 100.

The link between site A and site C has a much higher cost than the link between site A and
site B. The administrator configured this cost based on the expensive Integrated Services
Digital Network (ISDN) line that connects site A and site C, and the administrator would
prefer that resources in site B be used when possible. The site coverage algorithm
(described in the next sub-section) ensures that a domain controller in site B registers itself
as a domain controller for site A. In this way, clients in Site A that are looking for a domain
controller find one from site B, instead of possibly finding one from site C.

Site Coverage Algorithm

During registration of SRV records in DNS, the following algorithm determines if the domain
controllers should register site SRV records to designate themselves as preferred domain
controllers in Active Directory sites where no domain controller exists for a particular
domain.

For every domain controller in the forest, this procedure is followed:

• Build a list of target sites — sites that have no domain controllers for this domain
(the domain of the current domain controller).

• Build a list of candidate sites — sites that have domain controllers for this domain.

• For every target site, follow these steps:

1. Build a list of candidate sites of which this domain is a member. (If none, do
nothing.)

2. Of these, build a list of sites that have the lowest site link cost to the target
site. (If none, do nothing.)

3. If more than one, break ties (reduce this list to one candidate site) by
choosing the site with the largest number of domain controllers.

4. If more than one, break ties by choosing the site that is first alphabetically.

5. Register target-site-specific SRV records for the domain controllers for this
domain in the selected site.

Cache Time-out and Closest Site

If a domain member computer requests a domain controller while all domain controllers in
its site are offline, the Locator necessarily returns a domain controller in a different site. The
location of this domain controller is stored in the client cache. The cache lifetime is
controlled by the CloseSiteTimeout entry in the registry.

In addition, the domain controller performs authentication, and a secure channel is set up.
On subsequent location attempts, the lifetime of the cache and the lifetime of the secure
channel are secondary to the location of a domain controller in the closest site.

If the domain controller that is stored in the client cache is not in a site that is close to the
client, Net Logon attempts to find a close domain controller when either of the following
events occurs:

• An interactive logon process uses pass-through authentication on the secure

channel.

• The value in the CloseSiteTimeout registry entry has elapsed since the last attempt,
and any other attempt is made to use the secure channel (for example, pass-through
authentication of network logons).

Thus, Net Logon attempts to find a close domain controller only on demand. The default
value of the CloseSiteTimeout period is 15 minutes; the maximum value is 49 days; the
minimum value is 60 seconds. The implications of these settings are:

• If the time-out value is too large, a client never tries to find a close domain controller
if there is not one available at startup.

• If the time-out value is too small, secure channel traffic is unnecessarily slowed
down by discovery attempts.

Clients with No Apparent Site

Sometimes the client pings a domain controller and the client IP address cannot be found in
the subnet-to-site mapping table. In this case, the domain controller returns a NULL site
name, and the client uses the returned domain controller.

Types of Locators
On the basis of parameters passed to Net Logon in the DsGetDcName API, the process of
locating a domain controller proceeds in one of two ways:

• The DNS-compatible Locator is used if the domain name passed to DsGetDcName is

a DNS-compatible name. The Net Logon service on the client looks up the name in
DNS (by calling DnsQuery) after it appends an appropriate string to the front of the
domain name. The DNS service supports a query for determining the set of domain
controllers. If the client site name is known, the client DNS query specifies the site.
DNS returns the IP addresses of domain controllers that match the DNS query. The
client Net Logon service sends an LDAP UDP message to one or more of the domain
controllers that have been returned by DNS in order to determine whether any of the
specified domain controllers are running and support the specified domain.
 • The Windows NT 4.0–compatible Locator is used if the domain name passed to
DsGetDcName is a NetBIOS name. The Net Logon service on the client sends a
transport-specific logon request query to locate a domain controller in a particular
domain and then sends a mailslot message to one or more of the domain controllers
to determine whether any of the domain controllers it found are running and support
the specified domain.

DNS Client Service Configuration Elements

The DNS configuration on Active Directory client computers follows a specific computer
naming scheme and specifies how these clients will locate DNS servers. The following
table lists the configurations for DNS configuration elements.

DNS Configuration for Client Computers

DNS
Configuration
Element Configuration

Computer naming Use default naming. When a Windows 2000, Windows XP, or
Windows Server 2003 computer joins a domain, the computer
assigns itself a primary DNS name comprised of the host name of
the computer and the name of the domain.

Client resolver Configure client computers to point to any DNS server on the
configuration network.
Note

• Active Directory clients and domain controllers can dynamically register their DNS
names using a DNS server that is not authoritative for the DNS name of the Active
Directory domain. The DNS server used by these clients will refer the registration to
the DNS server that is authoritative for the name of the Active Directory domain.

A computer might have an existing DNS name if the organization previously statically
registered the computer in DNS or the organization previously deployed an integrated DHCP
solution. If client computers already have a registered DNS name, when the domain to
which they are joined is upgraded to Windows Server 2003 Active Directory, the client
computers will have two names: the existing DNS name, and the new primary name.

Clients can be located by either name. Any existing DNS, DHCP, or integrated DNS/DHCP
solution is left intact. The new primary names are created automatically and updated by
means of dynamic update. The old names are cleaned up automatically by means of DNS
scavenging.

To take advantage of Kerberos authentication when connecting to a server running Windows

2000, Windows XP, or Windows Server 2003, the client must connect to the server by using
the primary name.

Network Ports Used by DNS in Support of Active Directory

The network ports used by DNS are documented in the DNS Technical Reference. For more
information, see “Network Ports used by DNS” in How DNS Works.

Related Information
The following resource contains additional information that is relevant to this section.

• How DNS Works

• Home
• General DNS Records Explained with Examples
• Comma
nds ADD TO:
• Backup
• Packag Blink
e
Admin Del.icio.us
• Networ
k
• Webser Digg
ver
• Securit Furl
y
• Free Google
Tools
• Favouri Simpy
te Links
• Site Spurl
Map
• Contact Y! MyWeb
Me
DNS (Domain Name System), is the service which translates between
Internet names and Internet addresses.
Internet names are the names which we use to refer to hosts on the Internet,
such as www.debianhelp.co.uk.
Internet addresses are the numbers which routers use to move traffic across
the Internet, such as 211.1.13.115 and

What are DNS Records ?

DNS records or Zone files are used for mapping URLs to an IPs. Located on
servers called the DNS servers, these records are typically the connection of
your website with the outside world. Requests for your website are forwarded
to your DNS servers and then get pointed to the WebServers that serve the
website or to Email servers that handle the incoming email.
Different Types of DNS Records With Syntax and Examples

Types of DNS Records

A
AAAA
CNAME
MX
PTR
NS
SOA
SRV
TXT
NAPTR

The above DNS records are mostly used in all DNS Configurations. Now we
will see each one with examples.

A Record

An A record or address record.

Address Record, assigns an IP address to a domain or subdomain name.

When the domain name system was designed it was recommended that no
two A records refer to the same IP address.

Suppose you have the somedomain.tld domain and want to assign 10.10.0.1
IP address to your web server, then you should create an A record with
"www.somedomain.tld" as Fully Qualified Domain Name and "10.10.0.1" in the
value field.

From now on, all the requests for www.somedomain.tld will be sent to a server
with that IP.

Basically is useful to use an A record when you have subdomains residing on

various systems.

Usefultip: you might use a "*.somedomain.tld" A record to allow

WHATEVER.somedomain.tld to be resolved to your IP, though a wildcard
CNAME record is often better than a wildcard A record.

Example of A Record with Syntax

example.com. IN A 69.9.64.11

Where

IN indicates Internet

A indicates the Address record.

The above example indicate that the IP Address for the domain example.com
is 69.9.64.11

AAAA Record

An AAAA record or IPv6 address record maps a hostname to a 128-bit IPv6

address.

The regular DNS Address resource record is defined for a 32-bit IPv4 address,
so a new one was created to allow a domain name to be associated with a
128-bit IPv6 address. The four “A”s (“AAAA”) are a mnemonic to indicate that
the IPv6 address is four times the size of the IPv4 address. The AAAA record
is structured in very much the same way as the A record in both binary and
master file formats; it is just much larger. The DNS resource record Type
value for AAAA is 28.

Example of AAAA Record with Syntax

The AAAA record is to help transition and coexistence between IPv4 and IPv6
networks.An IPv4 nameserver can provide IPv6 addresses:

linuxaaaa 3ffe:1900:4545:2:02d0:09ff:fef7:6d2c

CNAME Record

A CNAME record or canonical name record makes one domain name an alias
of another. The aliased domain gets all the subdomains and DNS records of
the original.

You should use a CNAME record whenever you want associate a new
subdomain to an already existing A record; i.e. you can make
"www.somedomain.tld" to "somedomain.tld", which should already have been
assigned an IP with an A record.

This allows you to have as many subdomains as you wish without having to
specify the IP for every record. Use a CNAME if you have more services
pointing to the same IP. This way you will have to update only one record in
the convenience of a change of IP address.

Example of a CNAME record: "stuff.everybox.com CNAME

www.everybox.com" where 'www.everybox.com' is an A record listing an IP
address, and 'stuff.everybox.com' points to 'www.everybox.com'. It will NOT
allow you to foward a domain to a specific web page. Use a webhop for that.
Port numbers can be changed with webhops, as well; CNAMEs cannot change
the HTTP default of 80 to any other port number.

Do not use CNAME defined hostnames in MX records. For example, this is not
recommended

Example Of CNAME With syntax

mail.example.com IN CNAME mail.example.net

where

IN indicates Internet

CNAME indicates CNAME record.

MX Record

An MX record or mail exchange record maps a domain name to a list of mail

exchange servers for that domain.

Example with MX Record Syntax - Single mail servers

mydomain.com. 14400 IN MX 0 mydomain.com.

The MX record shows that all emails @ mydomain.com should be routed to

the mail server at mydomain.com. The DNS record shows that mydomain.com
is located at 26.34.9.14. This means that email meant for test@mydomain.com
will be routed to the email server at 26.34.9.14. This finishes the task of the
MX record. The email server on that server then takes over, collects the email
and then proceeds to distribute it to the user ``test''.

It is important that there be a dot(``.'') after the domain name in the MX record.
If the dot is absent, it routes to ``mydomain.com.mydomain.com''. The number
0, indicates Preferance number. Mail is always routed to the server which has
the lowest Preferance number. If there is only one mail server, it is safe to
mark it 0.

Using Multiple mail servers

If you want to use multiple mail servers you have to use MX record
preferences.The MX record preference values indicate which mail server to
use and in which order to try them when they fail or don't respond. A larger
preference number is less preferred. Thus, a mail exchanger with a preference
of zero (0) is always preferred over all other mail exchangers. Setting
preference values to equal numbers makes mail servers equally preferred.

Example with MX Record Syntax - Multiple mail servers

mydomain.com. 14400 IN MX 0 mydomain.com.

mydomain.com. 14400 IN MX 30 server2.mydomain.com

You can have unlimited MX entries for Fallback or backup purpose.If all the
MX records are equal Preference numbers, the client simply attempts all equal
Preference servers in random order, and then goes to MX record with the next
highest Preference number.

PTR Record

A PTR record or pointer record maps an IPv4 address to the canonical name
for that host. Setting up a PTR record for a hostname in the in-addr.arpa
domain that corresponds to an IP address implements reverse DNS lookup for
that address. For example www.name.net has the IP address 122.0.3.16, but a
PTR record maps 16.3.0.122.in-addr.arpa.

Example of PTR Record with syntax

16.3.0.122.in-addr.arpa. IN PTR name.net

Here as you see the IP Address is reversed and added with in-addr.arpa and
this has come to the left side while the actual domain name has gone to right
side of IN PTR.

This is mostly used as a security and an anti-spam measure wherein most of

the webservers or the email servers do a reverse DNS lookup to check if the
host is actually coming from where it claims to come from. It is always
advisable to have a proper reverse DNS record (PTR) is been setup for your
servers especially when you are running a mail / smtp server.

NS Record

An NS record or name server record maps a domain name to a list of DNS

servers authoritative for that domain. Delegations depend on NS records.

NS Record Name Server Record which indicates the Authoritative Name

Servers for a particular Domain. The NS records of the Authoritative Name
Server for any given Domain will be listed on the Parent Server. These are
called as the Delegation Records as these records on the Parent Server
indicates the delegation of the domain to the Authoritative servers.

The NS record will also be listed in the Zone records of the Authoritative Name
Server itself. These records are called as the Authoritative Records.

The NS records found on the Parent Server should match the NS records on
the Authoritative Server as well. However, you can have NS records listed on
the Authoritative server that is not listed in the Parent Server. This
arrangement is normally used to configure Stealth Name Servers.

Example of NS Record With syntax

example.com. IN NS ns1.live.secure.com.

where

IN indicates the Internet

NS indicates the type of record which Name Server record

The above indicates that the ns1.live.secure.com is the authoritative server for
the domain example.com

SOA Record

An SOA record or start of authority record specifies the DNS server providing
authoritative information about an Internet domain, the email of the domain
administrator, the domain serial number, and several timers relating to
refreshing the zone.

An SOA(State of Authority) Record is the most essential part of a Zone file.

The SOA record is a way for the Domain Administrator to give out simple
information about the domain like, how often it is updated, when it was last
updated, when to check back for more info, what is the admins email address
and so on. A Zone file can contain only one SOA Record.

A properly optimized and updated SOA record can reduce bandwidth between
nameservers, increase the speed of website access and ensure the site is
alive even when the primary DNS server is down.

Example of SOA Record with syntax

Here is the SOA record. Notice the starting bracket ``(``. This has to be on the
same line, otherwise the record gets broken.
; name TTL class rrNameserver email-address
mydomain.com. 14400 IN SOA ns.mynameserver.com.
root.ns.mynameserver.com. (
2004123001 ; Serial number
86000 ; Refresh rate in seconds
7200 ; Update Retry in seconds
3600000 ; Expiry in seconds
600 ; minimum in seconds )

name - mydomain.com is the main name in this zone.

TTL - 14400 - TTL defines the duration in seconds that the record may be
cached by client side programs. If it is set as 0, it indicates that the record
should not be cached. The range is defined to be between 0 to 2147483647
(close to 68 years !) .

Class - IN - The class shows the type of record. IN equates to Internet. Other
options are all historic. So as long as your DNS is on the Internet or Intranet,
you must use IN.

Nameserver - ns.nameserver.com. - The nameserver is the server which holds

the zone files. It can be either an external server in which case, the entire
domain name must be specified followed by a dot. In case it is defined in this
zone file, then it can be written as ``ns'' .

Email address - root.ns.nameserver.com. - This is the email of the domain

name administrator. Now, this is really confusing, because people expect an
@ to be in an email address. However in this case, email is sent to
root@ns.nameserver.com, but written as root.ns.nameserver.com . And yes,
remember to put the dot behind the domain name.

Serial number - 2004123001 - This is a sort of a revision numbering system to

show the changes made to the DNS Zone. This number has to increment ,
whenever any change is made to the Zone file. The standard convention is to
use the date of update YYYYMMDDnn, where nn is a revision number in case
more than one updates are done in a day. So if the first update done today
would be 2005301200 and second update would be 2005301201.

Refresh - 86000 - This is time(in seconds) when the slave DNS server will
refresh from the master. This value represents how often a secondary will poll
the primary server to see if the serial number for the zone has increased (so it
knows to request a new copy of the data for the zone). It can be written as
``23h88M'' indicating 23 hours and 88 minutes. If you have a regular Internet
server, you can keep it between 6 to 24 hours.

Retry - 7200 - Now assume that a slave tried to contact the master server and
failed to contact it because it was down. The Retry value (time in seconds) will
tell it when to get back. This value is not very important and can be a fraction
of the refresh value.

Expiry - 3600000 - This is the time (in seconds) that a slave server will keep a
cached zone file as valid, if it can't contact the primary server. If this value
were set to say 2 weeks ( in seconds), what it means is that a slave would still
be able to give out domain information from its cached zone file for 2 weeks,
without anyone knowing the difference. The recommended value is between 2
to 4 weeks.
Minimum - 600 - This is the default time(in seconds) that the slave servers
should cache the Zone file. This is the most important time field in the SOA
Record. If your DNS information keeps changing, keep it down to a day or
less. Otherwise if your DNS record doesn't change regularly, step it up
between 1 to 5 days. The benefit of keeping this value high, is that your
website speeds increase drastically as a result of reduced lookups. Caching
servers around the globe would cache your records and this improves site
performance.

SRV Record

The theory behind SRV is that given a known domain name e.g. example.com,
a given service e.g. web (http) which runs on tcp in this case, a DNS query
may be issued to find the host name that provides such on behalf of the
domain - and which may or may not be within the domain.

Example of SRV Record with syntax

srvce.prot.name ttl class rrpri weight port target

_http._tcp.example.com. IN SRV 0 5 80 www.example.com.

srvce

Defines the symbolic service name (see IANA port-numbers) prepended with a
'_' (underscore). Case insensitive. Common values are:

_http - web service

_ftp - file transfer service
_ldap - LDAP service

prot

Defines the protocol name (see IANA service-names) prepended with a '_'
(underscore). Case insensitive. Common values are

_tcp - TCP protocol

_udp - UDP protocol

name

Incomprehensible description in RFC 2782. Leaving the entry blank (without a

dot) will substitute the current zone root (the $ORIGIN), or you can explicitly
add it as in the above _http._tcp.example.com. (with a dot).

ttl

Standard TTL parameter. For more information about TTL values.

pri

The relative Priority of this service (range 0 - 65535). Lowest is highest priority.

weight

Used when more than one service with same priority. A 16 bit unsigned integer
in the range 0 - 65535. The value 0 indicates no weighting should be applied. If
the weight is 1 or greater it is a relative number in which the highest is most
frequently delivered i.e. given two SRV records both with Priority = 0, one with
weight = 1 the other weight = 6, the one with weight 6 will have its RR
delivered first 6 times out of 7 by the name server.

port

Normally the port number assigned to the symbolic service but does this is not
a requirement e.g. it is permissible to define a _http service with a port number
of 8100 rather than the more normal port 80.

target

The name of the host that will provide this service. Does not have to be in the
same zone (domain).

TXT Record

A TXT record allows an administrator to insert arbitrary text into a DNS record.
For example, this record is used to implement the Sender Policy Framework
specification.

Example of TXT Record with syntax

SPF domains have to publish at least two directives: a version identifier and a
default mechanism.

mydomain.com. TXT "v=spf1 -all"

This is the simplest possible SPF record: it means your domain

mydomain.com never sends mail.

It makes sense to do this when a domain is only used for web services and
doesn't do email.

MX servers send mail, designate them.

mydomain.com. TXT "v=spf1 mx -all"

Let's pretend mydomain.com has two MX servers, mx01 and mx02. They
would both be allowed to send mail from mydomain.com.

other machines in the domain also send mail, designate them.

mydomain.com. TXT "v=spf1 mx ptr -all"

This designates all the hosts whose PTR hostname match mydomain.com.

any other machines not in the domain also send mail from that domain,
designate them.

mydomain.com. TXT "v=spf1 a:mydomain.com mx ptr -all"

mydomain.com's IP address doesn't show up in its list of MX servers. So we

add an "a" mechanism to the directive set to match it.

mydomain.com. TXT "v=spf1 a mx ptr -all"

This is shorthand for the same thing.

Each of your mail servers should have an SPF record also.When your mail
servers create a bounce message, they will send it using a blank envelope
sender: <>. When an SPF MTA sees a blank envelope sender, it will perform
the lookup using the HELO domain name instead. These records take care of
that scenario.

amx.mail.net. TXT "v=spf1 a -all"

mx.mail.net. TXT "v=spf1 a -all"

NAPTR Record

NAPTR records (NAPTR stands for "Naming Authority Pointer") are a newer
type of DNS record that support regular expression based rewriting.

Example of NAPTR Record with syntax

$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.

NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .

NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" .
NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" .

This record set maps the phone number +441632960083 onto three possible
identically ordered URIs, with a preference for SIP, then H323, and finally
email. In each case, the regular expression matches the full AUS (^.$), and
replaces it with a URI (e.g., sip:info@example.com). As this is a terminal
record, this URI is returned to the client.Though most NAPTR records replace
the full AUS, it is possible for the regular expression to back-reference part of
the AUS, to grab an extension number, say:

$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. *

NAPTR 10 100 "u" "E2U+sip""!^+441632960(.*)$!sip:\1@example.com!" .

Once the client has the URI it must be resolved using DNS, but this is no
longer part of the DDDS algorithm..

wildcard DNS record

A wildcard DNS record is a record in a DNS zone file that will match all
requests for non-existent domain names, i.e. domain names for which there
are no records at all.

>
DNS Zones Overview
A DNS zone is the contiguous portion of the DNS domain name space over which a DNS server has
authority, or is
authoritative. A zone is a portion of a namespace .it is not a domain. A domain is a branch of the DNS
namespace. A
DNS zone can contain one or more contiguous domains. A DNS server can be authoritative for multiple
DNS zones. A
noncontiguous namespace cannot be a DNS zone.

A zone contains the resource records for all of the names within the particular zone. Zone files are used if
DNS
data is not integrated with Active Directory. The zone files contain the DNS database resource records
which define the
zone. If DNS and Active Directory are integrated, then DNS data is stored in Active Directory.

The different types of zones used in Windows Server 2003 DNS are listed below:

• Primary zone

• Secondary zone

• Active Directory-integrated zone

• Reverse lookup zone

• Stub zone

A primary zone is the only zone type that can be edited or updated because the data in the zone is the
original source of the data for all domains in the zone. Updates made to the primary zone are made by
the DNS server
that is authoritative for the specific primary zone. You can also back up data from a primary zone to a
secondary
zone.

A secondary zone is a read-only copy of the zone that was copied from the master server during zone
transfer.
In fact, a secondary zone can only be updated through zone transfer.

An Active Directory-integrated zone is a zone that stores its data in Active Directory. DNS zone files are
not needed. This type of zone is an authoritative primary zone. Zone data of an Active Directory-
integrated zone is
replicated during the Active Directory replication process. Active Directory-integrated zones also enjoy the
security
features of Active Directory.
A reverse lookup zone is an authoritative DNS zone. These zones are mainly used to resolve IP
addresses to
resource names on the network. A reverse lookup zone can be either of the following zones:

• Primary zone

• Secondary zone

• Active Directory-integrated zone

A stub zone is a new Windows Server 2003 feature. Stub zones only contain those resource records
necessary to
identify the authoritative DNS servers for the master zone. Stub zones therefore contain only a copy of a
zone, and are
used to resolve recursive queries and iterative queries:

• Iterative queries: The DNS server provides the best answer it can. This can be:

○ The resolved name

○ A referral to a different DNS server

• Recursive queries: The DNS server has to reply with the requested information, or with an error.
The DNS
server cannot provide a referral to a different DNS server

Stub zones contain the following information:

• Start of Authority (SOA) resource records of the zone.

• Resource records that list the authoritative DNS servers of the zone

• Glue address (A) resource records that are necessary for contacting the authoritative servers of
the zone.

Zone delegation occurs when you assign authority over portions of the DNS namespace to subdomains of
the DNS
namespace. You should delegate a zone under the following circumstances:

• You want to delegate administration of a DNS domain to a department or branch of your

organization.

• You want to improve performance and fault tolerance of your DNS environment .you can
distribute DNS database
management and maintenance between several DNS servers.

Understanding DNS Zone Transfer

A zone transfer can be defined as the process that occurs to copy the resource records of a zone on the
primary DNS
server to secondary DNS servers. Zone transfer enables a secondary DNS server to continue handling
queries if the
primary DNS server fails. A secondary DNS server can also transfer it zone data to other secondary DNS
servers, who
are beneath it in the DNS hierarchy. In this case, the secondary DNS server is regarded as the master
DNS server to the
other secondary servers.

The zone transfer methods are:

• Full transfer: When you configure a secondary DNS server for a zone, and start the secondary
DNS server, the
secondary DNS server requests a full copy of the zone from the primary DNS server. A full
transfer is performed of all
the zone information. Full zone transfers tend to be resource intensive. This disadvantage of full
transfers has led to
the development of incremental zone transfers.

• Incremental zone transfer: With an incremental zone transfer, only those resource records that
have since
changed in a zone are transferred to the secondary DNS servers. During zone transfer, the DNS
databases on the primary
DNS server and the secondary DNS server are compared to determine whether there are
differences in the DNS data. If the
DNS data of the primary and secondary DNS servers are the same, zone transfer does not take
place. If the DNS data of
the two servers are different, transfer of the delta resource records starts. This occurs when the
serial number on the
primary DNS server database is higher than that of secondary DNS server.s serial number. For
incremental zone transfer
to occur, the primary DNS server has to record incremental changes to its DNS database.
Incremental zone transfers
require less bandwidth than full zone transfers.

• Active Directory transfers: These zone transfers occur when Active Directory-integrated zones
are replicated
to the domain controllers in a domain. Replication occurs through Active Directory replication.

• DNS Notify is a mechanism that enables a primary DNS server to inform secondary DNS servers
when its
database has been updated. DNS Notify informs the secondary DNS servers when they need to
initiate a zone transfer so
that the updates of the primary DNS server can be replicated to them. When a secondary DNS
server receives the
notification from the primary DNS server, it can start an incremental zone transfer or a full zone
transfer to pull
zone changes from the primary DNS servers.

Understanding DNS Resource Records (RRs)

The DNS database contains resource records (entries) that are used to resolve name resolution queries
sent to the
DNS server. Each DNS server contains the resource records (RRs) it needs to respond to name
resolution queries for the
portion of the DNS namespace for which it is authoritative. There are different types of resource records.

A few of the commonly used resource records (RR) and their associated functions are described in the
Table.
Resource Records Type Name Function

Contains the IP address of a specific host, and maps t

A Host record
addresses.

AAAA IPv6 address record Ties a FQDN to an IPv6 128-bit address.

Associates a DNS domain name to a server subtype: a

AFSDB Andrews files system
volume or an authenticated name server using DCE/N

Associates a DNS domain name to the ATM address o

ATMA Asynchronous Transfer Mode address
atm_address field.

CNAME Canonical Name / Alias name Ties an alias to its associated domain name.

HINFO Host info record Indicates the CPU and OS type for a particular host.

ISDN ISDN info record Ties a FQDN to an associated ISDN telephone numbe

Contains the public key for zones that can use DNS S
KEY Public key resource record
Extensions (DNSSEC).

Maps the domain mail server name to the mail server.

MB Mailbox name record
name

MG Mail group record Ties th domain mailing group to mailbox resource reco

MINFO Mailbox info record Associates a mailbox for an individual that maintains it

MR Mailbox renamed record Maps an older mailbox name to its new mailbox name

Provides routing for messages to mail servers and bac

MX Mail exchange record
servers.

Provides a list of the authoritative servers for a domain

NS Name server record
the authoritative DNS server for delegated subdomain

Indicates those resource record types that exist for a n

NXT Next resource record
the resource record in the zone.

A pseudo-resource record which provides extended D

OPT Option resource record
functionality.
 Points to a different resource record, and is used for re
PTR Pointer resource record
lookups to point to A type resource records.

Provides routing information for hosts that do not have

RT Route through record
address.

SIG Signature resource record Stores the digital signature for an RR set.

This resource record contains zone information for

SOA Start of Authority resource record determining the name of the primary DNS server for th
such as version information.

Used by Active directory to locate domain controllers,

SRV Service locator record
and global catalog servers.

TXT Text record Maps a DNS name to descriptive text.

Maps a DNS address to the public switched data netw

X25 X.25 info record
number.

While there are various resource records that contain different information or data, there are a few
required fields
that each particular resource record has to contain:

• Owner; the DNS domain that contains the resource record

• TTL (Time to Live); indicates the time duration that DNS servers can cache resource record
information,
prior to discarding the information. This is however an optional resource records field.

• Class; is another optional resource records field. Class types were used in earlier
implementations of the
DNS naming system, and are no longer used these days.

• Type; indicates the type of information contained by the resource record.

• Record-Specific Data; a variable length field that further defines the function of the resource. The
format
of the field is determined by Class and Type.

Delegation records and glue records can also be added to a zone. These records are used to delegate a
subdomain into
a separate zone.

• Delegation records: These are Name Space (NS) resource records in a parent zone. The
delegation record
specifies the parent zone as being authoritative for the delegated zones.
 • Glue records: These are A type resource records for the DNS server who is authoritative for
delegated
zone.

The more important resource records are discussed now. This includes the following:

• Start of Authority (SOA), Name Server (NS), Host (A), Alias (CNAME), Mail exchanger (MX),
Pointer (PTR), Service
location (SRV)

Start of Authority (SOA) Resource Record

This is the first record in the DNS database file. The SOA record includes information on the zone
property
information, such as of the primary DNS server for the zone, and version information.

The fields located within the SOA record are listed below:

• Source host; the host for who the DNS database file is maintained

• Contact e-mail; e-mail address for the individual who is responsible for the database file.

• Serial number; the version number of the database.

• Refresh time; the time that a secondary DNS server waits, while determining whether database
updates have
been made, that have to be replicated via zone transfer.

• Retry time; the time for which a secondary DNS server waits before attempting a failed zone
transfer
again.

• Expiration time; the time for which a secondary DNS server will continue to attempt to download
zone
information. Old zone information is discarded when this limit is reached.

• Time to live; the time that the particular DNS server can cache resource records from the DNS
database
file.

Name Server (NS) Resource Record

The Name Server (NS) resource record provides a list of the authoritative DNS servers for a domain, as
well
authoritative DNS server for any delegated subdomains. Each zone must have one (or more) NS
resource records at the
zone root. The NS resource record indicates the primary and secondary DNS servers for the zone defined
in the SOA
resource record. This in turn enables other DNS servers to look up names in the domain.

Host (A) Resource Record

The host (A) resource record contains the IP address of a specific host, and maps the FQDN to this 32-bit
IPv4
addresses. Host (A) resource records basically associates the domain names of computers (FQDNs) or
hosts names to their
associated IP addresses. Because a host (A) resource record statically associates a host name to a
specific IP address,
you can manually add these records to zones if you have machines who have statically assigned IP
addresses.

The methods which are used to add host (A) resource records to zones are:

• Manually add these records, using the DNS management console.

• You can use the Dnscmd tool at the command line to add host (A) resource records.

• TCP/IP client computers running Windows 2000, Windows XP or Windows Server 2003 use the
DHCP Client service to both
register their names, and update their host (A) resource records.

Alias (CNAME) Resource Record

Alias (CNAME) resource records ties an alias name to its associated domain name. Alias (CNAME)
resource records are
referred to as canonical names. By using canonical names, you can hide network information from the
clients who
connect to your network. Alias (CNAME) resource records should be used when you have to rename a
host that is defined
in a host (A) resource record in the identical zone.

Mail exchanger (MX) Resource Record

The mail exchanger (MX) resource record provides routing for messages to mail servers and backup
servers. The mail
MX resource record provides information on which mail servers processes e-mail for the particular
domain name. E-mail
applications therefore mostly utilize MX resource records.

A mail exchanger (MX) resource record has the following parameters:

• Priority

• Mail server

The mail exchanger (MX) resource record enables your DNS server to work with e-mail addresses where
no specific mail
server is defined. A DNS domain can have multiple MX records. MX resource records can therefore also
be used to provide
failover to different mail servers when the primary server specified is unavailable. In this case, a server
preference
value is added to indicate the priority of a server in the list. Lower server preference values specify higher
preference.

Pointer (PTR) Resource Record

The pointer (PTR) resource record points to a different resource record, and is used for reverse lookups
to point to
A resource records. Reverse lookups resolve IP addresses to host names or FQDNs.

You can add PTR resource records to zones through the following methods:
 • Manually add these records, using the DNS management console.

• You can use the Dnscmd tool at the command line to add PTR resource records.

Service (SRV) Resource Records

Service (SRV) resource records are typically used by Active directory to locate domain controllers, LDAP
servers,
and global catalog servers. The SRV records define the location of specific services in a domain. They
associate the
location of a service such as a domain controller or global catalog server; with details on how the
particular service
can be contacted.

The fields of the service (SRV) resource record are explained below:

• Service name

• The protocol used

• The domain name associated with the SRV records.

• The port number for the particular service

• The Time to Live value

• The class

• The priority and weight.

• The target specifying the FQDN of the particular host supporting the service

The Zone Database Files

If you are not using Active Directory-integrated zones, the specific zone database files that are used for
zone data
are:

• Domain Name file: When new A type resource records are added to the domain, they are stored
in this file.
When a zone is created, the Domain Name file contains the following:

○ A SOA resource record for the domain

○ A NS resource record that indicates the name of the DNS server that was created.

• Reverse Lookup file: This database file contains information on a reverse lookup zone.

• Cache file: This file contains a listing of the names and addresses of root name servers that are
needed for
resolving names which are external to the authoritative domains.

• Boot file: This file controls the startup behavior of the DNS server. The boot file supports the
commands
listed below:
 ○ Directory command; this command defines the location of the other files specified in the
Boot file.

○ Primary command; defines the domain for which this particular DNS server has authority.

○ Secondary; specifies a domain as being a secondary domain.

○ Cache command; this command defines the list of root hints used for contacting DNS
servers for the root domain

Planning DNS Zone Implementations

When you divide the up the DNS namespace, DNS zones are created. Breaking up the namespace into
zones enables DNS to
more efficiently manage available bandwidth usage, which in turn improves DNS performance.

When determining how to break up the DNS zones, a few considerations you should include are listed
below:

• DNS traffic patterns: You can use the System Monitor tool to examine DNS performance
counters, and to obtain DNS
server statistics.

• Network link speed: The types of network links that exist between your DNS servers should be
determined when you
plan the zones for your environment.

• Whether full DNS servers or caching-only DNS servers are being used also affects how you
break up DNS zones

The main zone types used in Windows Server 2003 DNS environments are primary zones and Active
Directory-integrated
zones. The question on whether to implement primary zones or Active Directory-integrated zones; would
be determined by
the DNS design requirements of your environment.

Both primary zones and secondary zones are standard DNS zones that use zone files. The main
difference between
primary zones and secondary zones is that primary zones can be updated. Secondary zones contain
read-only copies of
zone data. A secondary DNS zone can only be updated through DNS zone transfer. Secondary DNS
zones are usually
implemented to provide fault tolerance for your DNS server environment.

An Active Directory-integrated zone can be defined as an improved version of a primary DNS zone
because it can use
multi-master replication and the security features of Active Directory. The zone data of Active Directory-
integrated
zones are stored in Active Directory. Active Directory-integrated zones are authoritative primary zones.

A few advantages that Active Directory-integrated zone implementations have oer standard primary zone
implementations are:
 • Active Directory replication is faster, which means that the time needed to transfer zone data
between zones is far
less.

• The Active Directory replication topology is used for Active Directory replication, and for Active
Directory-integrated zone replication. There is no longer a need for DNS replication when DNS
and Active Directory are
integrated.

• Active Directory-integrated zones can enjoy the security features of Active Directory.

• The need to manage your Active Directory domains and DNS namespaces as separate entities is
eliminated. This in
turn reduces administrative overhead.

• When DNS and Active Directory are integrated; the Active Directory-integrated zones are
replicated, and stored on
any new domain controllers automatically. Synchronization takes place automatically when new
domain controllers are
deployed.

The mechanism that DNS utilizes to forward a query that one DNS server cannot resolve, to another DNS
server is
called DNS forwarding. DNS forwarders are the DNS servers used to forward DNS queries for different
DNS
namespace to those DNS servers who can answer the query. A DNS server is configured as a DNS
forwarder when you
configure the other DNS servers to direct any unresolved queries to a specific DNS server. Creating DNS
forwarders can
improve name resolution efficiency.

Windows Server 2003 DNS introduces a new feature, called conditional forwarding. With conditional
forwarding,
you create conditional forwarders within your environment that will forward DNS queries based on the
specific
domain names being requested in the query. This differs from DNS forwarders where the standard DNS
resolution path to
the root was used to resolve the query. A conditional forwarder can only forward queries for domains that
are defined
in the particular conditional forwarders list. The query is passed to the default DNS forwarder if there are
no entries
in the forwarders list for the specific domain queried.

When conditional forwarders are configured, the process to resolve domain names is illustrated below:

1. A client sends a query to the DNS server for name resolution.

2. The DNS server checks its DNS database file to determine whether it can resolve the query with
its zone data.

3. The DNS server also checks its DNS server cache to resolve the request.
 4. If the DNS server is not configured to use forwarding, the server uses recursion to attempt to
resolve the
query.

5. If the DNS server is configured to forward the query for a specific domain name to a DNS
forwarder, the DNS server
then forwards the query to the IP address of its configured DNS forwarder.

A few considerations for configuring forwarders for your DNS environment are:

• You should only implement the DNS forwarders that are necessary for your environment. You
should refrain from
creating loads of forwarders for your internal DNS servers.

• You should avoid chaining your DNS servers together in a forwarding configuration.

• To avoid the DNS forwarder turning into a bottleneck, do not configure one external DNS
forwarder for all your
internal DNS servers.

How to create a new zone

1. Click Start, Administrative Tools, and then click DNS to open the DNS console.

2. Expand the Forward Lookup Zones folder

3. Select the Forward Lookup Zones folder.

4. From the Action menu, select New Zone.

5. The New Zone Wizard initiates.

6. On the initial page of the Wizard, click Next.

7. On the Zone Type page, ensure that the Primary Zone. Creates A Copy Of A Zone That Can Be
Updated Directly On This
Server option is selected. This option is by default selected.

8. Uncheck the Store The Zone In Active Directory (Available Only If DNS Server Is A Domain
Controller) checkbox.
Click Next.

9. On the Zone Name page, enter the correct name for the zone in he Zone Name textbox. Click
Next.

10. On the Zone File page, ensure that the default option, Create A New File With This File Name is
selected. Click
Next.

11. On the Dynamic Update page, ensure that the Do Not Allow Dynamic Updates. Dynamic Updates
Of Resource Records Are
Not Accepted By This Zone. You Must Update These Records Manually option is selected. Click
Next.

12. The Completing The New Zone Wizard page is displayed next.
 13. Click Finish to create the new zone.

How to create subdomains

1. Click Start, Administrative Tools, and then click DNS to open the DNS console.

2. In the console tree, select the appropriate zone.

3. From the Action menu, select New Domain.

4. The DNS Domain dialog box opens.

5. Enter the name for new subdomain.

6. Click OK to create the new subdomain.

How to create a reverse lookup zone

1. Click Start, Administrative Tools, and the select DNS to open the DNS console.

2. Select the appropriate DNS server in the console tree.

3. Right-click the DNS server, and then select New Zone from the shortcut menu.

4. The New Zone Wizard starts.

5. Click Next on the first page of the New Zone Wizard.

6. On the Zone Type page, ensure that the Primary Zone option is selected. Click Next.

7. On the following page, select the Reverse lookup zone option. Click Next.

8. Enter the IP network in the Network ID box, for the domain name that you are creating this new
reverse lookup zone
for. Click Next.

9. Accept the default zone file name. Click Next.

10. On the Dynamic Update page, select the Allow both nonsecure and secure dynamic updates
option, and then click
Next.

11. .The Completing The New Zone Wizard page is displayed next.

12. Click Finish to create the new reverse lookup zone.

How to create a stub zone

1. Click Start, Administrative Tools, and then click DNS to open the DNS console.

2. Expand the Forward Lookup Zones folder

3. Select the Forward Lookup Zones folder.

4. From the Action menu, select New Zone.

 5. The New Zone Wizard initiates.

6. On the initial page of the Wizard, click Next.

7. On the Zone Type page, select the Stub Zone option.

8. Uncheck the Store The Zone In Active Directory (Available Only If DNS Server Is A Domain
Controller) checkbox.
Click Next.

9. On the Zone Name page, enter the name for the new stub zone in the Zone Name textbox, and
then click Next.

10. Accept the default setting on the Zone file page. Click Next.

11. On the Master DNS Servers page, enter the IP address of the master server in the Address text
box. Click Next.

12. On the Completing The New Zone Wizard page, click Finish.

How to add resource records to zones

1. Click Start, Administrative Tools, and then click DNS to open the DNS console.

2. In the console tree, select the zone that you want to add resource records to.

3. From the Action menu, select the resource record type that you want to add to the zone. The
options are:

○ New Host (A)

○ New Alias (CNAME)

○ New Mail Exchanger (MX)

○ Other New Records

4. Select the New Host (A) option.

5. The New Host dialog box opens.

6. In the Name (Use Parent Domain Name If Blank) textbox, enter the name of the new host.

7. When you specify the name of the new host, the resulting FQDN is displayed in the Fully qualified
domain name
(FQDN) textbox.

8. In the IP Address box, enter the address for the new host.

9. If you want to create an associated pointer (PTR) record, enable the checkbox.

10. Click the Add Host button.

11. The new host (A) resource record is added to the particular zone.
 12. A message box is displayed, verifying that the new host (A) resource record was successfully
created for the
zone.

13. Click OK.

14. Click Done to close the New Host dialog box./li>

How to create a zone delegation

1. Click Start, Administrative Tools, and then select DNS to open the DNS console.

2. Right-click your subdomain in the console tree, and then select New Delegation from the shortcut
menu.

3. The New Delegation Wizard initiates.

4. Click Next on the first page of the New Delegation Wizard.

5. When the Delegated Domain Name page opens, provide a delegated domain name, and then
click Next.

6. On the Name Servers page, click the Add button to provide the names and the IP addresses of
your DNS servers that
should host the delegation

7. On the Name Servers page, click Next.

8. Click Finish.

How to enable dynamic updates for a zone

1. Click Start, Administrative Tools, and the select DNS to open the DNS console.

2. Right-click the zone you want to work with in the console tree, and then select Properties from the
shortcut
menu.

3. When the Zone Properties dialog box opens, on the General tab, select Yes in the Allow Dynamic
Updates list
box.

4. Click OK.

How to configure a zone to use WINS for name resolution

You can configure your forward lookup zone to use WINS for name resolution in instances where the
queried name is
not found in the DNS namespace.

1. Click Start, Administrative Tools, and the select DNS to open the DNS console.

2. In the console tree, proceed to expand your DNS server node, and then expand the Forward
Lookup Zones folder.
3. Locate and right-click the zone which you want to configure and then select Properties from the
shortcut menu.

4. When the Zone Properties dialog box opens, click the WINS tab.

5. Enable the Use WINS Forward Lookup checkbox.

6. Type the WINS server IP address. Click Add, and then click OK.

7. On the General tab, select Yes in the Allow Dynamic Updates list box.