Whitepaper
ii | BlueCat Networks
Use of this document
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.
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 2011, BlueCat Networks Inc. All rights reserved
worldwide.
Publisher Information
Published in Canada 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.
4101 Yonge Street, Suite 502
Toronto, Ontario
Canada M2P 1N6
Telephone: 416-646-8400
Fax: 416-225-4728
E-mail: info@bluecatnetworks.com
Website: www.bluecatnetworks.com
Executive Summary
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. AD utilizes DNS for its
location mechanism. DNS has grown to become not only the cornerstone of the Internet, but a crucial fabric to connect Windows
clients with their Domain Controllers. This document outlines how
AD 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.
iv | BlueCat Networks
Contents
Executive Summary iii
Active Directory and DNS 1
Dynamic DomainController Registration 1
Integrating Adonis into Active Directory 2
DNS Replication 3
Advantages Of Adonis For ActiveDirectory DNS Services 4
Interoperability with Existing DNS Architecture 4
Quick Migration4
Superior Configuration Management4
Controlled Deployment4
Improved Security5
Total Cost of Ownership (TCO)5
Summary 5
Active Directory DNS Records 5
SRV Records5
A Records 7
CNAME Records 7
About BlueCat Networks 8
BlueCat Networks White Papers 9
Domain Controller
1
1 Update locator records
Dynamic Domain
Controller Registration
LDAP Servers
Kerberos Domain Controllers
Addresses of the Domain Controllers
Global Catalog Servers
Kerberos Password Change Servers
Domain Controller
1
2
Description
_ldap
LDAP service
_tcp
_udp
_kerberos
_msdcs
_kpasswd
_gc
_sites
dc
gc
Domain Controller
1
1 Update locator records
2 | BlueCat Networks
For example, the following record locates an LDAP service, on
server1.bluecatnetworks.com in bluecatnetworks.com:
_ldap._tcp.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.
own Address (A) and Pointer (PTR) records with their local DNS
DNS Replication
There are two schools of thought about DNS record replication:
Master Slave and Master Master.
Master Slave The current industry standard outlined in RFC
1034 and 1035, states that a secondary zone (slave) replicates its
contents from a primary (master) zone on a given internal network.
This was enhanced by the DNS Notify mechanism (RFC 1996)
that lets master servers notify their slaves when their contents
have changed. With the advent of Dynamic DNS (DDNS), faster
incremental zone transfers (IXFR) were developed. Slave servers
could then accept and forward updates to their respective master
servers. The Master - Slave architecture works on Windows, UNIX,
and other operating systems. It is the recommended method for
managing DNS. The following table lists some of the pros and cons
of a Master-Slave replication system:
An industry standard
method for maintaining
zone data
Cons
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
Domain Controller
1
1 Update locator records
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.
Domain Controller
1
2
4 | BlueCat Networks
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. The 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 performs additional data checking on the
imported data to isolate and assist with the resolution of issues
before deployment.
Worm viruses can unload 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 which eventually rendered some of the
root servers to be off line. Many organizations also discovered that
their own internal DNS servers were being attacked in a similar
manner. The Adonis DNS Appliance contains an integrated firewall,
IP packet spoofing, and a hardened Linux operating system that
resists these types of attacks. Indeed, it is common knowledge that
heterogeneous networks are more resilient to effective attacks
since only some of the servers will be vulnerable to system-specific
exploits.
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 network application/
service outages and stability issues. This issue is compounded by
the fact that some applications do not respect DNS Time to Live
(TTL) values and will hold onto invalid data until restarted.
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 with the sheer volume of exploits in the
Windows operating system that plague network administrators.
Active Directory
MS DNS Server
Domain Controller
MS DNS Server
Summary
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 Domain
Controller (DC). This record is registered by all DCs. For example:
_ldap._tcp.bluecatnetworks.com
_ldap._tcp.<SiteName>._sites.<DomainName>
Enables a client to find an LDAP server in the domain named by
<DomainName>. This record is registered by all DCs. For example:
_ldap._tcp.richmondhill.bluecatnetworks.com
_ldap._tcp.dc._msdcs.<DomainName>
Used by clients to locate a Domain Controller (DC) in the domain
named by <DomainName>. This record is registered by all DCs. For
example:
_ldap._tcp.dc._msdcs.bluecatnetworks.com
_ldap._tcp.<SiteName>._sites.dc._msdcs.<DomainName>
Enables a client to locate a DC for the given site and domain named
by <SiteName> and <DomainName> respectively. For example:
_ldap.tcp.richmondhill._sites.dc._msdcs.
bluecatnetworks.com
_ldap._tcp.pdc._msdcs.<DomainName>
Enables a client to locate the Primary Domain Controller (PDC) for
a domain named by <DomainName>. This record is registered only
by the PDC of the domain. For example:
_ldap._tcp.pdc._mscdcs.bluecatnetworks.com
_ldap._tcp.gc._msdcs.<DomainName>
Enables 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. For example:
_ldap._tcp.gc._msdcs.bluecatnetworks.com
_ldap._tcp.<SiteName>._sites.gc._msdcs.<ForestName>
Enables a client to find a GC for the forest named by <ForestName>.
Only an LDAP server responsible for the GC will register this record.
For example:
_ldap._tcp.richmondhill._sites.gc._msdcs.
bluecatnetworks.com
6 | BlueCat Networks
_gc._tcp.<ForestName>
Enables 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. For example:
_gc._tcp.bluecatnetworks.com
_gc._tcp.<SiteName>._sites.<ForestName>
Enables 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. For example:
_gc._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. For example:
_kerberos._tcp.richmondhill._sites.dc._msdcs.
bluecatnetworks.com
_kpasswd._tcp.<DomainName>
Enables 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. For
example:
_kpasswd._tcp.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. For example:
_ldap._tcp.01693484-b5c4-4b31-8608-80e77ccc78b8.
domains._msdcs.bluecatnetworks.com
_kerberos._tcp.<DomainName>
Enables 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. For example:
_kerberos._tcp.bluecatnetworks.com
_kerberos._udp.<DomainName>
Enables 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.For example:
_kpasswd._udp.<DomainName>
Enables 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. For
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. For example:
dc1.bluecatnetworks.com
gc._msdcs.<ForestName>
Enables a client to find a GC for a given forest named by
<ForestName>. This record is used by referral from SRVrecords. For
example:
gc._msdcs.bluecatnetworks.com
_kerberos._tcp.bluecatnetworks.com
_kerberos._tcp.<SiteName>._sites.<DomainName>
Enables 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. For example:
_kerberos._tcp.richmondhill._sites.
bluecatnetworks.com
CNAME Records
<DSAGuid>._msdcs.<ForestName>
Enables a client to locate any DC in the forest named by <ForestName> by the GUID of the MSFT-DSA (Directory Services) object.
For example:
01693484-b5c4-4b31-8608-80e77ccc78b8._msdcs.
bluecatnetworks.com
To Learn More
For more information on BlueCat Networks, and our award winning Proteus IPAM solutions,
please visit our website at www.bluecatnetworks.com or call us at 1-866-895-6931.
North American
Corporate/R&D
Headquarters:
502-4101 Yonge Street
Toronto, ON M2P 1N6
Phone: +1.416.646.8400
Fax: +1.416.225.4728
Toll Free: +1.866.895.6931
United Kingdom
BlueCat Networks Europe
Merlin House
Brunel Road
Theale Berkshire RG7 4AB
Phone: +44.118.902.6680
Fax: +44.118.902.6401
Germany
BlueCat Networks
(Zentraleuropa)
Altrottstrasse 31
D-69190 Walldorf, Germany
Telephone: +49.6227.38489.10
Fax: +49.6227.38489.18
Shanghai, China
12/F, Shui On Plaza, No. 333 Huai
Hai Zhong Rd
Luwan District
Shanghai, China
US Offices:
Reston, VA
1818 Library Street
Suite 500
Reston, VA
20190
Phone: +1.703.956.3551
Atlanta, GA
1165 Sanctuary Parkway
Suite 260
Alpharetta, GA 30009
Phone: +1.770.777.2461
Fax: +1.770.777.2464
Chicago, IL
300 East 5th Avenue
Suite 440
Naperville, IL
60563
Phone: +1.630.946.6297
Philadelphia, PA
1500 Market Street
12th Floor / East Tower
Philadelphia, PA
19102
Phone: +1.215.246.3400
Los Angeles,CA
4640 Campus Drive
Suite 103
Newport Beach, CA
92660
Phone: +1.949.260.8444
Beijing, China
D202/2502 Topbox, No. 69
West Beichen Road
Chaoyang District,
Beijing China, 100029
Phone:+ 86.10.8202.4226
Fax: +86.10.8202.6488
2011. BlueCat Networks, the BlueCat Networks logo, the Proteus logo, IPAM Appliance, the Adonis logo, Adonis are trademarks of BlueCat Networks, Inc.
Microsoft, Windows, and Active Directory are registered trademarks of Microsoft Corporation. Any product photos shown are for reference only and are subject to
change without notice. All other product and company names are trademarks or registered trademarks of their respective holders. Printed in Canada.
bluecatnetworks.com