DNSConcepts | Windows Server 2003 in a Nutshell

DNSConcepts

DNS is the backbone of Active Directory for two reasons: domains are named using DNS and domain controllers are located using DNS. So if DNS is not set up properly, client computers will not be able to locate domain controllers and users will be unable to log on to the network and access resources. Since DNS is critical to the operation of WS2003-based networks, I'll begin by briefly reviewing basic DNS concepts while keying in on various issues relating to DNS on WS2003. For a more detailed look at DNS on Microsoft platforms, see DNS on Windows 2003 (O'Reilly).

How DNS Works

DNS is a client/server, Internet-standard protocol that implements a hierarchical naming system using a distributed database for associating names of hosts with IP addresses. This database is stored on DNS servers in the form of zones containing resource records, and DNS clients query these servers to resolve hostnames into IP addresses. DNS queries can be issued by DNS clients to DNS servers or by DNS servers to other DNS servers, and this system of queries is an essential part of the name -resolution process.

Let's unpackage that brief description in more detail.

DNS Namespace

The DNS namespace is hierarchical in structure and starts with a root domain represented by a period. Beneath the root domain are top-level domains, which are either functional ( .com , .org , .edu , and so on) or geographical ( .us , .ca , .uk , and so on). Beneath these top-level domains are second-level domains, usually simply called domains, which can be registered by individuals, companies, or organizations. An example is microsoft.com , which Microsoft Corporation has registered under the .com top-level domain. Organizations that have registered a domain name have the right to subdivide it any way they like into third-level domains, usually called subdomains. An example of a subdomain is msdn.microsoft.com , which Microsoft uses for the Microsoft Developer Network.

An individual host (a computer, router interface, network printer, or anything else having an IP address) is uniquely described within the DNS namespace by its fully qualified domain name (FQDN). For example, a computer whose hostname is bob and belongs to the sales subdomain of the mtit.com domain would have the FQDN bob.sales.mtit.com . FQDNs can consist only of the letters a-z and A-Z, the numbers 0-9, and the dash (-) symbol if they are to be RFC 1123-compliant, and this is important if your Microsoft DNS server needs to interoperate with another name server such as a Unix system running BIND.

DNS has several advantages over plain old IP addressing. FQDNs are easier to remember than IP addresses, and the hierarchical structure of the DNS namespace makes it easier to search for a particular host. Also, by organizing your hosts into a series of domains and subdomains, you can distribute management of your hosts across different DNS servers by creating zones. That way, instead of requiring that each DNS server contain and manage the entire DNS database, each DNS server can manage a portion of the distributed DNS database.

Resource Records

The DNS namespace is implemented as a distributed database containing resource records that map the FQDN of each host on the network to its IP address. They are called resource records because they are records of the resources (servers, gateways, and so on) on your network. Some important types of resource records include:

SOA (start of authority) record: Each zone has one SOA record that identifies which DNS server is authoritative for domains and subdomains in the zone.
NS (name server) record: An NS record contains the FQDN and IP address of a DNS server authoritative for the zone. Each primary and secondary name server authoritative in the domain should have an NS record.
A (address) record: By far the most common type of resource record, an A record is used to resolve the FQDN of a particular host into its associated IP address.
CNAME (canonical name) record: A CNAME record contains an alias (alternate name) for a host. For example, if a server functioned as both a web server and an FTP server, its A record might use the FQDN www.mtit.com , while the CNAME record might specify ftp as an alias for www . CNAME records can also be used to hide the true names of hosts on your network from external clients.
PTR (pointer) record: The opposite of an A record, a PTR record is used to resolve the IP address of a host into its FQDN.
SRV (service) record: An SRV record is used by DNS clients to locate a server that is running a particular servicefor example, to find a domain controller so you can log on to the network. SRV records are key to the operation of Active Directory.
MX (mail exchange) record: An MX record points to one or more computers that process SMTP mail for an organization or site.

DNS Servers

The backbone of any DNS implementation is the collection of DNS servers (or name servers) that contain the distributed DNS database. The main job of a name server is to resolve the names of hosts into their IP addresses. There are four different types of DNS servers you can deploy:

Primary name server: A name server that maintains the writable copy of the zone information for a zone. There can be only one primary name server for each zone.
Secondary name server: A name server that has a read-only copy of the zone information for a zone. A secondary name server gets its zone information from a master name server by a process called zone transfer. Each zone can have zero, one, or several secondary name servers to provide fault tolerance in case the primary server goes down. Secondary servers can also be used to reduce the load on primary servers; they can be deployed at branch offices to prevent clients from trying to perform name resolution over slow WAN links using primary name servers at company headquarters.
Master name server: Any name server configured to allow secondary name servers to download zone information. A master name server can be either a primary or secondary name server.
Caching-only name server: A name server that doesn't have any zone information. Instead, these servers cache the results of name queries and use this information to answer other queries. Caching-only name servers are useful in reducing unwanted WAN traffic. For example, say you have a primary name server located at company headquarters and configure a caching-only name server at a smaller branch office that is connected to headquarters over a slow WAN link. If clients at the branch office use DNS to issue name queries, the caching-only name server receives the requests and uses the WAN link to query the primary name server for the information. When the primary server returns a response, the caching-only server passes it on to the client but caches it in case it is requested later by another client. This reduces the WAN traffic that would occur if no name server was located at the branch office.

Note that a master name server can be either a primary or a secondary name server. In other words, secondary name servers can download their zone file from either a primary name server or another secondary name server. Note also that a name server can be a primary name server for one zone while being a secondary name server for another zone. In other words, each DNS server can service multiple zones and have different roles in different zones.

Zones

A zone is a contiguous (unbroken) subtree of the DNS namespace managed by name servers authoritative for that zone. For example, a zone might include a domain ( mtit.com ) and several subdomains ( sales.mtit.com and marketing.mtit.com ) but exclude other subdomains ( accounting.mtit.com and support.mtit.com ). Each zone has one primary name server that is authoritative over the zone and zero, one, or more name servers that are associated with the zone but aren't authoritative.

Name servers that are member servers use standard zones that store their zone information in ASCII files called zone files. A standard primary zone has a writable copy of the zone file while a standard secondary zone has a read-only copy. Name servers that are also domain controllers running WS2003 can use either standard zones or Active Directory-integrated zones. An Active Directory-integrated zone stores its zone information in Active Directory, which has several advantages over standard zones:

Zone transfers are subsumed into Active Directory replication, a process that is more efficient than traditional DNS zone transfers using standard zones. This also means there is only one replication topology to configure instead of two.
All name servers are primary name servers and can therefore have zone information directly modified on them. This provides fault tolerance compared to traditional DNS where, if a primary name server goes down, you have to promote a secondary name server to take its place.
Storing zone information in Active Directory is more secure as it prevents unauthorized clients from performing dynamic updates.

Zone transfers can be performed between standard and Active Directory-integrated zonesfor example, between WS2003 name servers and Unix BIND machines or legacy NT DNS servers.

Regardless of how zone information is stored, you can create three types of zones:

Forward-lookup zone: Contains mostly A records for resolving FQDNs into IP addresses when clients issue forward-lookup queries. Also contains an SOA record that defines the zone; NS records that specify authoritative name servers for the zone; and possibly other kinds of resource records such as SRV, MX, or CNAME.
Reverse-lookup zone: Contains mostly PTR records for resolving IP addresses into FQDNs when clients issue reverse-lookup queries (rare) or when administrators use nslookup to troubleshoot name-resolution problems (more common). Reverse lookups don't try to search all DNS namespaces to resolve their IP address into an FQDN; instead, they use a special DNS domain called in-addr.arpa , which uses a reverse ordering of the dotted IP address notation to identify hosts and stores this information in PTR records.
Stub zone: Contains only those resource records (SOA, NS, and possibly A records) needed to identify the authoritative name servers for that zone. Stub zones are new to WS2003. Stub zones help manage DNS query traffic by enabling local name servers to know the names and addresses of remote name servers authoritative for a given zone without requiring the local name server to have a copy of the information in that zone.

Zone Transfers

Zone transfer is the process by which zone information is replicated between name servers. Zone transfer ensures that all name servers for a zone have identical copies of the zone information, which enables clients to use any name server for the zone to perform name resolution. In DNS on NT, zone files were updated by a process called full zone transfer. This meant that when a DNS administrator updated one or more resource records in the primary zone, the full zone file would be replicated from the primary name server to any secondary name servers for the zone. This wasted network bandwidth, and WS2003 uses incremental zone transfer, in which only changes to the zone files are updated. Incremental zone transfer initiates when any of the following events occurs:

The master server for a zone notifies all secondary name servers for the zone that records have changed in its zone file and that they need to request an update. The process used by the master name server to notify secondary name servers is called DNS Notify. The secondary name servers then contact their master name server requesting the updates for their zone files.
The DNS Server service on a secondary name server starts up or is restarted. The secondary name server then contacts the designated master name server for the zone, requesting the updates for its zone file.
The refresh interval configured on the secondary server expires . The secondary name server then contacts the master name server for the zone, requesting the updates for its zone file.

Note that name servers using incremental transfer require additional disk space to maintain a version history of their zone filesin effect, a DNS transaction log.

Resolvers

A resolver is software running on a client computer that enables the computer to communicate with name servers to resolve FQDNs into IP addresses. In other words, a name server represents the server side of DNS while a resolver represents the client side. The WS2003 resolver is a caching resolver servicewhen a name is resolved, the results are cached locally by the client in case it needs to resolve the name again in the immediate future (before the time-to-liveor TTLof the resolved entry expires). WS2003 resolvers also cache negative name-query responses (failure to resolve a name).

Resolvers must be configured with the IP address of the name servers they will use to perform name resolution. This may be done either manually (for static IP addressing) or dynamically using DHCP.

Name Queries

A name query is a request for resolving a name into an IP address. Name queries may be issued by resolvers to name servers, or by name servers to other name servers. There are two types of queries:

Iterative query

When a DNS client or server issues an iterative query to a DNS server, the server must respond with its best current answer without contacting any other servers itself. This best answer is either:

The requested information (typically the IP address associated with the FQDN sent in the query). If this response is returned, the client is satisfied because it has what it wants.
A time-out or error message. If this is the case, the client is satisfied because an authoritative answer was received. However, since the answer was "I don't know," the desired network communications can't take place.
A pointer to an authoritative DNS server that is located one level down in the hierarchical DNS namespace. This kind of response is known as a referral . If a referral is returned, the client goes on to interactively query the lower name server. This process continues until one of the two previous responses is received by the client.

Recursive query

When a client or server issues a recursive query to a DNS server, the server that receives the query takes on full responsibility for finding an answer to the client's request and does so iteratively querying other DNS servers until it has an answer or receives an error or time-out message. Whatever the result of the process, it is passed to the client.

Recursive queries are used by:

DNS clients (resolvers), such as those running on XP Professional or other desktop Microsoft Windows operating systems.
DNS servers that are configured to forward unresolved names to another DNS server. A DNS server that has been configured to perform recursive instead of iterative queries is called a forwarder because it forwards queries for resolving FQDNs outside of its domain to a different DNS server.

Dynamic Updates

Dynamic updates is a process that enables resolvers to automatically update their associated resource records on their zone's primary name server. This is a big improvement over traditional DNS, in which administrators had to manually create and update resource records in zone files. Dynamic DNS can be used with both standard and Active Directory-integrated zones and can be used in conjunction with DHCP to make administering DNS even easier. Depending on how dynamic updates have been configured, either the DHCP client itself updates its records on the DNS server or the DHCP server updates the client's records for it.

Using Dynamic DNS with Active Directory-integrated zones enables resource records on name servers to be automatically updated more securely than when using standard primary and secondary zones. This works because only clients and servers that have been authorized in Active Directory can update their own records on the DNS server.

Delegation

You can also create subdomains in a domain and then delegate authority over those subdomains to different name servers. This lets you delegate the task of administering DNS for each subdomain to different name servers. For example, in the large enterprise mtit.com domain, there might be several subdomains such as ontario.mtit.com , quebec.mtit.com, bc.mtit.com , and so on. You can have one or more DNS servers to service each geographical location within the enterprise and make them authoritative over their own subdomain.

Planning DNS

Let's now look at planning issues related to DNS and Active Directory. There are three basic approaches to implementing a DNS namespace with Active Directory. I'll examine each of them briefly.

Single-Name Approach

In this approach, your existing DNS name is used for both the forest root domain of your internal (Active Directory) network and for your external servers connected to the Internet. For example, if your company has the registered domain name mtit.com and you want to migrate your NT network to WS2003, you could choose mtit.com as the name of your forest root domain. The advantage of this solution is that it is the simplest form of namespace to adopt. The disadvantage is that you would need to consider carefully how to secure your private corporate network from the Internet since both your private and public servers use the same naming system. The solution is to implement a firewall/proxy server with identical DNS zones created on your internal and external name servers. Your internal DNS server needs resource records for all the IP hosts on your private network, including special records to support Active Directory. Using a WS2003 DNS server is a good choice for your private network, since it fully supports Active Directory's features. Your external DNS server needs only those web servers and other hosts that you maintain outside your firewall for public access, and it can be either Microsoft DNS or BIND. You can then configure your internal name server to forward client requests for Internet resources to your external name server.

The advantages of this approach are:

Users need to remember only a single domain name when they want to access your company's resources, whether within the private corporate intranet or on your public Internet servers.
You need to register only one company name with your domain name registrary.

The disadvantages are:

The additional DNS administration work involved in making sure internal and external DNS servers contain only the records they are supposed to have
The complexity of reconfiguring your firewall
The fact that if you maintain some resources on both your internal and external networks, you need to figure out how to keep them synchronized properly

Double-Name Approach

In this approach, your existing DNS issued name for your public (external) servers connected to the Internet and a second DNS name for the forest root domain of your internal network is obtained. For example, you could use the DNS domain name mtit.com for your public web servers and register a new second name such as mtitenterprises.com to use for your internal network. You can then configure your internal name server to use your external server (typically your ISP's name server) as a forwarder for name resolution on the Internet. Note that when you use the Configure Your Server Wizard to install DNS on WS2003, it checks to see if your network is connected with the Internet. If it is, it creates a root hints file called Cache.dns that contains the addresses of the Internet's root name servers, and as a result you don't need to configure a forwarder to resolve hosts on the Internet. However, you may still want to configure a forwarder to increase performance and reduce DNS query traffic over your Internet connection.

If Configure Your Server can't detect an Internet connection, it may create a root (.) forward-lookup zone on your server to designate your server as a root name server! As a result, you may not be able to resolve hosts on the Internet even with a forwarder configured. The solution is to delete the root zone.

A variant of this approach is to use your existing DNS name ( mtit.com ) for your public presence and a local DNS name such as mtit.local for your internal network. The .local suffix is not part of the Internet's DNS system, and as a result clients on the Internet are unable to resolve and access hosts on your internal network and can resolve and access only public hosts on your DMZ. This provides an added layer of protection for your internal network by isolating it from the Internet, and if you use Manage Your Server to add the Typical First Server role to your first WS2003 machine, the Configure Your Server Wizard suggests this approach.

The advantages of this approach are:

The DNS naming hierarchy of your private WS2003 domains, trees, and forests is hidden from external users on the Internet. The security of your network resources is greater because internal and external resources are clearly distinguished by belonging to different DNS domains.
You can leave your existing corporate DNS naming hierarchy and zone files (if implemented) intact and simply upgrade your NT DNS servers to WS2003.

The disadvantages are:

You may need to register a second DNS domain name for your company with ICANN (unless you use the .local approach).
Some users might be confused by the fact that your company has two DNS domain names. Which one should they use?

Subdomain Approach

In this approach, your existing DNS domain name is used for your public servers connected to the Internet and for the legacy portion of your internal network that you don't plan to migrate to WS2003, and then a subdomain is created for the portion of your private network that you plan to upgrade to WS2003 and as the name for your WS2003 root domain in Active Directory. This might be the best approach in a heterogeneous network in which you migrate only a portion of your network to WS2003, especially if DNS is already configured on your existing network. For example, say your existing network uses the DNS name mtit.com , and you want to install Active Directory on a portion of your network. In this case you could create a DNS subdomain such as windows.mtit.com and make this the name of your new WS2003 root domain. Note that it might be better to use windows.mtit.com than win2003.mtit.com in case you decide to upgrade your network to Windows 2006 later on!

To make this happen, you need to:

Create a DNS zone for windows.mtit.com , preferably on a WS2003 name server since it will support Active Directory.
Create a delegation record on the existing name server that is authoritative for your mtit.com domain. The delegation record will indicate that authority for the windows.mtit.com subdomain is delegated to your WS2003 name server.
Install Active Directory with windows.mtit.com as your forest root domain.

The advantages of this approach are:

It provides a contiguous namespace for Active Directory, which you can easily administer.
It doesn't necessitate the upgrade of your existing DNS servers, so you can keep your good old BIND servers if you like.
You can leave your firewall pretty much the way it is right now.

The main disadvantage is that it takes longer for your DNS naming structure to name resources on your WS2003 network. This is only a minor bother, however, unless your domain name is something like wishicouldthinkofabetterdomainnamethanthis.com !

BIND and WS2003

Most name servers on the Internet and in large enterprises with heterogeneous networks are Unix machines running BIND, which stands for Berkeley Internet Name Domain. Recent versions of BIND are compatible with Active Directory, and you can elect to keep your existing BIND name servers if you like when deploying WS2003 on your network. The procedures for integrating BIND with Active Directory aren't trivial, however, and there are several ways you can approach the issue of integrating existing BIND name servers and Active Directory:

You can use BIND exclusively, an approach your DNS administrator may prefer. You should use BIND 8.2.1 or later if you plan to keep your BIND servers and not implement WS2003 name servers. This is because BIND 8.2.1 supports Dynamic DNS (DDNS), SRV resource records, incremental zone transfers, and negative cachingall features supported by Active Directory. However, BIND doesn't support WINS or WINS-R records, which may be needed if you need to integrate WINS with DNSfor example, if part of your network will continue to use NT. If you want to use a BIND name server for the forest root domain of Active Directory, you need to create special subdomains like _msdcs.<domainname> , _sites.<domainname> , _tcp.<domainname> , and _udp.<domainname> , where <domainname> is the DNS name you registered for your company. These special subdomains are used by Active Directory to store various configuration information on the DNS server. See the Deployment Planning Guide of the Windows Server 2003 Resource Kit for more information.
You can use WS2003 name servers exclusively. This is the simplest solution from the point of view of WS2003 but requires an upheaval of your existing BIND name servers and DNS administration scheme, plus the retraining of your DNS administrators. With the proven stability of BIND, your DNS administrators may try to talk you out of this approach.
You can use Windows name servers for your internal network and BIND name servers for name resolution on the Internet. This might be the best solution, and it doesn't even require upgrading your BIND servers. What you can do here is register a second DNS name and use this as your forest root domain in Active Directory. You can then leave your BIND server to manage DNS for the portion of your network you don't plan to migrate to WS2003 and to manage DNS for your Internet hosts. Then create a secondary zone on your BIND name server for your WS2003 domain and a secondary zone on your WS2003 DNS server for your BIND server's domain.
You can use BIND for both the internal and external network and configure your WS2003 root domain as a subdomain of your company's existing DNS domain. This might be a good solution if you are planning to migrate some (but not all) of your network to WS2003. On the BIND server, you then delegate authority for the WS2003 subdomain to Active Directory, which manages the delegated portion of DNS namespace for the network. You must be running BIND 8.2.1 or later if you go this route, however. What you need to do is create a delegation record on your BIND name server for the new subdomain and then configure the WS2003 DNS server to use the subdomain as the root domain for Active Directory.

For more information on BIND, see DNS and BIND by Paul Albitz and Cricket Liu (O'Reilly).