Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Overview of DNS Domain Structure

Before getting too far into DNS domains, let's deal with the ongoing confusion between Microsoft's use of the word

domain and the way the term is used in DNS.

Prior to introducing Active Directory, a Microsoft "domain" was completely different than a DNS domain. A DNS domain defines a namespace, such as Company.com. Resource records for hosts within this namespace are stored in a zone file, often simply called a zone. In classic Windows, a domain defines a security structure. Account records for users, groups, and computers within this security structure are stored in the SAM hive in the Registry.

With the advent of Active Directory, the two territories described by the term

domain became synonymous. The security structure defined by the account records in Active Directory conforms to a namespace defined by DNS.

The namespace of a DNS domain describes a relationship between hosts. If a host named Srv1 is in the domain Company.com, its

fully qualified domain name , or FQDN, would be srv1.company.com. Another host, Srv2, in the same domain would have an FQDN of srv2.company.com.

Domains can be joined into a hierarchy based on a contiguous namespace. A DNS domain named branch.company.com would be a child of the domain company.com. Figure 5.1 shows an example DNS hierarchy with several child domains.

The top domain, or

root , in a DNS hierarchy is identified by a trailing dot (.) at the end of the FQDN. This dot serves the same purpose as the leading slash in a file system path. It defines the top of the tree. A

DNS resolver parses the FQDN starting at the leftmost element of the name and ending at the root next to the dot at the right side of the FQDN.

The trailing dot at the end of a FQDN is not generally shown in DNS documentation, and Windows DNS tools add it automatically, so it's easy to forget it's there. When troubleshooting, though, it's a good idea to add the trailing dot just to be on the safe side.

Public DNS Namespace

The domain at the top of a DNS namespace is the

root domain . For public DNS domains, the root domain is also called the

top-level domain, or TLD.

The organization responsible for registering names in the public Internet namespace is the Internet Corporation for Assigned Names and Numbers, or ICANN. Its web site is www.icann.org.

ICANN has contracted with Network Solutions, doing business as Verisign Global Registry Services, to manage the name servers for the largest of the top-level domains: com, net, and org. The Verisign web site is www.verisign-grs.com.

In early 2001, Verisign migrated the name servers for its three TLDs to 64-bit servers located at key nodes in the Internet, both in the continental U.S. and overseas. As of this writing, there are 12 Verisign TLD servers, named a.gtld-servers.net through m.gtld-servers.net.

The remaining standard TLDsmil, gov, and eduare hosted on servers managed by Network Solutions but the zones are controlled by other ICANN designees. The TLD servers for these zones are a.root-servers.net through m.root-servers.net plus a few additional servers for the .mil namespace. The a.root-servers.net server gives referrals to the new Verisign TLD servers.

ICANN has approved seven new TLDs to help differentiate the crowded com and org namespace. Table 5.1 lists the TLD names and the agencies or companies that sponsor them:

ICANN is also responsible for country code TLDs, abbreviated ccTLDs. For example, a web site in Norway would have an FQDN ending in NO, such as www.sol.no. The two-letter country designations follow the ISO 3166 standards. For information about the registrar for a particular ccTLD, see www.iana.org/cctld/cctld-whois.

Private DNS Namespace

You are not constrained to using a public TLD as a root domain in your private network. You can define your own root domain for internal use. For a while, a proposal circulated around the Internet to designate the .local designator as the reserved root domain for private DNS namespaces. This recommendation did not catch on.

In general, you are free to use virtually any combination of letters for the root of your private namespace that have not already been taken by ICANN. Many organizations maintain a private DNS namespace with the same root domain name as their public namespace. This requires maintaining two DNS servers with different zones.

Hosts File

Before a client goes to the trouble to make a DNS query to resolve a host name into an IP address, it first consults a local file called Hosts. Here is an example Hosts file. The pound sign (#) denotes a comment:

10.1.1.1    dc01.company.com            #domain controller in Company
10.1.1.2    dc02.company.com            #another domain controller in Company
10.3.1.27   srv1.branch1.company.com     #general purpose server in branch office
10.2.1.12   web7.subsidiary.com            #web server in affiliate domain

The host name specified by a TCP/IP application must exactly match the entry in the Hosts file to get a successful lookup. For example, using the preceding Hosts file, a ping to dc01 would not succeed, but a ping to dc01.company.com would succeed. If the name is not in the Hosts file, the client then uses DNS to resolve the name.

Primary and Secondary Name Servers

A conventional DNS server stores its resource records in a zone file. Windows-based DNS servers give zone files a .DNS extension. For example, the zone file for the company.com zone would be company.com.dns. The zone files are stored in the \Windows\System32\DNS folder. A zone can also be integrated into Active Directory, in which case the resource records are stored as objects in the AD database.

Refer to Figure 5.2. In a standard DNS architecture, only one name server has a read/write copy of a zone file. That server is called the

primary name server . All zone changes must be funneled to this server.

For fault tolerance and performance, it is a good idea to install one or more

secondary name servers . A secondary name server hosts a read-only copy of the zone file. The secondary servers pull copies of the zone from primary name servers or from other secondary servers.

A name server that simply caches the results of queries so it can pass the information along to its clients is called a

caching-only name server .

This reliance on a single primary name server is a weakness of classic DNS. As we'll see, Active Directory Integrated zones overcome this weakness by making any domain controller running DNS a primary name server for its zones.

Resource Records

A zone file contains a set of

resource records . Each record contains specific information about a host or service in the DNS domain. RFC 1183, "New DNS RR Definitions," defines more than a dozen DNS record types. Only a few are used with any frequency.

When a DNS client needs information from a name server, it queries for a resource record. For example, if a client needs the IP address corresponding to a server named srv1.company.com, it sends the DNS server a request for the A, or Host, record for that server. The DNS server responds by finding the A record in the zone and then copying the contents of the record into a DNS reply, which it sends back to the client.

So, DNS is nothing more than an exchange of resource records between clients and servers. The trick to making your DNS structure work correctly is making sure that the clients can find the right DNS servers and the servers have the right information in their zone files.

Authoritative Query Responses

When a DNS server is presented with a query for a resource record, it responds differently depending on whether or not it hosts a copy of the zone containing that resource record.

A DNS server that hosts a copy of a zone file is said to be

authoritative for that zone. When tracing a DNS query, the buck always stops at an authoritative server for the zone specified in the query.

When a query arrives for a resource record within a name server's zone of authority, the server performs an

authoritative lookup . Here is how it handles that lookup:

• If the server finds the requested record in its zone file, it responds with a copy of the record contents.




• If the server has recently done a lookup on the same record, it responds with a cached copy of the record. This is much faster than doing a file lookup from disk.




• If the server cannot find the requested record, it returns a Record Not Found response to the client.

Non-Authoritative Query Responses

If a DNS server does not have a copy of the zone file for a requested zone, it has three alternatives when handling the query:

• Query other name servers until the record is found, then return a copy to the requestor.




• Respond with a referral to a name server further up the tree that might have a copy of the record.




• Respond with a cached copy of the record that was stored following a previous lookup.

All three methods result in a

non-authoritative reply . The choice of which method to use, #1 or #2, is based in large part on a

search type flag included in the client query. The flag has two possible states:

• Recursive.
  This tells the DNS server to respond with a copy of the requested resource record no matter what. If the server has to consult with other DNS servers to find the record, so be it. A recursive query is like a Spartan mother sending her son into battle saying, "Come back carrying your shield or lying on it."




• Iterative.
  This request permits the DNS server to return a referral to another DNS server that is likely to have a copy of the record rather than chase down the referral itself. An iterative search puts the workload on the client to follow up on the referral.

DNS clients typically set the recursive flag in their queries on the assumption that the DNS server has more capacity for handling the search. Recursive queries from thousands of clients can put a great deal of load on a DNS server, so it is not uncommon to find servers configured to reject recursive queries. For example, the Verisign TLD servers are configured to reject recursive queries. See "Configuring Advanced DNS Server Parameters" for the steps to disable recursive queries on a Windows Server 2003 running DNS.

If your ISP maintains a name server that permits recursive queries, or you find an open name server at another ISP, it is good etiquette to get permission prior to sending recursive queries to the server.

DNS servers typically use iterative queries when they search on behalf of their clients. The server has the resources to handle referrals, so it doesn't make sense to put unnecessary burden on upstream DNS servers. Windows Server 2003 running DNS will default to iterative queries. There are no adjustment parameters to change this default.

Root Hints

DNS servers within a contiguous namespace can use a simple referral mechanism to find entries in each other's zones. For example, a DNS server in branch.region.company.com that gets a request for an A record for srv1.company.com can go right to a name server at the root of the company.com namespace to begin its iterative search if it knows the identity of the name servers at the root domain. An administrator can include these names in the configuration for the name server.

When a DNS server gets a query for a resource record for a server on the Internet, it needs a way to find the TLD servers that host the root of the public domains. The DNS server finds these TLD servers using a special file called

root hints . Figure 5.3 shows the root hints stored on a Windows Server 2003 running DNS.

Root hints are contained in a text file that lists the names and IP addresses of the name servers at the root of the DNS namespace. Windows DNS servers store their root hints in a file called Cache.dns located in \Windows\System32\DNS. This root hints file contains the older TLD servers, not the new Verisign TLD servers. For an interim period, the a.root-servers.net TLD server will give referrals to the new TLD servers.

DNS Client Resolvers

The client service responsible for querying DNS and handling the responses is called a

resolver . In Windows, the DNS resolver is part of the main TCP/IP driver.

When an application first specifies the name of a particular server, the resolver first looks in its Hosts file. If the resolver does not find an entry in the Hosts file, it then goes to DNS. Like a good

Jeopardy contestant, the resolver always submits its DNS requests in the form of a question, a

DNS Query .

When the resolver gets a response to its query, it caches the results in memory to speed up subsequent queries for the same record. DNS servers that search out records on behalf of their clients also cache the results.

A name cache can get very large if the entries are never removed. Also, an entry might change but the server would not find out because it only looks in its cache. To prevent these problems, a DNS resource record contains a

Time-To-Live (TTL) setting that specifies how long to cache the entry.

Negative Caching

Starting with Windows 2000, Microsoft included support for RFC 2308, "Negative Caching of DNS Queries." This permits a client to cache negative responses along with the resource records it receives. The idea behind negative caching is to prevent sending repeated queries to a name server that has already admitted that it cannot find the record. If you're the parent of a two-year-old, you can understand the value of negative caching.

Unfortunately, negative caching can interfere with troubleshooting. For instance, let's say you forgot to put a host record for a new server into DNS. You start getting calls that folks cannot find the new server. You realize your mistake and create the host record. The phone calls continue to come in from those who have already tried to contact the server because their DNS client cached the negative response.

You can clear these negative responses out of the local DNS cache using the IPCONFIG utility as follows:

ipconfig /flushdns

Unfortunately, this command must be issued at the client.

Servers also cache query results, including negative responses. If you want to clear out the DNS cache of a server, use the DNSCMD utility with this syntax:

dnscmd /clearcache

When you clear the cache, the client or server must accumulate entries again. This may hurt performance for a short while.

NetBIOS Resolution Versus DNS Resolution

A modern Windows client (Windows Server 2003, XP, or Windows 2000) uses NetBIOS name resolution to support SMB-based network application such as LanMan Workstation and LanMan Server. (SMB stands for Server Message Block, the command language used in Windows networking.)

For example, if you map a drive to a share point on a server, the flat server name in the UNC path is resolved to an IP address using NetBIOS name resolution. If the name contains a dot (.) or is longer than 16 characters, the client uses DNS name resolution. With the default h-node configuration, a modern Windows client uses the following sequence for NetBIOS name resolution:

1. NetBIOS name cache




2. WINS query




3. Lmhosts file




4. Broadcast




5. Hosts file




6. DNS

For Windows Sockets-based applications, all Windows clients use DNS name resolution (Hosts then DNS) as the primary means of resolving names to IP addresses. A modern Windows client will initiate NetBIOS name resolution in parallel, so if there is a disparity between the flat name in WINS and the hierarchical name in DNS, you can end up with a tricky problem to troubleshoot.

Flat names cannot be submitted to a DNS server. If you ping a flat host name, such as svr1, the DNS resolver takes the following action:

• If the name does not have an embedded dot and is shorter than 16 characters (a flat name), the client appends the DNS suffix for the computer onto the name and sends it to DNS.




• If the name has an embedded dot and does not have a trailing dot, the resolver appends a trailing dot and sends the result to DNS. If the query fails to return a host record, the resolver appends the entire domain suffix and tries again.




• If the first DNS suffix fails to get a host record from DNS, the resolver appends any alternative DNS suffixes that have been configured for the interface.




• If all secondary suffixes fail, the resolver gives up.