Active Directory DNS Integration

White Paper

Abstract

This paper describes how Active Directory uses the Domain Name System (DNS) in conjunction with the
Windows Domain Locator service for distributed computing environments. It discusses how the Adonis Server
integrates into existing or new Active Directory deployments. DNS replication mechanisms are discussed
including their pros and cons. Active Directory records and DNS labeling conventions are described in detail to
give the reader a deeper understanding how the locator service works.
USE OF THIS DOCUMENT Publisher Information
All rights reserved worldwide. No part of this publication may be reproduced,
transmitted, transcribed, stored in a retrieval system, or translated into any human
or computer language in any form or by any means without the express written
permission of:

BlueCat Networks, Inc.

9050 Yonge Street, Suite 401
Richmond Hill, Ontario Canada L4C 9S6

Attention: General Manager

Telephone: 905-882-5691
Fax: 905-882-5057
E-mail: info@bluecatnetworks.com
Web Site: www.bluecatnetworks.com

This publication is provided as is without warranty of any kind, express or implied,

including, but not limited to, the implied warranties of merchantability, fitness for a
particular purpose, or non-infringement.

All terms mentioned in this publication that are known to be trademarks or service
marks are appropriately capitalized. BlueCat Networks cannot attest to the
accuracy of this information. Use of a term in this publication should not be
regarded as affecting the validity of any trademark or service mark. The
trademarks, service marks and logos (the "Trademarks") displayed are registered
and unregistered Trademarks of BlueCat Networks, Inc. and others. Users are not
permitted to use these Trademarks for any purpose without the prior written
consent of BlueCat Networks or the third party owning the Trademark.

Copyright
This document and all information (in text, Graphical User Interface ("GUI"), video
and audio forms), images, icons, software, design, applications, calculators,
models, projections and other elements available on or through this document are
the property of BlueCat Networks or its suppliers, and are protected by Canadian
and international copyright, trademark, and other laws. Your use of this document
does not transfer to you any ownership or other rights or its content. You
acknowledge and understand that BlueCat Networks retains all rights not
expressly granted.

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. i
 No Professional Advice
This document is for convenience and informational purposes only. This
document is not intended to be a comprehensive or detailed statement concerning
the matters addressed; advice or recommendations, whether scientific or
engineering in nature or otherwise; or an offer to sell or buy any product or
service. BlueCat Networks does not warrant or make any representations
regarding the use, validity, accuracy, or reliability of, or the results of the use of,
this web site or any materials on this document or any web site referenced herein.
This document is intended solely for the use of the recipient. It does not institute a
complete offering and is not to be reproduced or distributed to any other person.

Persons who receive this document agree that all information contained herein is
exclusively the intellectual property of BlueCat Networks and will not reproduce,
recreate or other use material herein, unless you have received expressed written
consent from BlueCat Networks.

© Copyright 2004 BlueCat Networks, Inc.

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. ii
CONTENTS INTRODUCTION................................................................................................... 1
ACTIVE DIRECTORY AND DNS ......................................................................... 1
DYNAMIC DOMAIN CONTROLLER REGISTRATION........................................ 2
INTEGRATING THE ADONIS INTO ACTIVE DIRECTORY ................................ 4
DNS REPLICATION ............................................................................................. 5
ADVANTAGES OF ADONIS FOR ACTIVE DIRECTORY DNS SERVICES ........ 7
SUMMARY............................................................................................................ 9
ACTIVE DIRECTORY DNS RECORDS ............................................................... 9
SRV Records.................................................................................................. 9
A Records..................................................................................................... 11
CNAME Records .......................................................................................... 11

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. iii
INTRODUCTION Windows® 2000 Server was a pivotal point for Microsoft in centralizing and
consolidating directory services. Active Directory® (AD) is based on well known
network services such as Lightweight Directory Access Protocol (LDAP) and
Kerberos and utilizes DNS for its location mechanism. DNS has now grown to
become not only the cornerstone of the Internet, but a crucial fabric to connect
Windows clients with their Domain Controllers. This document will outline how
Active Directory utilizes DNS and how the Adonis DNS Appliance integrates into
this environment. The integration of the Adonis Server can be performed easily
while providing a robust, secure and highly maintainable DNS management
platform.

ACTIVE DIRECTORY AND DNS Active Directory is an essential element of the Windows server architecture that
provides a centrally managed directory service for distributed computing
environments. The directory is a central authority for network security, resources,
users and services. Active Directory is based upon the LDAP and uses security
based on MIT's Kerberos project. AD was first available in Windows 2000 Server.

Microsoft chose to change its Windows Domain discovery process to use DNS
instead of its legacy discovery protocol. This acts like a boot strapping mechanism
for client systems to find the closest or most appropriate Domain Controller (DC).
This information is stored in a series of DNS records specifying the following
information:

„ LDAP Servers
„ Kerberos Domain Controllers
„ Address of the Domain Controllers
„ Global Catalog Servers
„ Kerberos Password Change Servers

Before a client can connect to the Windows Domain, a suitable DC needs to be

found. The Windows client contains a service called NetLogon which uses a
Domain Controller locating algorithm to find the appropriate server. This algorithm
works in the following manner:

1. A List of DCs is obtained via a DNS query using the domain name,
domain GUID and/or site name.

2. The locator will ping each controller in random order and use the weight-
ing factor discovered while getting the list of DCs. It will wait up to 1/10th
of a second for a reply from the DC. The pinging continues until all DCs
have been tried or until a successful response has been received.

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. 1
 3. After a DC responds successfully to a ping, the results from the response
are compared to the parameters required by the client. If this matches
then the DC is used, otherwise pinging of other DCs resumes.

Adonis DNS

1. Query DNS for a list

of Domain Controllers

Domain Controller
2. Ping Domain
Controllers remotely

Client Workstation 3. Select Domain Controller

that satisfies connection
parameters Domain Controller

Figure 1: Locating an appropriate Domain Controller

DYNAMIC DOMAIN Without the proper DNS information, a client cannot find out which server to
CONTROLLER REGISTRATION contact for authentication. Each Domain Controller registers and maintains it own
Active Directory DNS integration records which consist of several A (Address),
CNAME (Canonical Name) and SRV (Service) records. These records are initially
registered by the DC's NetLogon service. This is performed via standard DNS
zone transfer (AXFR), query and Dynamic DNS Update (RFC 2136) by the DC

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. 2
 Slave DNS Server

Slave DNS Server

Master DNS Server

1. Perform transfer of
Active Drectory zone 3. Send updates to slave servers via
Incremental Zone Transfer (IXFR)

2. Send Dynamic Updates to

add/update controller's records

Domain Controller

Figure 2: Registering Active Directory Records

When examining these records in the Microsoft DNS server, one is led to believe
that this data must reside in sub zones of the parent domain. This is not
necessarily the case, since Dynamic DNS (DDNS) updates have no way of
creating additional zones. The records are simply added as resource records with
label separators (".") into the parent domain. Additionally one will notice that
several of the records contain underscore ("_") characters as part of the names.
This technique is common practice used in Microsoft development tools and was
borrowed for the DNS naming technique for Active Directory. The following list
contains the naming conventions used in the records:

DNS Label Description

_ldap LDAP service
_tcp Service uses TCP connections
udp Service uses UDP connections
_kerberos Record contains information about a Kerberos Key Distribution Center
(KDC)
_msdcs Service is running on a Domain Controller
_kpasswd Kerberos Password Change service
_gc Global Catalog service
_sites Record contains information a specific site
dc Domain Controller (DC)
gc Global Catalog (GC)

A registered DNS record can contain one or more of the above names to describe
a service that can be queried. For example, the following record locates an LDAP
service, on server1.bluecatnetworks.com, in the bluecatnetworks.com:
_ldap._tcp.bluecatnetworks.com SRV 0 0 389 server1.bluecatnetworks.com

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. 3
 An alternative form of this record that indicates that the LDAP service is on a DC
would have the following syntax:
_ldap._tcp.dc._msdcs.bluecatnetworks.com SRV 0 0 389
server1.bluecatnetworks.com

For a detailed list of these records see the "Active Directory DNS Records"
section of this document.

INTEGRATING THE ADONIS The Adonis DNS Appliance can be easily integrated into the Active Directory
INTO ACTIVE DIRECTORY environment. The simplest way to perform this operation is use the "Active
Directory Wizard" for each zone that requires AD integration. The wizard asks for
the IP addresses of each Domain Controller that will register their records. Once
complete, the configuration is deployed and the Active Directory servers are
informed that their primary DNS server is now an Adonis DNS Appliance. Once
this has been performed, the DC will register their records and client machines will
use this information to gain access to the AD domain.

To manually perform the integration without the assistance of the Wizard involves
a few simple steps.

1. Create an Access Control List (ACL) that will contain the addresses of all
the Domain Controllers. Add this ACL to each DNS server.

2. For the master server, allow zone transfers

3. For each master zone, allow dynamic updates using the ACL

4. For each slave zone, allow update forwarding using the ACL. This will for-
ward dynamic updates to the master zone.

Once the configuration has been deployed, it will take anywhere from a few
minutes to an hour for the DCs to register their records. This time interval is
dependent on the DC's registration settings and can be changed to suit an
organization' needs. Domain Controllers will usually inspect their records after the
interval has expired. After the DCs have registered their records, a simple refresh
of the master server's configuration will reveal the Active Directory records.

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. 4
 Figure 3: Adonis Management Console with Active Directory Records

Windows 2000 type networks also allow clients to register their own Address (A)
and Pointer (PTR) records with their DNS server. In most cases, organizations
use DHCP servers that can perform the registration directly with the DNS server
and is a more secure method. However, if desired, clients can still register
themselves directly with the DNS server by allowing those specific clients to make
dynamic updates.

DNS REPLICATION There are two schools of thought about DNS record replication. Master-Slave, the
current industry standard outlined in RFC 1034 and 1035, states that a secondary
zone (slave) will replicate its contents from a primary (master) zone on a given
internal. This was enhanced by the DNS Notify mechanism (RFC 1996) that
allowed master servers to notify their slaves when their contents were changed.
With the advent of Dynamic DNS (DDNS), incremental zone transfers (IXFR)
were developed to make zone transfers faster and slaves can now accept and
forward updates to their masters. The master-slave architecture works on
Windows, UNIX® and other operating systems and is the recommended method
for managing DNS. The following table lists some of the pros and cons of a
Master-Slave replication system:

Master-Slave
Pros Cons
„ Industry standard method for maintaining „ Must update the master server to make
zone data changes on other servers
„ Master always contains most up-to-date „ If a slave is updated, a small delay will
information exist before update is propagated
„ Central repository for zone data „ Requires latest version of BIND software
„ Does not require other services to to take advantage of update-forwarding
replicate data

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. 5
 Slave DNS Server

Slave DNS Server

Master DNS Server

Send updates to
slave servers

Update locator records

Domain Controllers

Figure 4: Active Directory Master-Slave Architecture

When Microsoft introduced Active Directory with Windows 2000, it changed its
DNS implementation. The changes included the ability to allow special characters
in DNS labels and to store the entire DNS configuration inside the Active
Directory. Because Active Directory had its own replication scheme, a different
DNS architecture known as Master-Master was developed. The recommended
Microsoft architecture for Active Directory specifies that the DNS servers should
reside on the domain controller, thus eliminating the need to perform zone
transfers. The following table looks at the pros and cons of the Master-Master
method of replication:

Master-Master
Pros
„ Central repository for all zone data
„ Editing the DNS on one zone replicates to
all others
„ Saves bandwidth and processing power
by using existing LDAP replication
Cons
„ Microsoft-only implementations
„ Zone serial numbers can be inconsistent
in SOA data
„ Non-standard Architecture
„ Not favored in heterogeneous
environments
„ Relies on LDAP for replication
„ LDAP replication may not be acceptable
for external zone data

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. 6
 MS DNS Server

MS DNS Server

Active Directory

MS DNS Server

Update zone data

Update locator records

Domain Controller

Figure 5: Active Directory Master-Master Architecture

The Adonis DNS Appliance uses the BIND 9.x name server software. Therefore
all architectures are Master-Slave based. If this technique becomes more widely
accepted with other vendors, future releases of the Adonis DNS Appliance may
contain a Master-Master replication system.

ADVANTAGES OF ADONIS FOR Although every version of Windows Server ships with the Microsoft DNS service,
ACTIVE DIRECTORY DNS many network administrators do use a non-Microsoft implementation of DNS. A
SERVICES
non-Microsoft DNS-based solution like the Adonis DNS Appliance integrates well
into an Active Directory Environment.

1. Interoperability with existing DNS architecture

The Adonis Server is based upon ISC's BIND, the most widely used DNS ser-
vice implementation, and used as the reference for DNS. Existing BIND archi-
tectures can interoperate easily with the Adonis Server while maintaining a
similar architecture.

2. Quick Migration
Existing BIND-based configurations can be quickly imported and deployed to
Adonis Servers. Current Windows DNS implementations (NT 4.0, 2000 and
2003) can be imported via BlueCat Networks' DNS extraction tool. Current
Microsoft DNS management application requires low level scripting or manual
import via zone transfers to migrate from BIND to Windows DNS. The Adonis
Server will perform additional data checking on the imported data to isolate
and assist in resolution of issues before they are deployment.

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. 7
 3. Superior Configuration Management
The Adonis Server contains an elegant and easy to use interface for manipu-
lating DNS configurations and record data. Powerful features found in most
applications include multi-level undo/redo, cut/copy/paste and data checking
functionality that is absent from the Microsoft DNS application.

4. Controlled Deployment
Changes are not visible on the DNS server until the user has deployed the
configuration. The current implementation of the Microsoft DNS application
applies the changes to the DNS server as they are made. This can create
issues for applications when simple typos are introduced into a configuration
because records can be cached for a defined duration. This can lead to net-
work application/service outages and stability issues. This issue is com-
pounded by the fact that some applications do not respect DNS Time to Live
(TTL) values and will hold onto an invalid date until restarted.

5. Improved Security
DNS security is often overlooked for private networks because an internal
network is seen as secure and separate from the outside world. The real
problem lies in the sheer volume of exploits in the Windows operating system
that plague network administrators. Worms unload their payloads that attack
internal systems and replicate while bringing a network to its knees. The SQL
Slammer worm that exploited a known vulnerability in the Microsoft Data
Engine (MSDE) attacked available root servers by generating bogus queries.
These queries resulted in a large number of ICMP packets being sent out and
eventually brought the root servers off line. Many organizations also found
their own internal DNS servers being attacked in a similar manner. The Ado-
nis DNS Appliance contains an integrated firewall, IP packet spoofing and a
hardened Linux operating system that resists these types of attacks.

6. Total Cost of Ownership (TCO)

The total cost of the Adonis DNS Appliance is considerably lower than that of
a Microsoft DNS server solution. With the volume of Windows updates, vul-
nerabilities, scheduled maintenance and simplistic management, surrounding
the Windows solution, the Adonis solution offers a lower cost of total owner-
ship, even in the first year of deployment. For more detailed information about
the total cost of ownership, see the BlueCat Networks document on the Ado-
nis Server's Return on Investment (ROI).

SUMMARY Active Directory is the back bone of the Windows Server architecture and is
centered on the LDAP service. DNS plays an important role in providing the
information used by the Windows Domain locator service to connect and

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. 8
 authenticate with Active Directory. The Adonis DNS Appliance provides features
that allow easy integration with Active Directory while providing BIND-based DNS
services throughout an organization. Existing DNS configurations that utilize BIND
can rest assured that the migration to the Adonis DNS Appliance will yield a
compatible, reliable and dependable DNS solution.

For more information about the Adonis DNS Appliance, visit the BlueCat
Networks website at http://www.bluecatnetworks.com

ACTIVE DIRECTORY DNS The following section contains a list of Active Directory specific records that are
RECORDS registered by the NetLogon service.

SRV Records
_ldap._tcp.<DomainName>
SRV record that identifies an LDAP server in the domain named by <DomainName>.
The LDAP server is not necessarily a DC. This record is registered by all Domain
Controllers.
Example: _ldap._tcp.bluecatnetworks.com

_ldap._tcp.<SiteName>._sites.<DomainName>
Allows a client to find an LDAP server in the domain named by <DomainName>. This
record is registered by all Domain Controllers.
Example: _ldap._tcp.richmondhill.bluecatnetworks.com

_ldap._tcp.dc._msdcs.<DomainName>
Used by clients to locate a DC in the domain named by <DomainName>. This record is
registered by all Domain Controllers.
Example: _ldap._tcp.dc._msdcs.bluecatnetworks.com

_ldap._tcp.<SiteName>._sites.dc._msdcs.<DomainName>
Allows a client to locate a DC for the given site and domain named by <SiteName>
and <DomainName> respectively.
Example: _ldap.tcp.richmondhill._sites.dc._msdcs.bluecatnetworks.com

_ldap._tcp.pdc._msdcs.<DomainName>
Allows a client to locate the Primary Domain Controller (PDC) for a domain named by
<DomainName>. This record is only registered by the PDC of the domain.
Example: _ldap._tcp.pdc._mscdcs.bluecatnetworks.com

_ldap._tcp.gc._msdcs.<DomainName>
Allows a client to find the Global Catalog (GC) server for the forest named by
<ForestName>. Only the DC for the GC will register this record.
Example: _ldap._tcp.gc._msdcs.bluecatnetworks.com

_ldap._tcp.<SiteName>._sites.gc._msdcs.<ForestName>
Allows a client to find a GC for the forest named by <ForestName>. Only an LDAP
server responsible for the GC will register this record.

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. 9
 Example: _ldap._tcp.richmondhill._sites.gc._msdcs.bluecatnetworks.com

_gc._tcp.<ForestName>
Allows a client to locate a GC for the forest named by <ForestName>. Only an LDAP
server responsible for the GC will register this record. The LDAP server is not
necessarily a DC.
Example: _gc._tcp.bluecatnetworks.com

_gc._tcp.<SiteName>._sites.<ForestName>
Allows a client to find a GC for the site and forest named by <SiteName> and
<ForestName> respectively. Only an LDAP server responsible for the GC will register
this record.
Example: _gc._tcp.richmondhill._sites.bluecatnetworks.com

_ldap._tcp.<DomainGuid>.domains._msdcs.< ForestName>
Used by clients to find a DC given the domain guid of <DomainGuid> in the forest
named by <ForestName>. This lookup can used to resolve the DC if the domain name
has changed. This record is used infrequently and will not work if the <ForestName>
has been changed.
Example: _ldap._tcp.01693484-b5c4-4b31-8608-
80e77ccc78b8.domains._msdcs.bluecatnetworks.com

_kerberos._tcp.<DomainName>
Allows a client to find a Kerberos Key Distribution Center (KDC) for the domain named
by <DomainName>. This record will be registered by all DCs providing the Kerberos
service. This service is RFC-1510 compliant with Kerberos 5 KDC. The server is not
necessarily a DC.
Example: _kerberos._tcp.bluecatnetworks.com

_kerberos._udp.<DomainName>
Allows a client to find a Kerberos Key Distribution Center (KDC) for the domain named
by <DomainName>. This record will be registered by all DCs providing the Kerberos
service. This service is RFC-1510 compliant with Kerberos 5 KDC. The server is not
necessarily a DC. This service supports UDP.
Example: _kerberos._tcp.bluecatnetworks.com

_kerberos._tcp.<SiteName>._sites.<DomainName>
Allows a client to locate a server running the Kerberos KDC for a site and domain
named by <SiteName> and <DomainName> respectively. The server is not
necessarily a DC.
Example: _kerberos._tcp.richmondhill._sites.bluecatnetworks.com

_kerberos._tcp.<SiteName>._sites.dc._msdcs.<DomainName>
Used by clients to locate the DC running a Kerberos KDC for the site and domain
named by <SiteName> and <DomainName> respectively.
Example:
_kerberos._tcp.richmondhill._sites.dc._msdcs.bluecatnetworks.com

_kpasswd._tcp.<DomainName>
Allows a client to find a Kerberos Password Change Server for the domain named by
<DomainName>. The server is not necessarily a DC. All DC running the Kerberos
KDC will register this record.

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. 10
 Example: _kpasswd._tcp.bluecatnetworks.com

_kpasswd._udp.<DomainName>
Allows a client to find a Kerberos Password Change Server for the domain named by
<DomainName>. The server is not necessarily a DC. All DC running the Kerberos
KDC will register this record.
Example: _kpasswd._udp.bluecatnetworks.com

A Records
<ServerName>.<DomainName>
The server name named by <ServerName> is registered in the domain named by
<DomainName>. This record is used by referral lookups to SRV and CNAME records.
Example: dc1.bluecatnetworks.com

gc._msdcs.<ForestName>
Allows a client to find a GC for a given forest named by <ForestName>. This record is
used by referral from SRV records.
Example: gc._msdcs.bluecatnetworks.com

CNAME Records
<DSAGuid>._msdcs.<ForestName>
Allows a client to locate any DC in the forest named by <ForestName> by the GUID of
the MSFT-DSA (Directory Services) object.
Example: 01693484-b5c4-4b31-8608-80e77ccc78b8._msdcs.bluecatnetworks.com

© 2004 BlueCat Networks, Inc. All rights reserved. All brands and trademarks are the property oftheir respectve owners.
Actual implementation and configuration may vary. E. & O.E. 11