Lesson 4: Designing a Name Resolution Structure for a TCPIP Network

DNS is a distributed database used in TCP/IP networks to translate computer names (host names) to IP addresses. DNS is most commonly associated with the Internet. However, private networks use DNS extensively to resolve computer host names and to locate computers within their local networks and the Inter- net. DNS name resolution is different from the name resolution provided by Windows Internet Naming Service (WINS). WINS resolves NetBIOS names to IP addresses, but DNS resolves IP hostnames to IP addresses. This lesson introduces you to DNS and the name resolution process used by Windows 2000. The lesson also provides information on how to design a DNS namespace for a network that supports Internet connectivity.

After this lesson, you will be able to

• Describe the DNS Service in Windows 2000
• Design a DNS hierarchy and naming structure for a Windows 2000 network connected to the Internet

Estimated lesson time: 25 minutes

DNS Hierarchy and Naming

DNS is the name service used in Windows 2000 networks. It is by design a highly reliable, hierarchical, distributed, and scalable database. Windows 2000 clients use DNS for name resolution and service location, including locating domain controllers for logon. DNS in Windows 2000 provides a unique DNS Server implementation that’s fully interoperable with other standards-based implementations of DNS Server. You can integrate Windows 2000 DNS into Active Directory so that it uses the Windows 2000 multimaster replication engine.

DNS Structure

DNS is implemented as a hierarchical and distributed database containing various types of data, including host names and domain names. The names in a DNS database form a hierarchical tree structure called the domain namespace.

DNS Hierarchy

Domain names consist of individual labels separated by dots, such as mydomain.microsoft.com. A name such as mydomain.microsoft.com is referred to as a fully qualified domain name (FQDN). An FQDN uniquely identifies the host’s position within the DNS hierarchical tree by specifying a list of names (separated by dots) on the path from the referenced host to the root. Figure 2.15 shows an example of a DNS tree with a host called mydomain located within the microsoft.com domain. The FQDN for the host would be mydomain.microsoft.com.

Figure 2.15 - A DNS tree with a host named mydomain within the microsoft.com domain

DNS and the Internet

The Internet DNS is managed by a name registration authority on the Internet that’s responsible for maintaining top-level domains that are assigned by organization and by country/region. These domain names follow the International Standard 3166. The existing abbreviations are listed in Table 2.5.

Table 2.5 Top-Level Domains

DNS Domain Name	Type of Organization
com	Commercial organizations
edu	Educational institutions
org	Nonprofit organizations
net	Networks (the backbone of the Internet)
gov	Nonmilitary government organizations
mil	Military government organizations
num	Phone numbers
arpa	Reverse DNS
xx	Two-letter country/region code

DNS Resource Records

A DNS database is made up of resource records (RRs). Each RR identifies a particular resource within the database. There are various types of RRs in DNS. Table 2.6 provides information on the structure of some of the common RRs. They’re part of the Internet (IN) class of RRs.

Table 2.6 Common RRs

Description	TTL	Type	Data Options
Start of Authority	Default TTL is 60 minutes	SOA	Owner Name, Primary Name Server DNS Name, Serial Number, Refresh Interval, Retry Interval, Expire Time, Minimum TTL
Host	Zone (SOA) TTL	A	Owner Name (Host DNS Name), Host IP Address
Name Server	Zone (SOA) TTL	NS	Owner Name, Name Server DNS Name
Mail Exchanger	Zone (SOA) TTL	MX	Owner Name, Mail Exchange Server DNS Name, Preference Number
Canonical Name (an alias)	Zone (SOA) TTL	CNAME	Owner Name (Alias Name), Host DNS Name

DNS Zones

You can partition a DNS database into multiple zones. A zone is a portion of the DNS database that contains the RRs with the owner names that belong to the contiguous portion of the DNS namespace. Zone files are maintained on DNS servers. You can configure a single DNS server to host zero, one, or multiple zones.

Each zone is anchored at a specific domain name, which is referred to as the zone’s root domain. A zone contains information about all names that end with the zone’s root domain name. A DNS server is considered authoritative for a name if it loads the zone containing that name. The first record in any zone file is a Start of Authority (SOA) RR. The SOA RR identifies a primary DNS name server for the zone as the best source of information for the data within that zone and as an entity that processes the updates for the zone.

You can also delegate names within a zone to other zones. Delegation is a process of assigning responsibility for a portion of a DNS namespace to a separate entity. This separate entity could be another organization, department, or work-group within your company. In technical terms, delegating means assigning authority over portions of your DNS namespace to other zones. Such delegation is represented by the NS record that specifies the delegated zone and the DNS name of the server that’s authoritative for that zone. Delegating across multiple zones was part of the original design goal of DNS.

In Figure 2.16, the management of the microsoft.com domain is delegated across two zones: microsoft.com and mydomain.microsoft.com.

Figure 2.16 - Delegating a domain across two zones

If multiple NS records exist for a delegated zone identifying multiple DNS servers available for querying, the Windows 2000 DNS server will be able to select the closest DNS server based on the round-trip intervals measured over time for every DNS server.

DNS Replication

Multiple zones can represent the same portion of a namespace. In this situation there are two types of zones: primary and secondary. A primary zone is one in which all updates for the records that belong to that zone are made. A secondary zone is represented by a read-only copy of the primary zone. The changes made to the primary zone file are then replicated to the secondary zone file.

A name server can host multiple zones. A server can therefore be primary for one zone (it has the master copy of the zone file) and secondary for another zone (it gets a read-only copy of the zone file).

The process of replicating a zone file to multiple name servers is called zone transfer. Zone transfer is achieved by copying the zone file information from the master server to the secondary server. A master server is the source of the zone information. The master server can be primary or secondary. If the master is primary, then the zone transfer comes directly from the source. If the master server is secondary, the file received from the master server by means of a zone transfer is a copy of the read-only zone file.

The zone transfer is initiated in one of the following ways:

• The master server sends a notification (RFC 1996) of a change in the zone to the secondary server.
• When the secondary server’s DNS service starts or the secondary server’s refresh interval (15 minutes by default) has expired, it will query the primary server for the changes.

DNS and Active Directory

You can’t install Active Directory without having DNS on your network, because Active Directory uses DNS as its location service. However, you can install DNS without Active Directory. If you install DNS on a domain controller, you can also choose whether or not to use Active Directory to provide storage and replication for DNS. Using Active Directory for storage and replication provides the following benefits:

• Increased fault tolerance
• Security
• Easier management
• More efficient replication of large zones

In addition to storing zone files on DNS servers, you can store a primary zone in Active Directory. When you store a zone in Active Directory, zone data is stored as Active Directory objects and replicated as part of Active Directory replication.

Active Directory replication provides an advantage over standard DNS alone. With standard DNS, only the primary server for a zone can modify the zone. With Active Directory replication, all domain controllers for the domain can modify the zone and then replicate the changes to other domain controllers. This replication process is called multimaster replication because multiple domain controllers, or masters, can update the zone.

In multimaster replication, any domain controller can send or receive updates of information stored in Active Directory. Replication processing is performed on a per property basis, which means that only relevant changes are propagated. Replication processing differs from DNS full zone transfers, in which the entire zone is propagated. Replication processing also differs from incremental zone transfers, in which the server transfers all changes made since the last change. With Active Directory replication, however, only the final result of all changes to a record is sent.

When you store a primary zone in Active Directory, the zone information is replicated to all domain controllers within the Active Directory domain. Every DNS server running on a domain controller is then authoritative for that zone and can update it.

Although you can still perform standard zone transfers with Active Directory–integrated zones, Active Directory multimaster replication provides greater fault tolerance than using standard zone transfers alone. Standard zone transfers and updates rely on a single primary DNS server to update all the secondary servers. With Active Directory replication, however, there’s no single point of failure for zone updates.

In an integrated zone, domain controllers for each of your Active Directory domains correspond in a direct one-to-one mapping to DNS servers. When you troubleshoot DNS and Active Directory replication problems, the same server computers are used in both topologies, which simplifies planning, deployment, and troubleshooting.

Using directory-integrated storage also simplifies dynamic updates for DNS clients that are running Windows 2000. When you configure a list of preferred and alternate DNS servers for each client, you can specify servers corresponding to domain controllers located near each client. If a client fails to update with its preferred server because the server is unavailable, the client can try an alter- nate server. When the preferred server becomes available, it loads the updated, directory-integrated zone that includes the updates that the client made.

If you’re not using Active Directory, you need standard primary zones to create and manage zones in your DNS namespace. In this case a single-master update model applies, with one DNS server designated as the primary server for a zone. Only the primary server, as determined in the SOA record properties for the zone, can process an update to the zone. For this reason, make sure that this DNS server is reliable and available. Otherwise, clients can’t update their A or PTR RRs.

Active Directory is discussed in more detail in Chapter 8, "Directory Services."

Internet Access

For your organization to be visible on the Internet, you must have an external namespace (public namespace) that anyone on the Internet can access. However, to help prevent malicious access to your network, you can use an internal namespace (private namespace) that only users within your organization can see, thus preventing unauthorized people from learning the names and IP addresses of the computers on your network.

If you plan to have both an internal and external namespace, you must configure your DNS servers to enable internal clients to resolve names in both namespaces. How you plan your namespace depends on the type of clients that you have.

Planning the Namespace

When planning your namespace, you must decide whether to use a private root and whether you want your internal and external namespaces to have the same domain name. Whether you can use a private root depends on the type of clients you have. You can use a private root only if each of your clients has one of the following:

• Name exclusion list A list of DNS suffixes that are internal
• Proxy autoconfiguration (PAC) file A list of DNS suffixes and exact names that are internal or external

If you have clients lacking both of these, the DNS server hosting your organization’s top-level internal domain must forward queries to the Internet.

Table 2.7 shows whether you can use a private root, based on the your client’s proxy capability.

Table 2.7 Using Private Roots

	No Proxy	Local Address Table (LAT)	Name Exclusion List	PAC File
Microsoft software with corresponding proxy capability	Generic Telnet	Windows Sockets Proxy (WSP) 1.x, WSP 2.x	WSP 1.x, WSP 2.x, and all versions of Internet Explorer	WSP 2.x, Internet Explorer 3.01 and later
Must you forward queries?	Yes	Yes	No, but you can if you want	No, but you can if you want
Can you use a private root?	No	No	Yes	Yes

To simplify name resolution for internal clients, use a different domain name for your internal and external namespaces. For example, you can use the name contoso-ext.com for your external namespace and contoso.com for your internal namespace. You can also use the name contoso.com for your external namespace and noam.contoso.com for your internal namespace. However, you should not make your external domain a subdomain of your internal domain; that is, in the context of this example, don’t use contoso.com for your internal namespace and noam.contoso.com for your external namespace.

You can use the same name internally and externally, but doing so causes configuration problems and generally increases administrative overhead. If you want to use the same domain name internally and externally, you need to perform one of the following actions:

• Duplicate internally the public DNS zone of your organization.
• Duplicate internally the public DNS zone and all public servers (such as Web servers) that belong to your organization.
• Maintain a list (in the PAC file on each of your clients) of the public servers that belong to your organization.

Make sure that the domain name for your internal namespace isn’t used anywhere on the Internet. Otherwise you might have problems with ambiguity in the name resolution process.

Which action you need to perform to use the same domain name internally and externally varies. Table 2.8 shows whether you can use the same domain name for your internal and external namespaces, and if so, which method you must use, based on your client software proxy capability.

Table 2.8 Internal and External Namespaces

	No Proxy	LAT	Name Exclusion List	PAC file
Use different domain names	Yes	Yes	Yes	Possible (by using simple exclusion)
Use the same domain name; internally duplicating organization’s public DNS namespace (records)	Yes	Yes (by populating LAT)	No	Possible (when a PAC file is used and duplicated external records aren’t used)
Use the same domain name; internally duplicating organization’s public DNS namespace and public servers	Yes	Yes	Yes	Yes
Use the same domain name; maintaining list of public servers in the PAC files.	No	No	No	Yes

Making a Decision

When you plan the DNS hierarchy and namespace for your network configuration, you must take into account two primary considerations when implementing an Internet connection to your network: whether you’ll integrate DNS with Active Directory and whether you’ll use separate domain names for your internal and external namespaces. Table 2.9 provides an overview of both of these considerations.

Table 2.9 DNS Hierarchy and Namespaces

Strategy	Description
Active Directory integration	If you install DNS on a domain controller, you can choose whether or not to use Active Directory to provide storage and replication for DNS. However, full Active Directory integration provides greater fault tolerance by supporting integrated storage and multimaster replication. If you don’t use Active Directory integration, a standard primary zone becomes a single point of failure for dynamic updates and zone replication.
Separate domain names	You can use the same name for your external and internal namespaces, or you can use different names. Using the same name causes configuration problems and increases administrative overhead. It’s generally recommended that you use separate names.

Recommendations

The DNS Service should be fully integrated with Active Directory to provide a fault-tolerant name service for your network. In addition, you should use separate names for your external and internal namespaces in order to reduce configuration problems and decrease administrative overhead.

Example: A DNS Namespace

A company named Contoso has acquired a second company. The first organization, which has reserved the DNS domain names contoso-int.com and contoso-ext.com, has only proxy clients that support either exclusion lists or PACs. In contrast, the second organization, which has reserved the DNS domain names acquired01-int.com and acquired01-ext.com, has no such proxy clients. Both organizations use a different domain name for their internal and external namespaces.

The merged companies require a configuration that does the following:

• Exposes only the public part of the organization’s namespace to the Internet
• Enables any computer within the organization to resolve any internal or external name
• Enables any computer within the organization to resolve any name from the Internet
• Allows each private namespace to be able to resolve any name from the other namespace

Figure 2.17 shows how the DNS domains should be configured in this scenario.

Configuring the External Namespace

In the external namespace, two zones exist: contoso-ext.com and acquired01-ext.com. The zones contain only the records (the names and delegations) that the companies want to expose to the outside world. The server named server.contoso- ext.com hosts the contoso-ext.com zone, and the server named server.acquired01-ext.com hosts the acquired01-ext.com zone. The names contoso-ext.com and acquired01-ext.com must be registered with an Internet name authority.

Figure 2.17 - Example configuration of the DNS domains

Configuring the Internal Namespace

The internal namespace for the organization that hosts contoso-ext.com externally is contoso-int.com. Similarly, the internal namespace for the organization that hosts acquired01-ext.com externally is acquired01-int.com. The server named server.contoso-int.com hosts the contoso-int.com zone, and the server named server.acquired01-int.com hosts the acquired01-int.com zone. The names contoso-int.com and acquired01-int.com must be registered with an Internet name authority.

All the computers in contoso-int.com support either exclusion lists or PACs, and none of the computers in acquired01-int.com support exclusion lists or PACs.

Namespace Without Proxy Clients That Support Exclusion Lists or PACs

For a namespace in which none of the computers are proxy clients that support either exclusion lists or PACs (in this example, the namespace of acquired01-int.com), an organization must devote one or more DNS servers to maintain zones that contain all names from the internal namespace. Every DNS client must send DNS queries to one or more of these DNS servers. If a DNS server contains the zone for the top level of the organization’s namespace (for example, acquired01-int.com), then it must forward those queries through a firewall to one or more DNS servers in the Internet namespace. All other DNS servers must forward queries to one or more DNS servers that contain the zone for the top level of the organization’s namespace.

To make sure that any client within the organization can resolve any name from the merged organization, every DNS server containing the zone for the top level of the organization’s namespace must also contain the zones that include all the internal and external names of the merged organization.

This solution places a significant load on the internal DNS servers that contain the organization’s internal top-level zones. Most of the queries generated within the organization are forwarded to these servers, including queries for computers in the external namespace and in the merged organization’s private namespace. Also, the servers must contain secondary copies of the merged organization’s zones.

Namespace with Proxy Clients That Support Exclusion Lists or PACs

For a namespace in which all of the computers are proxy clients that support either exclusion lists or PACs (for example, the namespace of contoso-int.com), the private namespace can include a private root. One or more root servers can be in the internal namespace, and all other DNS servers must include the name and IP address of a root server in their root hints files.

To resolve internal and external names, every DNS client must submit all queries either to the internal DNS servers or to a proxy server, based on an exclusion list or PAC file. To make sure that every client within the organization can resolve every name from the merged organization, the private root zone must contain a delegation to the zone for the top level of the merged organization.

Using proxy clients and a private root simplifies DNS configuration because none of the DNS servers needs to include a secondary copy of the zone. However, this configuration requires you to create and manage exclusion lists or PAC files, which must be added to every proxy client in the network.

Lesson Summary

DNS is a distributed database used in TCP/IP networks to translate host names to IP addresses. DNS is implemented as a hierarchical and distributed database containing various types of data including host names and domain names. The names in a DNS database form a hierarchical tree structure called the domain namespace. A DNS database is made up of resource records that identify a particular resource within the database. A zone is a portion of the DNS database that contains the resource records with the owner names that belong to the contiguous portion of the DNS namespace. If you install DNS on a domain controller, you can also choose whether or not to use Active Directory to provide storage and replication for DNS. Full Active Directory integration provides greater fault tolerance by supporting integrated storage and multimaster replication. For your organization to be visible on the Internet, you must have an external namespace. When planning your namespace, you must decide whether you want your internal and external namespaces to have the same domain name. Using separate names for your external and internal namespaces reduces configuration problems and decreases administrative overhead.