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 – the reverse lookup zone 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 traditionally 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’.
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.
