Useful Links:

• Yale AD Home

Dynamic DNS and Windows 2000 at Yale University

Our original Active Directory design proposal had many subdomains instead of having most machines participate in a single domain. To go along with that, a significant amount of work was done on how to deal with the need for dynamic name service and reconcile requirements which seemed, at first, to be mutually exclusive:

• To fully integrate the Active Directory name space into the existing name space of the university.

• To use the existing name service (unix servers running bind in static mode) as the sole authoritative source for DNS "A" records.

• To allow dynamic name service to function without administrative action beyond initial configuration (i.e. no need to manually maintain DDNS information)

Eventually a a fully-functional model was implemented as a proof of concept during the early stages of testing Windows 2000 and the Active Directory and ran without incident forroughly six months while other testing was going on around it.  A significant amount of web material was written to document that modeland its specifics with a lot of emphasis on DNS because there seemed to be few others following the same path we did because of the complexity of the DNS issue.

This document is a collection of DNS-related information from those web pages that documented that AD model and described how an administrator of a subdomain could successfully integrate with it.

Our current Active Directory model uses the lessons we learned during that design and testing phase but does not fully distribute DDNS service to each subdomain.

We have received a significant amount of interest in the DNS work we did with Windows 2000 and, though the design that drove the work is no longer going to be fully implemented, the mechanisms and procedures we tested are documented here in the hope that others will find them useful.

The "heart" of the model is in this section on the relationship between AD and DDNS.

Why is Dynamic DNS so critical in Windows 2000?

Windows 2000 uses DNS as a locator service in a similar way that Windows NT relies on WINS (which was much less efficient and didn't scale).  Simply put, DNS queries are used to find which functions are running on which servers.  Servers and clients can make entries in a dynamic name server that indicate what functions they are performing with respect to the active directory.  Without those entries, a Windows 2000 system can't perform any domain-related functions such as authenticating users.

What is the relationship between Active Directory and DDNS and how do I make it work with static name servers?

Active Directory requires that a Dynamic DNS server (DDNS) be available in order to store information about what functions are being performed by what systems.  This is done by having each server insert records of type "SRV" in the name server to indicate what functions it is performing.  These functions include LDAP service, Kerberos KDC service, the location of the Global Catalog server, etc.  Without dynamic name service, Active Directory simply will not function (and in fact it won't even install).

Clearly, the easiest way to deal with Active Directory and DNS is to use fully dynamic name service.  In this case, all DNS functions are automatic and both clients and servers not only register what their functions are but their names and IP numbers ("A" records) as well.  Microsoft clearly prefers this model and it probably works very well in environments that are almost entirely Windows systems.

Here at Yale, we had a couple of situations that limited our ability to use fully dynamic name service:  First, we have BIND DNS servers maintained by DNO. Second, we had an AD design requirement that  DNO's name servers must be the sole source of IP number to host name mappings at Yale for security and other reasons.  Bringing up other DNS servers to accept "A record" registrations from systems automatically is against university policy.  Yale is not planning to switch to dynamic name service in the foreseeable future.

The dilemma is this: How do we reconcile this requirement for dynamic name service on one side versus the university's requirement of static name service for A records?

Before dealing with this directly, some explanation of how AD information is stored in DNS is necessary.

Active Directory DNS entries are made in four special "zones" that go along with each active directory domain.  These zones have the names _msdcs, _tcp, _udp and _sites.  If you have fully dynamic name service, these zones are created for you.  

So when there is an AD domain in play, there are two levels of DNS information:  The first is the "normal" DNS information consisting of IP number to host name mappings, and a second layer, under the four sub-zones, that is AD-specific information.

A Microsoft white paper (and other information) documents four models for managing Active Directory DNS information in the presence of BIND name servers:

1. Run the BIND servers in dynamic mode.  All dynamic functions are enabled so the AD performs in much the same way is if the DNS servers were Windows 2000 machines.  Typically, only a specific set of machines (usually the W2K domain controllers) are allowed to make changes to the DNS records because secure update is not supported.  BIND versions 4.9 and higher support dynamic update.
   
2. Use a combination of BIND and W2K DNS servers.  In this model, the BIND servers are in static mode and the Windows 2000 servers are dynamic.  The BIND ervers remain the authoritative name servers for theorganization.  Records of type NS ("delegation" records) are used so that the Windows servers handle all AD-specific traffic and BIND servers handle the rest.  This is also somewhat more secure because the W2K servers can run in "secure" mode so that changes to the DNS information must be authenticated.
   
3. Move all Active Directory activity into a separate DNS zone.  All machines that participate in the AD are moved into a DNS zone of their own, usually under the main DNS zone for the organization.  For example, an organization might make a DNS zone called "ad.company.com" under their main "company.com" DNS zone.  The Active Directory is then "rooted" at "ad.company.com".  This created a dichotomy between the DNS structure of the company and its AD structure in many cases, which has the potential for confusion.
   
4. Manually manage DNS information by hand-editing DNS tables to include SRV records for the critical services.  In this model, the DNS entries that would normally have been made automatically by the servers to register their functions with the AD are entered by hand into a static name server.  Since a single DC can make 30 or more entries in the DNS system, this quickly becomes a huge amount of work.  Also, since the information is dynamic, the AD loses some of its fault tolerance because the DNS system can not be updated automatically to reflect changes in the environment such as a server that is out of action or a role change.  This model would work in a very small domain that is extraordinarily stable, but is impractical for most real-world operations.

Yale uses the second model of operation.  In our case, we tell the name server for a DNS zone which matches up with an AD domain to refer these four specific zones to our new Windows 2000 server which is running dynamic DNS.  Therefore, when clients need to access any active-directory related information, which will be located in one of those four zones, they are handed off from DNO's name servers to a W2K name server which then handles the request and returns the correct information.

Some advantages of this are that the clients do not need to be aware of the Win2000 name server at all - their DNS configuration can remain exactly as it was before.  In addition, if the decision is ever made to go to dynamic name service, all they need to do is to remove those four delegation records which point to our server and their servers will handle all active-directory related information on their own with no changes necessary at all on the Windows 2000 side.

While this is not Microsoft's favorite  model for using DDNS -- they would obviously prefer that everyone replace all unix and/or NT4  DNS servers with shiny new Windows servers -- it is a documented and supported mode of operation and we have shown that it works fine.
 

Preparation of DNS before creating a new Active Directory Domain

[ Note: This section was part of a much longer document that was a step-by-step guide to bringing up a new Active Directory DC and making it a new subdomain of the root. ]

Active directory requires a properly configured DNS name space in order to work properly.  The ideal model is that the Active Directory domain hierarchy follows the existing name space of the organization exactly and that all name servers responsible for that hierarchy are fully cognizant of a mechanism called "dynamic update", which allows computers to automatically register records into the name server system instead of having those servers rely on static lists of information stored as text files on the server.

Windows 2000 includes a DNS server which supports Dynamic Update and all other name server functions.  In fact, Microsoft's preferred model of deployment is for you would be to purge all of your existing name servers from your organization and replace them with Windows 2000 servers running Microsoft's DDNS (Dynamic DNS) name server.

While this would probably work great for a Windows-centric organization, the situation here at Yale -- and in many other places -- is that there already is an existing infrastructure based on the Unix operating system and name servers running the BIND software.  Furthermore, Microsoft DNS servers do not have a track record anywhere near as long as unix ones so some people are unwilling to trust such a critical function to them.

Note that Dynamic Update is not a Microsoft-only feature - it's been around for a while and is supported by UNIX BIND as an optional feature.  Microsoft, however, is relying on it in order to make Active Directory function properly whereas in the past it has not been widely used.

One of the design requirements about name service at Yale is that the existing (unix) servers need to remain the primary source for the basic name-to-IP number ("A record") mappings that map IP numbers to specific machines.  This is called a "static" name service and updates to this information are strictly controlled.

Active Directory's DNS requirements are quite different -- it needs to use DNS (with the help of a record type called "SRV") to find other machines within the domain structure in a similar way to how WINS maps IP numbers to machine and domain names.  These SRV records need to be updated frequently (every couple of hours) and the information in them can change as machines change their roles in the network.

So how do we reconcile competing requirements for static information from one side and dynamic information from the other?  We need to find a way to make the Windows 2000 servers handle only the dynamic information and let the static servers handle the rest.  In order to do this we need to know a little about how Active Directory works with respect to DNS.

All of Active Directory's information is contained within DNS but it's only going to be used by AD-aware application and systems.  To segment the AD information from normal name server information, Microsoft has created four special zones that are used to store information about Active Directory domains, servers and services.  These zones are identified as follows:

_msdcs
_tcp
_udp
_sites

IMPORTANT: for Windows 2003 forests, you must also include these two additional zones:

DomainDnsZones
ForestDnsZones

[ BIND purists will note that the leading underscore is not in line with internet naming standards.  BIND will issue warnings when it encounters this character in a name but the warning can be disabled.  Unfortunately, this is the way that the system works and we can't do anything about it. ]

These zones are used mostly to store records of type "SRV".   SRV records indicate where Active Directory services are running within the hierarchy of domains that make up a forest.  Each domain, for example, has one or more Kerberos servers, one or more LDAP servers, and there is a unique "Global Catalog" that must be visible from anywhere in the forest.  The SRV records allow a client machine or application to ask a question like "show me the IP number of a machine running the LDAP server for the domain yourdomain.yale.edu", or "which machine is running the global catalog server in my enterprise?"

By arranging for a Windows 2000 name server to handle the AD zones, we can create a discontinuity in the DNS structure across which only AD information is handled - and put Windows 2000 servers on that side to handle that information.

To set this up, you  need to contact the person in charge of the DNS name server for the zone that matches your active directory domain (i.e. mydomain.yale.edu) and have them create "delegation" records for these four zones that point to your Windows 2000 server.  At Yale, this means contacting the hostmaster (hostmaster@net.yale.edu) These records do not affect the normal functioning of the DNS server and will not affect any computer which is not actually participating in the Active Directory because the authoritative name server will continue to handle all normal traffic.  What we want is for any AD-specific traffic to be "handed off" to our Windows 2000 server which will know what to do with it.

This is what the delegation entries look like on the unix name server.  If you substitute the correct name and domain name below, the name server maintainer can cut and paste these lines directly into their tables:

_msdcs IN NS myserver.mydomain.yale.edu
_tcp IN NS myserver.mydomain.yale.edu
_udp IN NS myserver.mydomain.yale.edu
_sites IN NS myserver.mydomain.yale.edu

IMPORTANT: for Windows 2003 forests, you must also include these two additional zones:

DomainDnsZones IN NS myserver.mydomain.yale.edu.
ForestDnsZones IN NS myserver.mydomain.yale.edu.

You also need to make sure that a normal internet "A" record is in place on the static name server which maps your machine's name to its correct IP number.

Here's how to test that these delegationsare in place and working:

On a unix or NT/Win2000 machine, start the 'nslookup' utility from a command prompt.  Then, enter this command:

> set type=ns

Then, query the four special zone names by entering them into nslookup.  You should receive a response like this:

> _msdcs.mydomain.yale.edu
Server:  serv1.net.yale.edu
Address:  130.132.1.9

Non-authoritative answer:
_msdcs.mydomain.yale.edu     nameserver = MYSERVER.MYDOMAIN.YALE.EDU

SERVER.MYDOMAIN.YALE.EDU    internet address = xxx.xxx.xxx.xxx
>

The response that you're looking for is the line highlighted in red.  It shows that the specified zone is served by the nameserver listed on that line.  You should get a valid response for all four zones, and all four zones should point back to your new server.  If a zone is not configured properly, you might get a response like this:

> _msdcs.mydomain.yale.edu
Server:  serv1.net.yale.edu
Address:  130.132.1.9

*** serv1.net.yale.edu can't find _msdcs.mydomain.yale.edu: Non-existent domain
>

This means that there is no entry in the name server matching the query you typed.  Either you mistyped the query or the name server hasn't been updated yet.