Planning, Implementing, and Maintaining a Name Resolution Infrastructure

In the domain name system (DNS), containers called domains hold the information. The hierarchy starts with a root container, called the root domain. The root domain doesn't have a name, so it is typically represented by a single period. The root domain contains pointers to all top-level domains (TLDs), which are directly below the root domain. They are also sometimes called first-level domains. Lower-level domains are second-level , third-level, and so on. Every domain name has a suffix that indicates which TLD domain it belongs to. There are only a limited number of such domains as defined by Request for Comments (RFC) 1591. Following are some of the more common TLDs:

.COM ” Intended for commercial entities, but it has become the overwhelming favorite top-level domain (example of .COM : area51partners.com )
.EDU ” Intended for higher-education institutions, such as four-year colleges and universities (example of .EDU : berkeley.edu )
.GOV ” Intended for use by agencies of the U.S. Federal Government (example of .GOV : whitehouse.gov )
.MIL ” Intended for use by agencies of the U.S. military (example of .MIL : af.mil )
.NET ” Intended for use by network providers and organizations dedicated to the Internet, such as Internet service providers (example of .NET : ibm.net )
.ORG ” Intended for nonprofit or noncommercial establishments, such as professional groups, charities, and other such organizations (example of .ORG : npr.org )

DNS is used to translate a hostname to an IP address. The fully qualified domain name (FQDN) typically looks something like the following:

 filesvr042.corporate.mcseworld.com

This is known as the host's FQDN because it lists the host's precise location in the DNS hierarchy. The DNS name in the example represents the host FILESVR042 in the subdomain CORPORATE (this is frequently a department or division in a company), which is in the subdomain MCSEWORLD (this is frequently the name of the company or organization that has registered the domain), which is in the TLD .COM .

Following are some questions you should ask yourself when planning your namespace needs:

Is your DNS namespace to be used for internal purposes only ? If so, you can use characters that are not typically used in DNS names , such as those outside the RFC 1123 standards. An example might be bigcorp.local .
Is your DNS namespace to be used on the Internet as well ? If you are currently using a corporate DNS namespace on the Internet, or think that you might at any point in the future, you should register your own domain name and conform to Internet naming standards.
Will you be implementing Active Directory ? The design and implementation of Active Directory on your network plays a critical role in determining how domains should be created and nested within each other.

You need to consider the following three basic options when planning the DNS namespace you will be using:

Use an existing DNS namespace ” This option uses the same namespace for both the internal (corporate network) and external (Internet) portions of your network. If your domain name is bigcorp.com , you would use this for both internal and external use. Although this method is the easiest and provides simple access to both internal and external resources, it poses additional administrative requirements because an administrator must ensure that the appropriate records are being stored on the internal and external DNS servers as a security precaution.
Use a delegated DNS namespace ” This option uses a delegated domain of the public namespace. If your domain name is bigcorp.com , you might consider using corp.bigcorp.com for the internal namespace. When you use this option, the corp.bigcorp.com domain becomes the root of the Active Directory forest and domain structure. Internal clients should be allowed to resolve external namespace addresses; however, external clients should not. Using a delegated DNS namespace provides a namespace that is easy to understand and remember and that fits in nicely with the existing registered domain name. All internal domain data is isolated in the domain or domain tree, thus requiring its own DNS server for the delegated internal domain. The downside to delegated namespaces is that this adds length to the total FQDN.
Use a unique DNS namespace ” This option uses a completely separate but related domain name for your internal namespace. As an example, if you are using bigcorp.com for your external namespace, you might use bigcorp.net for your internal namespace. This configuration provides the advantage of improving security by isolating the two namespaces from each other. Additionally, the administrative burden is relatively low because zone transfers do not need to be performed between the two namespaces, and the existing DNS namespace remains unchanged. In addition, this configuration prevents internal resources from being exposed directly to the Internet.

When creating DNS namespaces that are several levels deep, you must keep in mind some general DNS restrictions, as outlined in Table 6.

Table 6. DNS Name Restrictions

Restriction	Standard DNS	DNS in Windows Server 2003 (and Windows 2000)
Characters	Supports RFC 1123, which permits A to Z, a to z , 0 to 9, and the hyphen (-).	Supports several different configurations: RFC 1123 standard, as well as support for RFCs 2181 and the character set specified in RFC 2044.
FQDN length	Permits 63 bytes per label and 255 bytes for an FQDN.	Permits 63 bytes per label and 255 bytes for an FQDN. Domain controllers are limited to 155 bytes for an FQDN.

Although it is typically abbreviated in the world of DNS, a zone is actually a zone of authority , which means that it contains the complete information on some part of a domain namespace. In other words, it is a subset or root of that portion of namespace. The nameserver is considered to have authority for that zone, and it can respond to any requests for name resolution from that zone. So, when you look at the DNS name www.quepublishing.com , quepublishing.com is a DNS zone within the .com hierarchy. The www denotes the DNS record of a host contained within the quepublishing.com zone.

This conceptual representation of a zone also has a physical counterpart : All the information relating to a particular zone is stored in a physical file known as the zone database file , or more commonly the zone file , that can be found at %systemroot%\system32\dns for zones that are not stored in Active Directory. The following types of zones are supported by Windows Server 2003:

Standard primary ” A standard primary zone holds a master copy of a zone and can replicate it to all configured secondary zones in standard text format. Any changes that must be made to the zone are made on the copy stored on the primary.
Standard secondary ” A standard secondary zone holds a read-only copy of the zone information in standard text format. Secondary zones are created to increase performance and resilience of the DNS configuration. Information is transferred from the primary zone to the secondary zones.
Active Directory “integrated ” Active Directory “integrated zones are available only on Windows 2000 Server and Windows Server 2003 DNS servers in an Active Directory domain. The zone information is contained within the Active Directory database and is replicated using Active Directory replication. Active Directory “integrated zones provide an increased level of replication flexibility as well as security. Active Directory “integrated zones also operate in a multimaster arrangement because they are hosted within Active Directory itself; this way, any DNS server (domain controller) hosting the Active Directory “integrated zone can update the zone data.
Stub ” Microsoft has introduced support for stub zones for the first time in Windows Server 2003. A stub zone contains only those resource records that are necessary to identify the authoritative DNS servers for that zone. Those resource records include Name Server (NS), Start of Authority (SOA), and possibly glue host (A) records. (Glue host records provide A record pointers to ensure that the master zone has the correct nameserver information for the stub zone.)

When you are using a standard primary/standard secondary DNS zone implementation, the following points are of concern:

A single DNS server is the master, holding the only writable copy of the DNS zone file.
Zone transfers can be conducted using either incremental or full zone transfer.
This implementation is made fully compatible with BIND DNS servers by using the standard DNS zone transfer methods in place.

When you are using an Active Directory “integrated DNS zone implementation, the following points are of concern:

A multimaster arrangement allows any DNS server to make updates to the zone file.
Zone data is replicated with Active Directory data.
Increased security is provided on the zone file.
Redundancy is provided for DNS dynamic update.
The administrator can adjust replication scope. Additionally, the zone file can be replicated to a standard secondary DNS server ”a common practice for DNS servers placed on screened subnets.
This implementation appears to be a standard primary zone to a BIND DNS server, thus allowing the use of BIND DNS servers as standard secondary zone servers.

Table 7 provides a comparison of Active Directory “integrated zones and standard DNS zones.

Table 7. DNS Zone Type Comparison

DNS Feature	Standard DNS Zones	Active Directory “Integrated Zones
Complies with IETF specifications	Yes	Yes
Uses Active Directory for replication	No	Yes
Increases availability by providing a multi-master arrangement	No	Yes
Allows for zone updates after the failure of a single DNS server	No	Yes
Supports incremental zone transfers	Yes	Yes

Regardless of whether you create standard or Active Directory “integrated DNS zones, you should be aware of the benefits of also using standard secondary zones. Following are some of the benefits you can realize by placing secondary zones on your network:

The addition of standard secondary zone servers increases the redundancy of the zone by providing name resolution even if the primary zone server is unresponsive .
When remote locations are connected to the core network over WAN links, secondary zone servers can greatly reduce costs and network traffic. By placing standard secondary zones in these remote locations or in locations with a high number of clients, you can improve overall network performance.
Standard secondary zone servers reduce the load on the primary servers by distributing name resolution requests among more DNS servers.

Unlike WINS, which allows for a push/pull arrangement, zone transfers always originate with the secondary server polling the primary zone at the configured interval. It does so by checking the zone version number on the primary server to see whether it has changed in comparison to the version number on the secondary server. If the zone version number on the primary server has been incremented, a zone transfer is required and will be performed. If the secondary zone supports incremental zone transfers (which Windows Server 2003 does), the secondary zone pulls (from the primary zone) only the changes made to resource records for each incremental zone version ”meaning that a resource record could potentially be updated one or more times in a single zone transfer. When you use incremental zone transfers, network traffic is reduced and zone transfer speed is increased.

Windows Server 2003 supports two zone transfer types for standard zones: full zone transfers and incremental zone transfers. You might also see them abbreviated as AXFR and IXFR, respectively. A full zone transfer causes the entire zone data file to be transferred, which is a large user of both bandwidth and time.

Active Directory “integrated DNS zones replicate data among all domain controllers, allowing any domain controller to modify the zone file and replicate the changes to the rest of the domain controllers. This form of replication is known as multimaster replication because multiple DNS servers are allowed to update the zone data ”domain controllers that are running the DNS service in this case. Replication occurs on a per-property basis, meaning that only the relevant changes are replicated. Active Directory “integrated zones replicate only the final result of multiple changes to a resource record, unlike standard zones, which transfer the changes to a resource record that occurred in each zone version number.

In a TCP/IP network, a DNS resolver is any system that has been configured with one or more DNS server IP addresses and that performs queries against these DNS servers. The DNS resolver is part of the DNS Client service, which is automatically installed when Windows is installed. The resolver can request one of two types of queries from a DNS server: recursive or iterative.

A recursive query is a DNS query that is sent to a DNS server from a DNS resolver asking the DNS server to provide a complete answer to the query, or an error stating that it cannot provide the information. If the DNS server is also configured as a forwarder, the query can be forwarded directly to another DNS server. If the query is for a name outside the local DNS server's zone of authority, it performs an iterative query against a root DNS server, which then responds with the IP address of the DNS server whose zone of authority includes the desired IP top-level domain. Additional iterative queries are then performed until the name is resolved into its IP address or an error is produced.

An iterative query is a DNS query that is sent by a DNS server to another DNS server in an effort to perform name resolution. Consider the example of a workstation (DNS resolver) in the bigcorp.com domain that wants to communicate with a Web server located in the smallcorp.com domain .

A DNS forwarder is a DNS server that accepts forwarded recursive lookups from another DNS server and then resolves the request for that DNS server. This capability can be useful if you do not have local copies of your internal DNS zone and want to have your local DNS server forward DNS queries to a central DNS server that is authoritative for your internal DNS zone. Caching-only servers make good DNS forwarders. If the DNS forwarder does not receive a valid resolution from the server that it forwards the request to, it attempts to resolve the client request itself.

A DNS slave server is a DNS forwarder server that does not try to resolve a resolution request if it doesn't receive a valid response to its forwarded DNS request. You typically see this type of DNS server implemented in conjunction with a secure Internet connection.

A new feature in Windows Server 2003, conditional forwarding , enables administrators to direct DNS requests to other DNS servers based on domain. Previous versions of Microsoft DNS supported only one forwarder, so if forwarding were enabled, all requests would be sent to a single server. This feature is used frequently when you want requests made to the internal network to be forwarded to a master DNS server that stores internal DNS zones, but have resolution requests that are made to Internet domains be sent to the Internet using the standard resolution process.

A common implementation of DNS forwarders in a Windows Server 2003 network has one specific DNS server being allowed to make queries to DNS servers outside the firewall. This implementation allows the firewall to be configured to allow DNS traffic only from this specific DNS server to leave the protected network, and allows only valid replies back to the DNS server to enter the protected network. Through this approach, all other DNS traffic ”both inbound and outbound ”can be dropped at the firewall, adding to the overall security of the network and the DNS service.

Configuring DNS security can be broken into the following five general areas of concern:

Dynamic updates
Active Directory DNS permissions
Zone transfer security
DNS server properties
DNS Security (DNSSEC)

Dynamic updates occur when a DHCP server or a DNS client computer automatically updates the applicable DNS resource records when a DHCP lease is granted (or expires ). Three types of dynamic updates exist in Windows Server 2003, each with its own security specifics.

Secure dynamic updates are available when Active Directory “integrated zones are in use. Using secure dynamic update, the DNS zone information is stored in Active Directory and thus is protected using Active Directory security features. When a zone has been created as or converted to an Active Directory “integrated zone, Access Control List (ACL) entries can be used to specify which users, computers, and groups can make changes to a zone or a specific record.

If the zone is integrated with Active Directory, the Discretionary Access Control List (DACL) for the zone can be used to configure the permissions for the users and groups that may change or control the data in the DNS zone. Table 8 lists the default group and user permissions for Active Directory “integrated DNS zones. These default values can be modified to suit your particular needs.

Table 8. Default Group and User Permissions on Active Directory “Integrated DNS Zones

Group or User	Permissions
Administrators	Allow : Read, Write, Create All Child Objects, Special Permissions
Authenticated Users	Allow : Create All Child Objects
Creator Owner	Allow : Special Permissions
DnsAdmins	Allow : Full Control, Read, Write, Create All Child Objects, Delete Child Objects, Special Permissions
Domain Admins	Allow : Full Control, Read, Write, Create All Child Objects, Delete Child Objects
Enterprise Admins	Allow : Full Control, Read, Write, Create All Child Objects, Delete Child Objects
Enterprise Domain Controllers	Allow : Full Control, Read, Write, Create All Child Objects, Delete Child Objects, Special Permissions
Everyone	Allow : Read, Special Permissions
Pre-Windows 2000 Compatible Access	Allow : Special Permissions
System	Allow : Full Control, Read, Write, Create All Child Objects, Delete Child Objects

By default, Windows Server 2003 DNS performs zone transfers only with the DNS servers that are listed in a zone's Name Server (NS) resource records. Even though this configuration is fairly secure, you should consider changing this setting to allow zone transfers to be carried out only with specific IP addresses that you have explicitly configured.

If you must perform zone transfers across an untrusted network, you should consider implementing and using a virtual private network (VPN) tunnel between the two DNS servers. Encrypted zone information traveling inside the tunnel is safe from prying eyes, thus providing an uncompromised zone transfer. When using a VPN tunnel for zone transfer data, you should use the strongest possible level of encryption and authentication supported by both sides of the tunnel.

By default, Windows Server 2003 DNS servers use a secure response option that eliminates the addition of unrelated resource records that are included in a referral answer to the cache. The server typically caches any names in referral answers, thus expediting the resolution of subsequent DNS queries. However, when this feature is in use, the server can determine whether the referred name is polluting or insecure and discard it. The server thus determines whether to cache the name offered in the referral depending on whether it is part of the exact DNS domain tree for which the original name query was made. As an example, a query made for sales.bigcorp.com with a referral answer of smallcorp.net would not get cached.

It's a fact of life that many organizations already have existing DNS solutions in place, such as Unix BIND. In some cases, these existing BIND servers might not meet the DNS requirements of Active Directory. Table 9 outlines the features of some of the more common versions of BIND in use.

Table 9. Features of Various BIND Versions

BIND Version	Features
4.9.4	Support for fast zone transfers
4.9.6	Support for SRV resource records
8.1.2	Support for dynamic DNS (DDNS)
8.2.1	Support for incremental zone transfer (IXFR) between DNS servers
8.2.2	Full support for all Active Directory features

If you are dealing with other DNS systems, you have two basic choices of implementation:

Upgrade existing DNS systems to meet the DNS requirements of Active Directory. For BIND, versions 8.1.2 and later are sufficient.
Migrate existing DNS zones to Windows Server 2003 DNS.

Although it is recommended that you use only Windows Server 2003 DNS servers to ensure full support for Active Directory, you can use any DNS system that meets the following specifications:

Support for SRV (Service) resource records
Dynamic updates per RFC 2136

If you have Unix BIND servers in your DNS infrastructure, you should consider placing them as secondaries instead of primaries. By default, Windows Server 2003 DNS servers use a fast zone transfer format whereby compression is used and multiple records can be sent in a single TCP message. BIND versions 4.9.4 and later support fast zone transfers. If you are using an earlier version of BIND or another third-party DNS system that does not support fast zone transfers, you must disable fast zone transfers. When you select the BIND Secondaries option, fast zone transfers are disabled for that server. You also should configure your zones to not transfer WINS-related information during zone transfers to these secondary servers.

In most environments that rely on WINS for name resolution for legacy systems, it is important to ensure that more than one WINS server exists so that you provide redundancy and availability. To ensure that each server has a current copy of the database, you need to configure replication between your WINS servers. You can configure the following types of replication for the WINS service:

Pull replication ” In pull replication, your server pulls the database from the replication partner. A pull replication is time based and occurs at the time you have configured. You can decide whether to establish a persistent connection for replication, and you can set the start time and interval for replication.
Push replication ” In push replication, your server pushes its database to the replication partner. A push replication is event driven, and the number of database updates determines when the event occurs. You can decide whether to use a persistent connection for push activities, and you can set the number of changes in version ID before replication.
Replication partner type ” The partner type can be push, pull, or push/pull, depending on your requirements. (In push/pull replication, database replication can occur using either method ”push or pull.)

Microsoft TCP/IP uses NetBIOS over TCP/IP (NetBT) as specified in RFC 1001 and 1002 to support the NetBIOS client and server programs in the local area network (LAN) and wide area network (WAN) environments. Before we look at the specifics of NetBIOS name resolution, let's briefly review how computers communicate on the network. This review should help you understand how the different NetBIOS modes work and why some are preferable to others.

Computers can use two ways to communicate on a network:

Through broadcast messages, which every computer receives
Through directed messages, which are sent to a specific computer

Although networks can be organized using a mixture of node types, Microsoft recommends against doing so. B-node client computers ignore P-node directed messages, and P-node client computers ignore B-node broadcasts. Therefore, it is conceivable that two client computers could separately be established with the same NetBIOS name. If WINS is enabled on a Windows 2000 or XP computer, the system uses H-node by default. Without WINS, the system uses B-node by default. Non-WINS client computers can access WINS through a WINS proxy, which is a WINS-enabled computer that listens to name query broadcasts and then queries the WINS server on behalf of the requesting client computer.

The actual configuration of a computer to use LMHOSTS for NetBIOS name resolution is not done by using the WINS console or a Group Policy Object, as you might expect. Instead, you must actually configure it computer by computer by setting the options available to you on the WINS tab of the Advanced TCP/IP Settings dialog box.