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

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