70-240 in 15 minutes a week: Windows 2000 DNS

Monday Oct 22nd 2001 by ServerWatch Staff
Share:

Article 22 in Dan DiNicolo's 70-240 in 15 minutes a week series takes a final look at DNS in Windows 2000. This includes a look at host name resolution, associated utilities, integration with WINS, and advanced DNS configuration in Windows 2000.

by Dan DiNicolo
http://www.2000trainers.com

Welcome to article number 22 in my 70-240 in 15 minutes a week series. This week's article covers a final look at DNS in Windows 2000. This includes a look at host name resolution, associated utilities, integration with WINS, and advanced DNS configuration in Windows 2000. This article again falls into the networking services portion of the 70-240 exam.

The material to be covered in this article includes:

- Host name resolution
- Name resolution utilities
- Integrating DNS with WINS
- Advanced DNS Configuration


Host Name Resolution

Many people confuse the ideas of a host name and a NetBIOS name when first attempting to understand the concepts. Simply put, a host name is an alias for an IP address -a name that is easier to remember than a 32-bit number. If a system doesn't have an IP address, it doesn't have a host name, and talking about host name resolution is then a non-issue. The reason for some of the confusion is that traditionally, the host name and NetBIOS name on a Windows-based system are the same by default, although this needn't be the case, since they can be different. The process of having a host name and attempting to find the associated IP address is referred to as host name resolution, and can be accomplished using two main facilities - the HOSTS file, and DNS.

The HOSTS file is a text file found in the %systemroot%\system32\drivers\etc directory on a Windows 2000-based system. This static file is used by the local system to resolve host names to an associated IP address. This is the first place from which a system will attempt to resolve a name, so it is important that it does not contain incorrect entries. Note also that the files is parsed from top to bottom, such that if multiple entries for a name exist, the first found will be used and the others ignored. An example HOSTS file is shown below.

Any entries proceeded by a # symbol are considered comments. Note that HOSTS files were the original name resolution facility on the Internet prior to the creation of DNS. The size of the files eventually made this method impractical, but the simplicity of the file as a name resolution facility make then useful, even today.

DNS was invented largely due to the scalability issues associated with the creation and maintenance of a single flat text file for name resolution on the Internet. The Domain Name System is a distributed database of information maintained on DNS servers (actually more of a series of distributed localized text files called zone files). Having explored the process of DNS name resolution in previous articles, I will not repeat it here. If you still do not understand the basics of DNS resolution, please visit the series article archive found at http://windows.2000trainers.com/coursesandarticles/70-240/. However, remember that the main purpose of DNS is to take a host name (or fully qualified domain name) and resolve it to an IP address. DNS forms the naming backbone of the Internet, via the 13 root name servers and thousands of other DNS servers that currently exist. (see the cache.dns file in the %systemroot%\system32\dns\samples directory for the root server list, or the Root Hints tab from the DNS server's properties) 


Name Resolution Tools and Utilities

A number of hostname resolution utilities and facilities exist that you should be aware of in Windows 2000. These include nslookup, the monitoring tab of the DNS server properties, ipconfig switches, and netdiag.

Nslookup is the most common DNS hostname resolution troubleshooting utility. In effect, this tool is used as a command-line resolver, a DNS client that sends queries of different types to a DNS server and returns a response. This tool provides a quick and easy way of testing whether or not host name queries are capable of being properly resolved via DNS. For example, to test resolution of the server at 10.1.1.1, you could issue the command nslookup 10.1.1.1 192.168.1.200, and be returned the hostname associated with the IP address 192.168.1.200 if DNS is correctly configured.

The Monitoring tab found in the properties of a DNS server also provides a quick way to assess DNS resolution (although I would argue that it can be less reliable at times based on experience), via a simple or recursive query test. The screenshot below outlines the options available, which include the ability to schedule these tests to run automatically.

A simple query sends a query from the local resolver (client) to the locally configured DNS server. The recursive query goes a step farther, with the client asking the server to use recursion to find a name server for the root (".") domain. This provides a method to ensure that root hints (the list of root servers) and / or forwarding are configured correctly.

Netdiag - although this tool can be used to test many network connectivity and associated issues, it can also be used specifically to troubleshoot DNS-related issues. When issued using the Netdiag /test:DNS command, Netdiag will check to see whether the computer is correctly registered in the listed DNS servers, while also verifying that the DNS cache service is running. When used with the /fix option, Netdiag will attempt to re-register the host in DNS if the entries found are not consistent.

Ipconfig - although most commonly used to view IP address configuration information, the ipconfig command has 3 switches directly related to DNS. The /displaydns switch, allows you to view the DNS entries recently resolved and cached on the client. The /flushdns switch clears the client DNS cache. Finally the /registerdns switch forces the client to attempt name and address registration with the configured DNS server(s).

Event Viewer DNS Server Log file - found on Windows 2000 DNS servers, this Event Viewer log file will provide information on errors and other important information relating to the DNS service. This should be used as a first point of contact when troubleshooting DNS-related issues. The System log should also be consulted for issues relating to client-side resolution problems. 

DNS Logging - Another option for monitoring your DNS servers is to configure then to using DNS logging, which logs selected DNS event information (as shown below) to a dns.log file in the %systemroot%\system32\dns folder on the server. This is configured from the Logging tab on the DNS server's properties, but may cause performance degradation on the server. It should be used only for troubleshooting purposes.

Integrating DNS with WINS

Since many networks running NT 4.0 relied on WINS as their primary name resolution facility, Microsoft provided a non-standard method for integrating DNS with WINS. This involved configuring a DNS server with special WINS-related records that would then be used to extend name resolution beyond the records known to DNS. In a nutshell, if configured with the address of a WINS server (using the non-standard WINS record), the DNS server would attempt to query WINS for any records not found in the DNS zone database file. It would do this by reformatting the request as a NetBIOS query, and the WINS server would respond if a match was found. This provided many companies with an efficient way to create a type of dynamic DNS in NT 4, since clients whose IP addresses were not in DNS (since they used DHCP) could still be found via DNS, since WINS was updated dynamically.

This same functionality still exists in Windows 2000, even though dynamic DNS now exists. Remember that non-Windows 2000 clients still do not use dynamic DNS, and many companies have large WINS implementations that work quiet well, and as such, might wish to continue using this rather than switching to DHCP-initiated client updates. Before looking at how integration between WINS and DNS should be handled, remember that a DNS query is resolved by a DNS server that is authoritative for the zone within which a DNS domain exists. That is, a name server whose zone is responsible for the domain company.com will answer a query for server12.company.com. The reason that I mention this is because the placement of the WINS records will differ based on a company's DNS implementation. 

For example, imagine that my company has set up DNS to support Active Directory, and my implementation is such that only records for domain controllers appear in DNS. If I configure my single DNS forward lookup zone with a WINS record pointing to my WINS server, this WINS server will be queried if the associated host record is not found in DNS. While this works fine for a single forward lookup zone, it becomes more complex when my company has many domains in its DNS implementation (perhaps because of a large multi-domain AD design). In cases like these, you might want every forward lookup zone to be configured to do WINS resolution, and this might involve a great deal of administration. For this reason, Microsoft recommends creating a separate Active Directory domain strictly for the purpose of WINS resolution. At first glace this may not may sense, so let me explain. In the Advanced TCP/IP properties of a system (on the DNS tab, as shown below), you can control the order in which domains are searched for the purpose of name resolution. By default, the suffix for the domain in which the local system exists is searched, followed by parent domains. For example, imagine you typed ping server3. If the client system from which the command was issued was in the west.company.com domain, it would first try resolving server3.west.company.com (notice is automatically appends the domain name since you didn't use an FQDN). If this fails, it will then attempt server3.company.com (appending the suffixes of the parent domain - company.com). If this also fails to resolve the name, resolution fails. 

Consider if you were to create a separate DNS domain just for WINS resolution, however. You might create a special domain within your DNS structure called wins.company.com, and have this be the second domain appended in a search to resolve a hostname. In my example, the setup might look like this:

Now, if a client were to attempt to ping an unqualified hostname, like server3, it would first attempt to query server3.west.company.com followed by server3.wins.company.com. The idea is that if an answer could not be found in subdomain 'west', it would then attempt subdomain 'wins'. The forward lookup zone for subdomain 'wins' would only need to be configured with 1 (or more) WINS records (and WINS-R records in the associated reverse lookup zone), pointing to the appropriate WINS servers where clients and servers are registered. This setup is best when you have many domains and/or subdomains, where client DNS properties are set to query their own domain first, followed by the special 'wins' domain second, thereby making use of the existing WINS facility for resolution.


Advanced DNS Configuration

Certainly there are a great many ways in which DNS can be configured, including as a root server (for your own network if you wanted), a caching-only server, a forwarder, and so forth. There are also a number of more advanced capabilities that you may not understand or appreciate. While you certainly don't need to understand every tiny detail for the exam, I will use this section to give a brief overview of some of the things you should be aware of that you might have overlooked in exploring Windows 2000 DNS. These are considered on an area-by-areas basis below.

Reverse Lookup Zones - certainly one of the least understood subjects in DNS, the reverse lookup zone primarily exists for the purpose of mapping IP addresses to host names. This is easier said than done, since FQDNs get more specific when moving from right to left, while IP addresses get more specific when moving from left to right. DNS was designed to resolve the domain, subdomain, and finally the hostname, moving from the right (like .com) to the left (like server16). However, imagine how difficult it would be to figure out how difficult it would be to find the hostname of a machine knowing only that it ends in .200! The number of possibilities makes it almost impossible. For this reason the reverse lookup zone was created, its interesting feature being that it is named using the network portion of the IP address reversed, with the special domain in-addr.arpa appended as the suffix. As such, if the network address for company.com were 131.107.0.0, the associated reverse lookup zone would be named 107.131.in-addr.arpa. This can then be resolved like a normal DNS address, since a limited number of network IDs (256 to be exact) begin with 131, and in theory at least, only one begins with 131.107 (assuming is hasn't be 'slashed' by an ISP) making identification possible. This zone can then be consulted to find records for hostname associated with the sought after IP address. But why do we care? Because many applications actually use reverse lookup as a security device to ensure that a given host is coming from a permitted source. Although your DNS will properly function for the most part with reverse DNS, it is definitely best practice to create associated reverse zones for your forward lookup zones.

Character Sets - something you may not have considered when configuring your DNS server is the character set in use. This is an important consideration, especially is you are using different versions of DNS from different vendors, and wish to have them communicate with one another (for example for the purpose of zone transfers). If one supports a character set that the other does not, the zone transfer might fail, which would obviously be an issue. The reason this actually has to be looked at is because traditionally Microsoft naming has been based in NetBIOS, which allows characters (such as the underscore, for example) that are not valid within a hostname. There are 3 main character sets supported in Windows 2000 DNS. These include:

a. Strict RFC (ANSI) - allows A to Z (upper and lower case), 0-9, and the hyphen in names, according to RFC 1123
b. Non RFC (ANSI) - allows everything as above, including the '_' character anywhere in a name.
c. Multibyte (UTF8) - allows characters outside of the ASCII character set, such as Unicode. 
d. Any Character - allows any character set to be used, including Unicode

The character set should be defined in the Advanced tab of the properties of the DNS server under 'name checking', as shown below:

Interoperability with BIND - Some companies will choose to use their existing DNS infrastructure to support Active Directory or their networking infrastructure in general. For the purpose of the exam, you should be aware of the capabilities supported by BIND, the Berkeley Internet Naming Daemon, which is also the most popular DNS server in use today. Without getting into tremendous detail, you should be aware of supported features in 3 key versions:

a. version 4.9.7 supports SRV records, the single 'required' element to support Active Directory.
b. Version 8.1.2 support SRV records and dynamic updates.
c. Version 8.2 supports SRV records, dynamic updates, and incremental zone transfers.

Note that none of the BIND versions listed support UTF8 character encoding, nor do they support the WINS or WINS-R resource records. As such, these may cause you issues that you may need to address prior to having a Windows 2000 and BIND server interoperate.

That does it for yet another week of the series. Thanks again to all who all supporting the series, and especially those who have been patient over the last few weeks with the delays in a few of the recent articles being released. Next week I plan to cover either Routing in Windows 2000 or Remote Access, depending on how much time I have to devote to the topic. There are only a few articles left, and hopefully I'll have them all released prior to the end of September. Until next week, best of luck with your studies.

Dan

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved