DNS – 2000Trainers.com

Router Hostname and DNS Settings

During the initial System Configuration Dialog, we gave our router a hostname of toronto-1. This can be changed using the hostname command. For example, to change the hostname of this router to cisco2501, enter the following from global configuration mode:

toronto-1(config)#hostname cisco2501 cisco2501(config)#

Notice that the command prompt name immediately changes to cisco2501. The hostname associated with the router is there to give you perspective on which router you are connected to. Unless you have an entry set up on a DNS server that maps this name to one of the router’s IP addresses (or appropriate host file entries), you still won’t be able to telnet into the router using its hostname.

By default, a Cisco router will always assume that any unrecognized command is the name of a host that you wish to initiate a telnet session with. Because of this, it will attempt to resolve the name to an IP address using DNS. For example, consider what happens when I enter “helpme” at the prompt and press enter.

cisco2501#helpme Translating "helpme"...domain server (255.255.255.255) % Unknown command or computer name, or unable to find computer address cisco2501#

If you want to avoid this frustrating and somewhat annoying action, you can always configure the router to not perform a DNS lookup on unrecognized commands using the no ip domain-lookup command.

cisco2501(config)#no ip domain-lookup cisco2501(config)#^Z cisco2501#helpme Translating "helpme" % Unknown command or computer name, or unable to find computer address cisco2501#

You will probably get to a point where you’ll want to configure a router to resolve names, since these are generally easier to remember (and to input) than IP addresses. If you decide to do this, you have two choices – you can either configure your router to use DNS, or you can use a locally configured hosts table. If you’re familiar with the HOSTS file from UNIX or Windows environments, this is almost exactly the same – a group of static name-to-IP address entries that you manually define.

To configure a router to use a local hosts table, you will need to be in global configuration mode. In the example below, I have created entries for 2 different routers, named accra and montreal, using the ip host command.

cisco2501(config)#ip host accra 192.168.1.45 cisco2501(config)#ip host montreal 192.168.36.2 cisco2501(config)#^Z cisco2501#show hosts Default domain is not set Name/address lookup uses static mappings Host Flags Age Type Address(es) accra (perm, OK) 0 IP 192.168.1.45 montreal (perm, OK) 0 IP 192.168.36.2

The show hosts command is used to view the hosts table. The table shows us that the entries are permanent, along with hostnames and associated IP addresses. To be honest, creating a hosts table on each an every router would be painful – you are much better off using DNS if it’s available.

Configuring a router to use a DNS server to resolve hostnames isn’t much more difficult. Just remember that entries for the hosts and their associated IP addresses need to be entered in DNS prior to the router being able to resolve them. There are a couple of steps involved in setting up a router to query DNS. As a first step, we need to reinstate the ip domain lookup command that we turned off earlier.

cisco2501(config)#ip domain-lookup cisco2501(config)#ip name-server 192.168.1.100 cisco2501(config)#ip domain-name 2000trainers.com

So what just happened? Well, we reinstated domain lookup to begin with. The second step set the IP address of the DNS server that the router will query. The final command set the domain name of the router to 2000trainers.com. This domain name will be appended to hostnames when we don’t provide a fully qualified domain name (FQDN). For example, an attempt to resolve the hostname accra would be sent to the DNS server as a request to resolve accra.2000trainers.com.

Domain Renaming and Repositioning

In the Windows 2000 version of Active Directory, it was not possible to rename domains without demoting all domain controllers, which effectively destroyed the domain. In Windows Server 2003, domains can be renamed, as long as the forest in which they exist are configured to the Windows Server 2003 forest functional level. Of course, this means that you cannot rename a domain that includes either Windows 2000 or Windows NT 4.0 domain controllers, since the Windows Server 2003 forest functional level only supports Windows Server 2003 domain controllers. The tool to rename Windows Server 2003 domains is named RENDOM, and is found in the Valueadd\Msft\Mgmt\Domren folder on the Windows Server 2003 CD.

Along the same lines, Windows Server 2003 also allows you to rename individual domain controllers with a new computer name. In Windows 2000 Active Directory, this was only possible if you first used DCPROMO to demote a domain controller back to a member server, changed the name, and then re-promoted it. Renaming a domain controller is only possible if a domain is configured to the Windows Server 2003 domain functional level.

Renaming a Windows Server 2003 domain controller is handled differently than the traditional method (via the System tool in Control Panel). Instead, the NETDOM command line utility is used to handle the domain controller renaming function. For example, the series of commands to rename a domain controller from server1.company.com to database.company.com would be:

C:\>netdom computername server1.company.com /add:database.company.com

C:\>netdom computername server1.company.com /makeprimary:database.company.com

Then, after rebooting the server:

C:\>netdom computername database.company.com /remove:server1.company.com

Finally, Windows Server 2003 also supports the ability to reposition domains within an Active Directory forest. For example, imagine that you originally implemented each domain as its own forest, and then decided that you instead wanted to change the structure that such all domains fell into the same DNS namespace, as part of a single tree. This is now possible, but only if the forest is configured to the Windows Server 2003 functional level. Although that does present a limitation, the ability to reposition domains is a great feature, especially if you managed to inherit responsibility for a forest that was not well designed in the first place.

In the same manner as renaming domains, domain repositioning in Windows Server 2003 Active Directory environments is also accomplished by using the RENDOM utility.

Exchange, DNS, and Internet Email

As most of you know, I haven’t been churning out the articles lately. I am in a little bit of a slump, and decided to do a light article this week to help me get back into the swing of things. I decided that one of the best places to start would be with one of the most frequent problems I see people having with Exchange 2000. The question that I probably see the most relates to setting up Exchange 2000 to access the internet. What I am going to talk about in this article is how to setup DNS to allow your Exchange 2000 server to access the internet, as well as how to use Nslookup to troubleshoot DNS settings. Obviously, I can’t cover all possible configurations, but I am going to try and cover the most basic configuration.

I am going to go with the understanding that most of you already have your Exchange Server installations completed. If not, then this isn’t the article that will cover that. For installing Exchange, take a look at one of my earlier articles. Now once you have Exchange 2000 installed, there isn’t much else you need to do on the Exchange side. Exchange is tightly integrated with Active Directory, but more importantly, it is very tightly integrated with IIS as well. This integration allows Exchange 2000 to connect to the internet without requiring any connectors to be installed or configured. This one is a little different, because previous versions of Exchange required a connector of some type to be configured. For example, Exchange 5.5 required an Internet Mail Service Connector (IMS) in order to access the internet.

Now there are a couple of different ways that we could configure DNS for our Exchange 2000 server. For example, I might be running DSL, with a firewall like Proxy 2.0 or ISA Server in place. This would mean that we would have a public IP on the external network card of the firewall. Now, if we were running our own DNS server, we could simply put the appropriate Host (A) and Mail Exchanger (MX) records into our DNS database. Now, when a client queried our DNS server, the record for our Exchange 2000 server would be returned, and the client would be able to communicate with our server. This is a simple configuration from the standpoint of DNS, although it would require additional work in order to get the Exchange Server communicating from behind the firewall. For additional information on how to configure this, see Q276388 and Q308599.

However, judging from the questions that I am getting, the majority of you aren’t setting up your servers in this type of environment. The majority of the questions that I am seeing are centered around small companies that are running a single Exchange 2000 server, and running their own DNS servers for internal purposes, but using an ISP for external name resolution. Although this situation is a little more complicated than our previous example, it is by no means impossible. Probably the biggest problem facing most people is a lack of understanding on how DNS works. For this, I recommend reading DNS and BIND, by Paul Albitz and Cricket Liu. You can find this book just about any place that sells books on technology. Another good resource would be the Windows 2000 help files, as well as the Windows 2000 Resource Kit.

Now lets get back to our problem. We have our Exchange 2000 Server installed, we have our internal DNS working, taking care of Active Directory and all its needs. So how do we configure it to allow our internal clients to be able to send email out to the internet, and also to allow internet users to send email to our internal users?

The first thing that we need to take a look at is how do we get our email out to the internet? In this case, setting up our internal DNS server to forward requests that it can’t handle to our ISP’s DNS server should do the trick. So what I would need to do would be to go into the DNS MMC, right click on the DNS server object, and go to properties, and then select the Forwarders tab. I would type in the address or addresses of my ISP’s DNS server(s), clicking add after each one. Now my DNS server will simply send requests that it can’t resolve out to my ISP’s DNS Server. This will allow my clients to get their email out to the internet, but at this point, I am only halfway done. I still need some way to give users access to my Exchange server. The trick here is that my Exchange server is running on my internal network, probably running on a Private IP address. So let’s take a look at how we can accomplish this task.

As a first step, we have to add the appropriate MX and A records to our ISP’s DNS Server. In this case, the records would point to the public IP for our company, typically the external interface of our firewall. Now, we would need to use something like Network Address Translation (NAT) in order to convert the incoming request and redirect it to our Exchange server. In my earlier example using ISA server, publishing Exchange from behind the ISA server allows you to accomplish this task with a minimal of effort, because ISA will forward the requests for Exchange to the appropriate address, allowing external clients access to our internal Exchange server.

Given that we have configured everything correctly, our internal clients should be capable if sending and receiving both internal and internet email. But how do we know that we setup DNS correctly? Enter Nslookup. Nslookup is a troubleshooting utility that allows us to query a DNS database for the presence of appropriate records, amongst other things. Now, for internal DNS, we can simply open up the DNS MMC console and verify that we have correctly configured the Forward and Reverse Lookup Zones. This is easy enough, because we are in charge of these zones, we manage, create and delete them. But what about our ISP’s DNS database? How do you know that they have correctly configured your A and MX records. The answer would be to do a simple query of their DNS database using Nslookup. From Windows NT 4.0, 2000, and XP, simply drop to a command prompt and type in Nslookup

Once you hit enter, you can now query the DNS database. In my case, I have typed in that I am looking for an MX record. The second option tells the Nslookup utility what domain name I am looking for. In this case, it is my business domain, Bellcs.com. The screen would look like this;

Figure

You can also see from looking at the second screen shot that I am querying my ISP’s DNS server, which is 4.2.2.2. However, this ISP isn’t authoritative for this particular domain name, as you can see from the reply that has been returned. It does show that I do have a configured Mail Server, as well as the Name Servers for my domain.

So this is how I can see what is in my ISP’s DNS database, without having access to the physical DNS server. Obviously, there is a lot more to Nslookup than what I have shown here. For more information about this utility, simply type Nslookup and press Enter. Then type help and press Enter. You can also lookup Nslookup in Windows 2000 Help, or online at Technet.

That should just about do it for now. Hopefully this helps to shed some light on configuring your Exchange 2000 servers to access the internet, as well as the DNS settings necessary to make it work. Next week we will get back to our regular series, starting with a new Exchange 2000 article. Until next time, cya!

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 – 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.

Integrating DNS and 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 is 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 what would happen 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.

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.

Troubleshooting DNS Servers

Three main options exist for troubleshooting DNS servers that you should be aware of. The first is the monitoring tab on the properties of the DNS server.

This tool allows you to pass queries to the DNS server to ensure it is functioning correctly. A simple query is passed only to this server for resolution, and will either pass or fail. A recursive query is one in which a DNS server will attempt to query other DNS servers to obtain an answer, which will again be presented as a pass or fail. This tool can also be used to test DNS on a regular basis, as specified by the test interval.

DNS logging can also be used for troubleshooting purposes, as it will log when certain DNS events occur. Found on the Logging tab of a DNS server’s properties, all output is saved to a text file called dns.log located in the %systemroot%\system32\dns folder on the server. Note that excessive logging may have a negative impact on server performance, and as such should only be used for troubleshooting purposes.

More commonly, Nslookup is the tool used to query a DNS server. This command line utility allows you to search for resource records relating to a domain. Use the /? option for a list of supported commands.

Configuring DNS to Support Active Directory

Aside from the details listed above, it is important to understand how to create an initial DNS zone to support Active Directory. This should be done in advanced of installing Active Directory, in order to ensure that things are configured as you wish them to be. If you do not configure the zone in advance, the installation wizard will automatically do it for you, and the installation may not meet your needs.

Configuring a zone first involves installing the DNS service via the Add/Remove Windows components wizard. After doing this, open the DNS tool and you should see the default configuration.

By default the server will act as a caching-only server, simply forwarding queries to root servers when an answer cannot be found in cache. However, in order to support AD, a zone must be created that will be authoritative for the Active Directory domain that is to be installed. A wizard does exist to walk you through the process (right click and choose Configure the Server) if you choose that method. However, right-clicking the forward lookup zone and choosing New Zone will open the New Zone wizard, which I will cover here. By default, three options exist for zone types to be created.

Note that the option for an Active Directory-integrated zone is unavailable since Active Directory has not yet been set up. Choosing a standard primary would be our only real option, since a secondary requires a primary to exist. This primary zone can later be changed to AD-integrated as we’ll see in a bit. The zone must be named, so I have chosen 2000trainers.com, which will create a zone file called 2000trainers.com.dns.

After creating a zone, ensure that the TCP/IP properties of the server you wish to promote to a domain controller point to this newly created DNS server (it may be the same system). Also note that the properties on the zone can be accessed to change settings such as the zone type (which can be changed once we install AD), support for dynamic updates (disabled by default), SOA, Name Server, WINS, and Zone Transfer information.

The properties configured for a zone are different than those configured for a DNS server, which may support many zones. Properties for a DNS server are shown below, allowing you to control elements including the configuration of interfaces, forwarders, advanced properties, root hints, logging, and monitoring.

Note that dynamic updates are not allowed by default. You’ll need to change this in order for domain controllers to automatically register their service records.

Also remember that a zone can only be compromised of domains in a contiguous namespace. As such, if you wanted to support domains called test.com and 2000trainers.com from the same DNS server, you would be required to created separate zones. However, a single zone could handle the domains 2000trainers.com and research.2000trainers.com without issue.

Although not required for Active Directory support, it is also good practice to create reverse lookup zones for all forward lookup zones created, since these provide IP address to hostname resolution services. A reverse zone name will be in a format that reverses the network portion of the IP address range in use, and appends the reverse-lookup domain name. For example, the domain name for a reverse zone that supports network 192.168.0.0 would be 168.192.in-addr.arpa. You should also enable dynamic updates for this zone in order for reverse records to be added automatically.

DNS Service Records and Locating Domain Controllers

Windows 2000 Active Directory requires DNS to function correctly. DNS support for SRV records is the only absolutely mandatory requirement for Active Directory to function. However, it is also recommended that your DNS server support dynamic updates, since domain controllers dynamically register a number of records in DNS. If your DNS servers do not support this, you would need to set up all required service records for all domain controllers manually, a potentially long and arduous process. Windows 2000 DNS supports both, as well as incremental zone updates (IXFR). IXFR is useful in that it allows DNS servers to simply replicate zone changes instead of the entire zone file as in AXFR-based implementations (NT 4 DNS, for example). It is also worth noting which versions of BIND (the popular Unix-based DNS server) support the above requirements:

BIND 4.9.7 – supports SRV records

BIND 8.2.1 – supports SRV records, Dynamic Update, IXFR

An understanding of the SRV records and related domains that you will find (or require) in a DNS implementation to support Active Directory is also important. Just to reiterate, Windows 2000 uses service records in DNS to locate domain controllers in specific domains, domain controllers in the same site, global catalog servers, key distribution centers, and more. A service record uses a standard record format, an example of which is shown below:

_service._protocol.name ttl class SRV priority weight port target

_Service represents the name of the service that a domain controller is running, such as ldap (for a domain controller), gc (for a global catalog server), kerberos for a key distribution center, and so forth.

_Protocol specifies the transport protocol used, such as TCP or UDP.

Name specifies the domain name relating to the record, for example 2000trainers.com

Ttl specifies the time to live value, in seconds

Class specifies the DNS record class value, almost always ‘IN’ for Internet.

Priority specifies the priority level of the server. Clients will attempt to contact the server with the lowest priority value.

Weight is a load-balancing feature. If multiple servers have the same priority, clients choose SRV records with higher weights.

Port specifies the port number that a particular service listens on.

Target specifies the FQDN of the host running the service

As such, a domain controller with FQDN dc1.2000trainers.com acting as a global catalog server would have a service record (as well as many others) as shown below:

_gc._tcp.2000trainers.com 600 IN SRV 0 100 3268 dc1.2000trainers.com

Domain controllers register their service records when their Netlogon service starts. As such, stopping and starting the domain controller’s Netlogon service can accomplish re-registration of all SRV records. You should also familiarize yourself with the different subdomains that are created beneath a domain in a Windows 2000 DNS implementation. The four main subdomains created are:

_msdcs – this subdomain is used to allow clients to find domain controllers providing specific services and running Windows 2000.

_sites – this subdomain is used to allow clients to find domain controllers providing specific services in a specific site.

_tcp – this subdomain lists services provided that use the TCP protocol to communicate.

_udp – this subdomain lists services provided that use the UDP protocol to communicate.

Service records and related entries can be verified by using both the DNS MMC snap-in, as well as by querying DNS using nslookup.exe. The syntax to query a DNS server for a list of all service records for a given domain is shown below:

C:\Nslookup >ls –t SRV 2000trainers.com

Changes to DNS in Windows 2000

In the Windows 2000 DNS implementation, a number of changes have been made. The most important include support for service records, dynamic DNS, secure dynamic updates, incremental zone transfer, and Active Directory integration. Each of these is described below:

Service Records – Windows 2000 DNS implementation provides support for an important type of resource record, service records (often referred to a SRV records). Service records allow a client to query DNS looking for a system running a particular service, such as a global catalog (which is designated by a GC record).

Dynamic DNS – In a traditional DNS implementation, all records needed to be created and updated manually on the DNS server, which could be extremely time consuming. The Windows 2000 implementation supports RFC 2136, usually referred to as Dynamic DNS or DDNS. In this implementation, clients are capable of automatically updating their records, which is especially useful in environments where clients use DHCP for IP address allocation. Windows 2000 is the only current Microsoft client OS that supports dynamic updates. However, it is also possible to configure a Windows 2000 DHCP server such that it updates DNS on behalf of clients, thus allowing non-Windows 2000 client information to be updated in DNS. Dynamic DNS is also especially useful for domain controllers, who can automatically register their service records – otherwise, all of these would need to be created manually.

Secure Dynamic Updates – if a DNS zone is Active Directory integrated, Windows 2000 allows you to use something called secure dynamic updates. Note that dynamic updates can potentially be dangerous because any client could potentially be registered in DNS, since dynamic DNS is only looking for a request, and is not authenticating the request. If secure dynamic updates are enabled, only a user or system that has the appropriate permissions on the associated access control list (ACL) for the zone can add a system to DNS. By default, the Authenticated Users group has these permissions. Client systems will attempt to use an unsecured request first by default, and a secure update if refused.

Incremental Zone Transfer – NT 4 DNS implementations only supported AXFR, or full zone transfers. Under this configuration, every time a primary name server did a zone transfers with a secondary, the entire zone database file was transferred, even if there were only a single change. Windows 2000 DNS supports IXFR, or incremental zone transfers. In this implementation, only the changes are passed during the zone transfer, as opposed to the entire zone database file.

Active Directory Integration – Windows 2000 still supports the traditional primary / secondary implementation of DNS. In that scenario, changes to the zone file could only be made on the primary, which had the only writable copy. Windows 2000 introduces a new concept here – Active Directory Integrated DNS. In this implementation, the DNS zone file and associated information is stored as objects in Active Directory instead of as files in the DNS directory on the hard disk. This integration basically allows any domain controller running DNS to accept changes to the DNS database, with changes to the zone file replicated as part of Active Directory replication. This also helps make DNS more fault-tolerant. In a traditional DNS environment, if the primary name server were to fail, all dynamic updates to DNS would be denied, since the writable copy would not be available. In AD-integrated DNS, all DNS servers are capable of handling an update. Note that legacy DNS servers can continue to exist – they can be secondaries, using the AD-integrated DNS server as a primary.

Planning DNS for Active Directory

Prior to installing Active Directory in a Windows 2000 environment, it is important to first design a DNS implementation that will meet both your name resolution and Active Directory requirements. Active Directory requires DNS in order to provide both name resolution as well as namespace definition, since domain names in Windows 2000 are based on the DNS naming conventions. As such, any servers on which you are installing Active Directory should have their TCP/IP properties configured to be pointing at a DNS server that you have already configured. If you choose not to do this, the installation of Active Directory will automatically create a DNS structure for you, which may not meet your needs.

Since a basic introduction to how DNS queries work was already covered earlier in the series, I am not going to repeat it here. Instead I am going to cover the main areas of DNS that you’ll need to understand in order to successfully implement the service for the purpose of supporting both name resolution and especially Active Directory.

The first concept that you’ll need to be familiar with is the use of DNS to resolve hostnames or fully qualified domain names to IP addresses. As a quick reminder, a fully qualified domain name (FQDN) provides the hostname as well as the domain name of a system. For example:

www.2000trainers.com

In this example, the hostname is the leftmost portion, or www. Hostnames can also be resolved using a HOSTS file, which is a static text file that exists in the %systemroot%\system32\drivers\etc directory on the local machine. DNS should not be confused with WINS, which maps Netbios names to IP addresses (as does the text equivalent, LMHOSTS).

DNS stores a number of different types of resource records beyond simple host or ‘A’ records. The most popular resource records that you’ll find in a zone file are outlined below:

SOA –represent the Start of Authority for a zone, and provides information about the zone including which server is the primary, who the administrative contact is, how often zone database files are checked for changes, database serial numbers, time to live values, and more.
A –represents a unique host address on the network, mapping its hostname to an IP address.
NS – outlines a domain name and the corresponding FQDN of name servers that are authoritative for that domain.
MX – designates that a given host is a mail exchanger (mail server or forwarder) for the domain specified.
PTR – provides reverse lookup capabilities by mapping the reversed IP address of a host to an FQDN. This allows the hostname associated with an IP address to be found. PTR records are found in reverse lookup zone files.
SRV – maps a particular service to one or more hosts. For example, records can indicate a server as a Global Catalog server, domain controller, and so forth.

The second main concept you’ll need to be familiar with is that of a zone. A zone is basically an area of the DNS namespace that functions as an administrative unit. That is, a group of name servers are responsible (have authority) for the records relating to a certain domain and/or subdomains. I like to refer to zones as areas of responsibility. For example, I could create a zone for the domain 2000trainers.com, and create 2 servers that would be responsible (authoritative) for holding records for the defined zone. I could then create a different zone, to be managed by someone else, for the domain asia.2000trainers.com, and have 2 other servers (maybe in Asia) that are responsible (authoritative) for the records in that zone. However, a zone can also encompass a number of domains, as long as they fall within a contiguous namespace. For example, 2000trainers.com and asia.2000trainers.com could be part of the same zone, and have a number of servers responsible for holding records relating to the two domains. If a query was sent to these DNS servers looking for a record ending in 2000trainers.com or asia.2000trainers.com, these name servers could answer the query, since they are authoritative for the zone, which includes the two domains. The main reason for having multiple zones usually relates to administrative authority, as well as zone transfer traffic. For example, perhaps I have one DNS administrator in Canada and one in Asia. Then, two zones may be warranted. By the same token, if I had only one zone, then all DNS servers (perhaps two in Canada and two in Asia) would all need to participate in zone transfers in order to receive updates. This may cause an unacceptable level of WAN traffic.

As a general rule, 5 main types of DNS servers exist which you should be familiar with. These are primary, secondary, active-directory integrated, forwarding, and caching-only. Each is described below:

Primary DNS Server – a primary DNS server is the name server that is authoritative for a zone. Essentially what this means is that this is the only server on which updates to the zone database can be made.

Secondary DNS Server – a secondary DNS server contains a read-only copy of the information stored on the primary name server, and obtains updates via zone transfers. A single secondary is the minimum suggested requirement, but many more can be created for the purposes of load-balancing and fault-tolerance.

Active Directory Integrated – limited to Windows 2000-based DNS servers, this implementation of DNS stores the zone file as an object within Active Directory instead of a series of files on the hard drive. In this scenario, every domain controller running DNS essentially acts as a primary DNS server, allowing updates to the zone file, and handling zone file synchronization via directory replication. As such, if any DNS server should fail, any other AD-integrated server can continue to make updates.

Caching-Only – a caching only DNS server is not authoritative for any zone. As such, it simply takes client queries, performs queries on other DNS servers, caches the results, and passes the answers to clients. By default, a caching-only DNS server will forward all queries for information not found in cache to DNS root servers.

Forwarder – DNS servers can be configured to sent queries that they cannot resolve to other specific DNS servers, referred to as forwarders. The forwarders will then work to resolve the query, instead of the individual DNS servers. This allows the number of requests sent to find hosts (on the Internet for example) to be reduced over time, as the forwarder handles these requests and caches the results, which are subsequently returned to the DNS servers making the request. The can improve both speed and efficiency.