by Brad Rhodes
This chapter covers the name resolution. Name resolution is important in computer networks because it allows one computer to locate resources that are available on the network. The name resolution issue is complicated by the fact that each of the network architectures addresses name resolution in their own fashion. The name resolution becomes tied to the network architecture.
There is relief on the name resolution issue. Network Operating systems like Windows NT 4.0 are doing a lot more to adopt and integrate the disparate name resolution schemes. This chapter, in particular, discusses how Windows NT provides the ability for using the Domain Name System (DNS) and the Windows Internet Naming System (WINS).
Computers that are connected over networks using the TCP/IP network protocol address each other using the IP addressing scheme. The IP addressing scheme follows the syntax of four dotted decimal numbers, such as 199.217.160.1. This address scheme is sometimes called a dotted octet representation. This address scheme allows for a clear network topology that relays to computers a lot of the information required for the computers to communicate efficiently.
NOTE: The Internet Protocol was specifically designed to enable computers connected to each other through a series of networks to very efficiently determine the destination of a given packet of information. A router can look at the information in the TCP/IP address, and quickly determine the best place to send the packet.
Name resolution in the TCP/IP network protocol enables network administrators to establish reasonable names for computers on the network. These names are given in an alphanumeric dotted format and are designed so that many people can easily remember or derive the name of the computer. For instance, it is much easier to remember www.ford.com than it is to remember the IP address of 198.108.89.236. Name resolution enables the computer name www.ford.com to be resolved to computer IP address of 198.108.89.236.
In the TCP/IP networking system, there are two common methods of name resolution available. There is a Hosts file for a local and simple method of name to address resolution. The Domain Name System is a distributed method of coordinating the name resolution of connected computers. In addition to the two common methods, there are a couple of less common systems for name resolution in the TCP/IP environment. They include high-end solutions such as X.500, and low-end methods such as a sheet of paper.
In the past ten years, the Networking Operating System (NOS) has been based upon primarily three network protocols. These protocols are the TCP/IP protocol that began in the UNIX operating system and is the basis for the Internet, Novell IPX/SPX protocol that is the basis of the Novell NetWare operating system and NetBIOS protocol that was originated at IBM and is the basis of the LAN Manager network operating system.
Although the network operating system can be implemented independent of network protocol, the network protocol ends up heavily influencing how the resources on a network are located. Both Novell and Microsoft currently release their servers with the capability to use multiple protocol stacks. There are several implementations of IPX/SPX and NetBIOS protocols in the UNIX operating system.
How resources are located on a network is the name resolution scheme. A little understanding of how the three network protocols resolve their names will help you understand the complexity, as well as the need, for the DNS system in the TCP/IP protocol.
Novell IPX/SPX Name Resolution
The easiest of the three network architectures is the Novell NetWare IPX/SPX environment. When Novell implemented the IPX/SPX architecture, it knew that its main targeted environment was going to be the small business and that the administration of the system would have to be kept to a minimum. To keep the naming scheme simple, NetWare relied on keeping all of the naming functionality on the server; this is prior to the Novell Directory System (NDS) in NetWare 4.0. If a client wanted to find a resource, it just asked the server. The primary server that enabled the client to access the network was responsible for knowing how to access all of the resources available on the LAN.
This solution works great when there are a large number of clients and few servers. The problem develops when a client wants to begin sharing data with other clients. In this type of network, the server will quickly become a bottleneck just tracking all of the available network resources. In addition, as the network grows, it will be difficult to ensure that the server always knows about all of the resources on the network. With the release of NetWare 4.0 Novell has added the NetWare Directory Service (NDS). The NDS enables the directory of resources and their location to be implemented in distributed database fashion. There are a lot of similarities between the DNS system and the NDS system. The main difference is that the DNS system is primarily used for the location of machines. The NDS system contains information on every aspect of the resources on a network.
NetBIOS Name Resolution
In the design of the NetBIOS network operating protocol, the designers targeted LAN based workgroups. In the NetBIOS environment, the name of resource and how to connect to it is broadcast over the network. When a client wants to connect to a server resource, the client broadcasts the name of the service that it is looking for. When the server named resource is reached, the server needs to reply to the broadcasting client. The main advantage is of this architecture is that it is very simple to implement peer type servers where all of the clients on the network can easily advertise available resources.
See "Using TCP/IP With Windows NT Server," (Ch 9)
The main disadvantage of this operating environment is the continuos broadcast of large numbers of packets while clients look for resources on the network. The broadcast packets can not be routed. The broadcast name requests would quickly use up the available router bandwidth. With the release of Windows NT 3.5 Microsoft introduced the Windows Internet Naming Service that provides a mechanism of letting NetBIOS resources be located from a central resource.
TCP/IP Name Resolution
There are two main forms of name resolution in the TCP/IP networking environment. These are the use of a local hosts text file and the use of the Domain Name System.
These two TCP/IP naming techniques provide different operating benefits and costs. On small networks, the hosts file is easy to understand and is simple to setup and manage. When the network grows, the hosts file becomes unwieldy and the more advanced Domain Name System provides the network administrator an advance naming system. The following two sections provide an overview of the Hosts file and DNS naming in a TCP/IP environment.
The precursor to the Internet was a network of research computers called ARPANET. When the administrators began setting up the ARPANET network of computers, they first relied upon a name resolution based on a hosts text file. A sample of a hosts text file relates the format of the information in this file (see Listing 10.1).
See "Implementing Intranet and Internet Technologies," (Ch. 16)
# Copyright © 1993-1995 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows NT. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) can be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host 127.0.0.1 localhost 199.217.160.2 someserv.allnet.net 170.310.133.5 anotherserv.busnet.com
NOTE: The hosts file on Windows NT systems with TCP/IP installed and configured is located in the \winnt40\system32\drivers\etc directory.
The records in the hosts file that begin with a pound sign (#) are comments. These records are not processed by the system and are used to make notes so that other administrators can more efficiently read the hosts file. The address records begin with the IP address of a machine in the three dotted decimal notation. The final part of the record is the name of machine for the given address.
NOTE: It is typical that the names in the hosts file are set up in a hierarchical format. The rightmost part of the name is the top of the hierarchy.
As the number of computers connected to the ARPANET began to grow, it became evident that one central authority would need to keep and maintain a master hosts file for the entire network. The group that ended up with the job was the Stanford Research Institute's Network Information Center SRI-NIC.
A number of issues combine to make this scheme of centrally managing the TCP/IP host names for the entire network became increasingly burdensome. The first issue was that someone had to be available to take requests for new network numbers and their associated machine names. Each time someone added a new computer to their network this person would have to make an entry in the master hosts file so that all of the other computers on the network would be able to locate that machine. Additionally they would need to make the master hosts file available to administrators of all of the machines connected to the network so that they could download the file and update their hosts file. Only after all of this would the new machine on the network be available by name.
As the number of new computers connected to the network per week grew, the pressure to update the master hosts file more often also grew. This growth also meant that the number of computers that had to be manually updated with a new hosts file also grew. The net result was that more and more computers were needing to download a growing master hosts file more often.
One last issue made the hosts file unmanageable when large number of hosts were connected to the network. The hosts file was typically ordered by the IP address of the machine. The IP address of a machine was resolved by linearly searching through all of the hosts records until a matching host name was found. This linear search would become unreasonably long as the number of hosts gets large. Also if a host name is added to hosts file with the same name as that of an existing host the machine first listed in the hosts file would be the address to get resolved. The second machine listed in the hosts has been replaced by a new machine.
All of the packets that were destined to the second machine now arrive at the first machine. If this second machine was an important mail node, at a university or large company, all of this mail would now be routed to the first machine. This would enable the first machine to impersonate and steal all of the second machines identity. When a hacker uses this type of a mechanism to look like another machine, either to steal information bound for that machine or to cover his illegal activity, this is known as spoofing.
The Domain Name System was created to provide a highly scaleable and more manageable solution to the mapping of host names to IP addresses. The DNS system was designed to address many of the problems associated with the Hosts name resolution discussed above.
The DNS system is designed to have the distribution of the naming service spread across large numbers of machines on the network. This way no one machine becomes a single source of failure or bottleneck for the entire network. The DNS system relies upon a concepts of zones, authority and domains to distribute the name resolution load. The DNS system pushes the responsibility of resolving a name to the DNS server thereby allowing the client to make one request to the server. The server then issues multiple searches to resolve the address. This enables the resolver client to be very light weight in its processing, configuration, and memory requirements.
Figure 10.1 provides an overview of the name resolution process for a common name lookup. Here it is seen that the desktop client named desktop.gasullivan.com is requesting from the default name server namesrv.gasullivan.com the address of www.microsoft.com. Figure 10.1 shows that the iterative search for www.microsoft.com is conducted by namesrv.gasullivan.com on behalf of the client requesting the address. When the IP address is returned to desktop.gasullivan.com, it is used exactly the same as if the IP address were gotten from a hosts file.
The desktop clients main DNS server, namesrv.gasullivan.com, iterativily searches the DNS name space by contacting other DNS servers.
The example shown in Figure 10.1 is not exactly how the name space is searched to resolve the name to an address. If it were the Root domain, name server would be a bottle neck and source of failure for the whole system. In reality, the namesrv.gasullivan.com would typically be configured with a set of hints, stored in the "cache" file, that describe where all of the top level domain name servers are located.
The design of the DNS system was developed by Paul Mockapetris of USC's Information Sciences Institute and was submitted to the Internet Engineering Task Force as RFC's 1034 and 1035 in 1984. A popular implementation of the DNS system was the Berkley Internet Name Domain (BIND) implemented for Berkeley's 4.3BSD version of UNIX by Kevin Dunlap. The source code for BIND was ported to most major versions of UNIX and is the basis for the DNS server in the Windows NT Server system.
The first section of this chapter introduced the following two primary forms of name resolution in a TCP/IP network:
This section helps to determine which network managers will need to consider setting up a full Domain Name System server.
The following are the issues that are important to the consideration of the DNS server:
The most important issue in determining the need to establish a DNS server is the size and complexity of the network that is going to be established. The larger and more complex the network is going to be, the more likely the network manager will benefit by establishing a DNS server at the start.
As discussed in the first section of this chapter, the DNS name resolution scheme was designed to relieve the administration headaches that grow from managing the hosts file for name resolution. The more complex a network is, the more the network administrator will benefit from the DNS systems manageability features.
The first factor in deciding if you should establish your own DNS is the size and complexity of your network. It is possible to start a network using the hosts file method of resolution and switching over to the DNS server at a later time. Unfortunately, switching a bunch of Windows NT workstations, Windows NT servers, or Windows 95 machines set up from hosts resolution to DNS name resolution involves going to each machine and changing the TCP/IP settings to use DNS. Even on a 25 computer network this becomes a several day task. If it appears that your TCP/IP network will grow to even this modest level, it is likely that you need to consider establishing a DNS server.
The second factor to consider is the connectivity of the network to the Internet. If your network is connected to the Internet via an Internet service provider (ISP), you have the option of getting your DNS services from your ISP. In a typical small network (fewer than 10 nodes), the DNS service offered by an ISP will be adequate. Most ISPs offer DNS services for corporate based connections. The draw back of letting your ISP provide your DNS server is that when it becomes time to change any of the addresses on your network, you will have to coordinate these changes with your ISP. This is an error prone process, and if there are a large number of changes, you will end up spending a lot of time coordinating these changes with the ISP.
The DNS system does not have to only be used on networks that are connected to the Internet. If you are the network manager of a network that will not be connected to the Internet and you want to take advantage of the TCP/IP networking architecture, the DNS system will help manage the naming of the machines on the network. If the network is a large network or a bunch of geographically separated interconnected LANs, the DNS system will be very helpful in managing the network names.
The third factor is the type of applications that are being supported on the network. If you are the network manager of a network that is to provide a large number of Internet based services to people on the Internet, you will probably want to have a DNS server. The DNS server will enable you to properly configure and name your servers so that people on the Internet will be able to reach the servers. It will come in extremely handy when you decide to move or change the configuration of your Internet servers.
The most important part of the DNS system is to provide name resolution for a TCP/IP computer. Prior to configuring a DNS server it is important to develop an understanding of how the DNS system provides name resolution. The following are the two main topics that explain the DNS name resolution process:
The name space is the organization of the DNS systems distributed host name database. The resolution process is the way that the name space is searched for the matching host name so that the corresponding IP address can be returned. Finally, the concept of a zone will help you understand how the DNS name space is distributed across a group of DNS servers.
The DNS system client/server architecture highly depends upon distributing the storage of the host name information under its control across large parts of the network. This enables the system to be scaleable, reliable, and manageable. The distributed database enables the DNS to be scaleable as the queries for resolution are distributed to a large number of machines. The millions of queries that are resolved on the Internet each day could never be accomplished on one single machine, they must be distributed to a large number of systems. The distributed database within the DNS provides a more reliable solution by making separate nodes that will duplicate data. The distributed nature provides mechanisms that will copy data from one server to another or refer a query from one server to the next. If any one server is down, the DNS query can typically be resolved by another system.
If an important number of DNS servers are unavailable, only those hosts that are covered by the down DNS servers will be unreachable. The rest of the DNS system remains intact and usable. The distributed database makes the whole system more manageable. The distributed database allows configuration changes in the layout of the data in the DNS system to propagate easily through the system. New servers can be added and old servers can be removed with very little intervention by the network manager.
The distributed database that is the DNS system is laid out like any operating systems file structure. This tree structure is most like the UNIX file system: There is root to the file system, and the subdirectories spawn off of the root (see Figure 10.2).
Here the DNS name space is viewed as the directory or tree structure of an operating system file structure. The files are host names and the subdirectories are new domain names.
This tree structure can be traversed up or down the tree to find any one given node. The biggest difference with the DNS system is that the DNS tree resides on more than one machine. The data in Figure 10.2 that contains the information on the .microsoft.com domain would reside on a DNS server that is located at the Microsoft facility. The data contained in the Berkeley domain under the .edu domain resides on a DNS server that is at the Berkeley campus (refer to Figure 10.2).
The domain name server name space is searched just like the directory tree on a machine is searched. A quick comparison of the directory tree structure search and the search of a file on a file system will help you understand the name space. In the file system search, any one file can be identified by the full path name. In Figure 10.3, the file Wordpad.exe is identified by the full path name c:\Program Files\Accessories\wordpad.exe. In the DNS name space shown in Figure 10.2, the system Web server www at Microsoft is identified by the fully qualified DNS name of www.microsoft.com.
The file system structure as seen on a Windows NT machine. The subdirctories split off the root and the files are nodes on the subdirectory.
The main difference between a DNS name and a file system name is the order of names in the tree. A smaller difference is that the file system uses the a slash to separate names and DNS uses a period to separate names. The order of a DNS name is reversed when compared to a file system name space. The file system name space starts with the broad high level name on the left and goes down the tree to the more specific name as you go to the right. For instance, the full path name of c:\Program Files\Accessories\wordpad.exe starts at the root directory of \.
The Program Files directory is the first level directory underneath of the root file system. You traverse the path name until you come to the specific file. The DNS system is organized in the same fashion, except that you start from the right of the fully qualified DNS name. The DNS name www.microsoft.com ends with the .com high level domain. This is the first level domain underneath of the root domain name in the DNS name space. You continue to traverse the name space to the left until you reach the actual node.
The main difference between the DNS name database and the file system database is that the DNS name database is distributed across multiple network nodes. This is done through delegation. The DNS system enables the root name server or any other name server to delegate the authority for a given segment of DNS names to another server. This allows the database to be distributed across a large number of nodes but still ensures that any one machine can find and access all of the data.
An example will help to explain how the delegation will take place when a host name is being resolved. Figure 10.4 shows two corporate domains under the .com high level domain: the Microsoft domain and the G. A. Sullivan domain.
A simplified domain tree that shows portions of the G. A. Sullivan domain and the Microsoft domain.
In this example, you are on the workstation desktop.gasullivan.com and want to access information on the server www.microsoft.com. Your workstation is set up to use the DNS server of name-srv.gasullivan.com as its default DNS server. To resolve the www.microsoft.com, your workstation will ask name-srv.gasullivan.com for the IP address of www.microsoft.com. The desktop machine desktop.gasullivan.com will issue a recursive name resolution query to name-srv.gasullvan.com. Remember that name-srv.gasullivan.com will resolve the address for the requesting client. This is Step 1 in Figure 10.5.
This figure detials an example of how the DNS name space is iterativly processed to resolve the destination host.
In step 1 in Figure 10.5, desktop.gasullivan.com asks name-srv.gasullivan.com for IP address of www.microsoft.com. This request is a recursive name resolution query. A recursive request tells name-srv.gasullivan.com to search the DNS system for the host name www.microsoft.com. The DNS server name-srv.gasullivan.com should not respond until the host name is located or there is an error locating the host.
The server name-srv.gasullivan.com will recognize that it does not know the address of www.microsoft.com and that no servers below name-srv.gasullivan.com will know the address of www.microsoft.com. In step 2, the request will be forwarded up to the next higher level of the domain name space, the root domain. The actual forwarding will be done by the DNS server name-srv.gasullivan for the workstation desktop.gasullivan.com. The DNS server name-srv.gasullivan.com will send an iterative name resolution query to one of the root name servers for the domain. An iterative query will either return the actual IP address of the host name or will return the IP address of a DNS server that is closer to the host.
The root domain name server will know that it has delegated authority for the .com domain to the DNS server dns1.root-servers.com. The root name server will tell name-srv.gasullivan.com that dns1.root-server.com is the authoritative name server for the .com domain. This is step 3 in Figure 10.5.
The .com server tells name-srv.gasullivan.com that dns.microsoft.com is the authoritative name server for the microsoft.com domain. This is step 5 in Figure 10.5. Once name-srv.gasullivan.com receives this response, it will query dns.microsoft.com for the IP address of www.microsoft.com (step 6 in Figure 10.5). Because dns.micorosoft.com is the DNS server that is authoritative for www.microsoft.com, this DNS server will respond to the request with the IP address of www.microsoft.com. At this time, name-srv.gasullivan.com replies to desktop.gasullivan.com with the IP address of www.microsoft.com. This is step 8 in the Figure 10.5.
This might seem like a lot of activity to resolve the one address. The DNS system provides for caching as a means to reduce the need for so much request response activity. In this example, the DNS server name-srv.gasullivan.com will cache several addresses the first time this query is issued. The first piece of information is the host name and IP address of the name server for the .com domain. The second piece of information is the IP address and host name for the DNS server that is authoritative for the microsoft.com domain, dns.microsoft.com. The third piece of information is the actual IP address and host name of the server www.microsoft.com. Any further requests for the www.microsoft.com server will be answered directly from the cache on name-srv.gasullivan.com. If a request is now received at name-srv.gasullivan.com for ftp.microsoft.com (another server at Microsoft), this request is fulfilled by name-srv.gasullivan.com directly asking dns.microsoft.com.
This caching scheme is designed to ensure that popular and recently visited sites are found in the cache of the nearest DNS servers. Less frequently accessed sites are flushed from the cache. Each DNS server response in the above example will include a Time to Live (TTL) number. This number is the number of seconds that the domain record should be kept active in a cache. This enables the Authoritative name serverñthe name server that is responsible for the hosts in that part of the domainñto determine how records pointing to its servers are to be cached. Once the record has been in the DNS servers cache longer than the TTL value, it is flushed and the root name servers are queried again to make sure that most valid data is available.
The resolver is the portion of the TCP/IP client software that issues a request to a DNS server for a name resolution. The resolver library is automatically called whenever the workstation is configured to DNS for name resolution. There are three types of DNS queries that can be issued to a DNS server: recursive, iterative and reverse.
NOTE: DNS servers will receive queries from DNS clients and other DNS servers.
A recursive name resolution query tells the server that it is to either resolve the host name to the IP address of the server or to return an error code. The error code could indicate that the host name does not exist in the domain or that the domain does not exist. Most clients that are not DNS servers will issue a recursive query to their assigned DNS server. This enables the client to issue one request and sit back and wait either for the IP address or an error code to return. This corresponds to step 1 in Figure 10.5.
Iterative queries will return either the IP address of the destination host or the IP address of a DNS server that is closer to host that is being resolved. This type of query is issued by one DNS server to another DNS server. If the IP address of the destination host is returned, then the DNS server has finished resolving the DNS query and returns the value to the requesting client. If the response to an iterative query is the IP address of another DNS server, this is called referring. The responding DNS is referring the requesting DNS up or down the domain hierarchy tree to a DNS that is closer to the destination host. This type of query is the same as that shown in steps 2ó3 and steps 4ó5 in Figure 10.5.
This process is very similar to the change directory command in a file system. The DNS server that is resolving the host name will continue up the domain tree until it reaches a point high enough that the destination host is under a lower level domain. The DNS server will traverse down that branch of the tree until the DNS that is authoritative for the host is reached. This DNS will respond with the IP address of the destination host.
A reverse name request enables the DNS client to request the host name of the host that has a given IP address. The section Reverse Name Resolution explains how the reverse domain name space is constructed. When the client request the reverse name resolution of an IP address, the reverse name space is searched just like the forward name space. If a client is requesting the host name of the IP address 207.68.156.61, the DNS servers will search for the host name with a PTR record of 61.156.68.207.in-addr.arpa. Again, the DNS server handling the request will walk up the domain hierarchy until high enough that the domain is below. It will then walk down the domain hierarchy until the host name for the IP address is exactly matched.
The majority of DNS systems that are set up will be connected to the Internet. The Internet is an extremely large example of the DNS name space. It is a good example of how the distributed DNS database allows a network to be scaled to extremely large sizes. Until recently the Internet was divided into seven top level domains. These top level domains are truly how most people, especially those in the United States, view the Internet. The seven domains are as follows:
This original domain hierarchy was dictated by the most powerful organizations that were involved in the Internet during the early formation of the Internet. The majority of these organizations were United States specific organizations. With explosion of the Internet over the last couple of years especially in countries outside of the United States it has become necessary to redesign the domain layout of the Internet. The current domain layout is in accordance with the specification ISO 3166. In ISO 3166, each country gets a domain hierarchy much like the upper-level one shown in the previous list for the United States. So for the Australians there is a domain hierarchy that includes com.au, edu.au, and so on. Not all countries follow this guideline.
The DNS system has two primary concepts when considering how the name space is divided up. The main and most evident is the concept of Domains. A domain is a division in the name space shown in the name. For instance, the microsoft.com domain is a subdomain of the .com domain. The division of the name space and placement of the data in this example makes the distinction between a zone and a domain more clear.
A zone is actually all of the data that is contained under a given DNS server. This is not necessarily all of the data that is associated with the subdomain being managed by the DNS server. For instance, the site gasullivan.com is divided into five subdomains and the DNS server name-srv.gasullivan.com is the Authoritative DNS server for the gasullivan.com domain. The five subdomains of gasullivan.com are as follows:
Of the five subdomains of gasullivan.com, the research and product subdomains are of a large enough size that they can have their own DNS server (see Figure 10.6). The srv.gasullivan.com name server is set up to delegate authority of the research and product domains to dns1.research.gasullivan.com and printsrv.product.gasullivan.com, respectively.
This expanded gasullivan.com domain includes the reverse name domains.
The difference between a zone and a domain can now be shown. The domain for gasullivan.com includes all of machines that are named *.gasullivan.com, *.training.gasullivan.com, *.research.gasullivan.com, *.management.gasullivan.com, *.systems.gasullivan.com, and *.product.gasullivan.com. The name-srv is the authoritative DNS server for this domain. The zone that is attributed to the name-srv.gasullivan.com server are those servers that are actually held in the name-srv.gasullivan.com databases. Because the research and product subdomains have been delegated to different DNS servers, these servers are no longer in the zone controlled by name-srv.gasullivan.com.
A split in the domain is like adding a tree in a directory on a file system. A split in the zone is when the authority for a split in the domain is delegated to another DNS server. It is not possible to have splits in a zone that do not correspond to splits in the name space. For example, all of the machines at the *.management.gasullivan.com level must have the same DNS server and all of the machines at the *.gasullivan.com level must have the same DNS server. Only when a subdomain is split off of the name space can a new zone be created.
A zone is a single coherent piece of the DNS name space. When one zone is configured to be a backup server for another DNS server, the backup server will request a zone transfer from the primary server. Once the backup has received the zone, it knows that it has the most recent backup of the primary DNS server. Primary domain backup can be used to create a secondary DNS server that mirrors the primary server for reliability and backup purposes. The secondary DNS could also be established to provide faster name resolution for a group of machines that are connected to the primary through a slow or WAN network connection. This way the name resolution packet will not have to flow over the slow network connection.
The DNS system provides a method for allowing the resolution of a network nodes host name given the nodes TCP/IP numeric address. This enables a system to log incoming network requests in terms of the host name not just the TCP/IP address from where the request is coming from. Reverse name resolution is very important to the overall architecture of the DNS system.
Several UNIX utilities use the reverse name resolution to verify that the person is coming from a valid machine on the network. For instance, the server part of the FTP connection could double check that you are a valid address on the Internet. The server part of the FTP connection is the ftpd program. The ftpd program could verify that a log in request is coming from a valid machine by using the TCP/IP address.
Every packet contains the TCP/IP address of the machine that is making the request. Once ftpd has this TCP/IP address, it can do a reverse name resolution to get the host name of the requesting machine. Now that it has the host name it can do a forward name resolution. This will return the actual TCP/IP address of the requesting machine from the official Internet DNS systems. If this new TCP/IP address does not match the original requested TCP/IP address, this is an indication that the original request did not come from where it stated.
How does reverse name resolution occur in a DNS server. From our discussion to this point, the DNS system is set up to resolve host names to TCP/IP addresses. The DNS server maintains a list that is sorted by the host name. During forward name resolution the list is searched in the sorted order until the name is found and the TCP/IP address is returned. These sorted searches are greatly more efficient than a linear search of the host names. Using a small indexing system improves this lookup time even more. Figure 10.7 shows how the names come out in a sorted fashion.
The list of domains is parsed and sorted. The name is broken at the periods and the indivual components are reversed. The list is then sorted and built.
Because the list is already sorted by host name, there are two possibilities for reverse name resolution. The list could be linearly searched on the second element of the list, the TCP/IP address. Or the list could be duplicated and sorted by TCP/IP address. The linear search would be problem for two reasons. The first is inefficiency. The second is the spoofing problem that was introduced earlier in the section "Hosts File Name Resolution." Spoofing could occur when a record is added to the DNS host table with a TCP/IP address that is a duplicate of an existing host. Now the reverse name resolution that is relying on the linear search of the TCP/IP address could return a different host name. Reverse name resolution relies upon keeping a second list that is sorted by TCP/IP address.
It would have been easy to take the initial host name list that is being added to the server and resort the list based upon the TCP/IP address instead of the host name. The DNS system does not do this because the reverse name resolution can solve another very important architectural issue for the DNS system. This is how the domain numbers themselves are assigned and managed. The DNS system uses a second input file and creates a whole new domain space that is tacked on to the root of the main DNS system for tracking the TCP/IP to host name resolution information.
In the name space, the reverse names are stored under a specially created domain. In Figure 10.8, the arpa domain is a subdomain split off of the root. There is also the in-addr domain that is split off of the arpa domain. This special domain constitutes the reverse name space. Under the in-addr.arpa domain, the TCP/IP addresses form subdomains.
The current IP address is reversed and it is added to the in-addr.arpa domain. This forms the reverse domain name space.
Notice that the address is broken up at the dots and used to form the directory-like structure. The full DNS reverse name resolution domain name of beast.gasullivan.com (199.217.177.1) is 1.177.217.199.in-addr.arpa. The name is pieced together just like the host name. In the host name, the lowest level node in beast.gasullivan.com is beast and this is the first name in the domain name. In other words, the reverse name space names are formed just like the host name part of the name space (see Figure 10.9).
The list of reverse domain names are parsed and sorted like the list of domain names.
Like the forward name space the reverse name space is kept in sorted list in the DNS server. The list is built in exactly the same manner as the forward host name list. This list facilitates the use of indexes to reduce the amount of memory needed to store the list and to greatly reduce the amount of time that it takes to search the list.
These two special domains under the in-addr.arpa reverse name domain solve some minor problems with how DNS replaces the hosts text file for name resolution. Often, TCP/IP applications send requests for the reverse lookup of 0.0.0.0 IP address or the 127.0.0.1 IP address. The 0.0.0.0 IP address is an undefined addresses. It is a waste of network resources to allow resolution of this address to propagate all of the way to the root name server before getting an undefined host or domain error.
The 127.0.0.1 address is the loopback IP address. All TCP/IP systems should route packets sent to this address back to the same machine, loopback. If an application is set up to do reverse name resolution and is getting logon requests from the localhost, then the packet will often contain the IP address of 127.0.0.1. When the application requests a reverse DNS request on this IP address, if there is not a 127.in-addr.arpa domain on the server, then this request will again go all the way to the root server before receiving an error or an invalid response.
In order to diminish the impact of requests on these two special IP addresses, every DNS server should define PTR records in the 0.in-addr.arpa and 127.in-addr.arpa domains.
CAUTION: It is considered to be in bad taste, or lazy, to set up a DNS server that does not resolve these special domains. If your DNS server does not resolve them and they are not resolved on the client, then these requests are forwarded to the next higher server. This can result in a lot of needless overhead on a busy or large network.
The DNS server system enables a DNS server to be either a primary or a secondary domain name server. A primary domain name server reads its name resolution data directly from files that reside on the server. A secondary server obtains the name resolution data by requesting a zone transfer directly from a primary DNS server. Changes to the machines in a zone must be made to the primary server. The secondary server updates its files from the primary DNS server.
It is highly recommended that any given zone be on two DNS servers, a primary and a secondary. This provides the necessary redundancy that a DNS server requires. If a DNS server is not available for an organization, then anybody trying to get to resources on the network or trying to get out to the Internet will get name resolution errors.
Although the DNS server implemented on the Windows NT Server operating system is guaranteed to inter-operate with the BIND implementation of DNS that many of the UNIX systems are based upon, Microsoft implemented a few additions to the basic DNS server to ensure tight integration with the Microsoft Windows NT Server environment.
Microsoft changed the DNS server code to allow for a tight integration with the WINS naming server. The WINS server and DNS server will now share name spaces. This is primarily done to allow DHCP registered NetBIOS names that will show up in the WINS server to be resolved by DNS requests.
Microsoft also changed the DNS resolver, to enable NetBIOS name resolution and TCP/IP name resolution to interoperate. The DNS resolver is the actual code on a DNS client machine that initiates a name resolution request with a DNS server. Microsoft added a NetBIOS name resolution ahead of the normal DNS name resolution. This allows machines set up for NetBIOS over TCP/IP to use local NetBIOS resolution.
See "DNS and WINS Integration," (Ch. 10)
The Windows NT operating system has roots in the Microsoft LAN Manager server. This server operating system was based heavily upon the NetBIOS networking architecture. The root level of how Windows NT workstation and server operating systems share resources is through a NetBIOS based protocol. As discussed in "NetBIOS Name Resolution," the NetBIOS architecture relies on broadcasts to resolve names of available servers on the network. This scheme has shown to be very costly on large networks that are interconnected with WANS.
In order to address this problem, Microsoft has implemented the WINS naming database service. The WINS naming service enables the NetBIOS name of a service to be directly mapped to an IP address. Microsoft has since extended the WINS naming service to allow the DNS system in place on many networks to actually provide the name resolution. The WINS server in a DNS server environment will append the NetBIOS name to a configured domain name and pass the resolution request on to the DNS server.
In addition, the DNS server has been enhanced to enable the DNS server to attempt to resolve a host name through a request to the WINS server. The DNS server can be configured with an unlimited number of WINS severs that should be tried for host name resolution requests. When configured in this fashion, the DNS server attempts to resolve the host name from its database files. If it does not find an A record in its local records and the host name is less than 15 characters long, the DNS server will attempt to resolve the name from the WINS servers.
On the Windows NT operating system, the resolver library has been modified over the normal TCP/IP resolver. The Windows NT TCP/IP resolver library is also used to resolve NetBEUI. Microsoft calls the resolver the NetBT networking component. NetBT stands for NetBIOS over TCP/IP. The NetBT component acts a little different than the standard TCP/IP name resolver in that NetBT will look at the name that is being requested. If that name is less than 15 characters long and does not contain any periods, NetBT will attempt a NetBIOS name resolution on the name. If this fails, then NetBT will do a normal TCP/IP name resolution.
The Dynamic Host Control Protocol (DHCP) also presents one challenge to the name resolution. If a client computer on the network is currently configured to use DHCP to obtain the IP address, then the DHCP system enables the network manager to configure a server to dynamically assign IP addresses. There is no provision in the DNS system to allow for dynamic updates of the DNS configuration data. As a result, because the IP address is assigned on the fly, it is not possible for someone outside of the current network to establish a connection to a machine that is getting its IP address dynamically. If you are setting up a machine that people on the Internet need to reach, you must to make sure that you assign that machine a static IP address.
There are nineteen individual data record types available for the DNS server database. These records follow the basic format of
hostname.company.com IN A 199.217.160.1
Where the first field in the record is the hostname of the machine referenced in the record. The second field is the class type. The class type is almost always IN for the Internet class type. The only other type currently in use is HS for Hesoid used at MIT. The third record is the record type indicator. This is an A record, which is an address record type. The last field in the record is the IP address for the host. Table 10.1 explains all of the individual record types that can be found on the DNS server.
| Record Type Indicator | Description |
| A | Basic address record, which is the most used record in the DNS system. The A record tells how to map a host name to an IP address. |
| AFSDB | Andrew File System (AFS) cell database server. This enables a client on the AFS system to locate an AFS authenticated name server. |
| CNAME | Canonical name resource. This enables alias names to be created for the same IP address. For example, if you want to add ftp.gasullivan.com to your network and want it to point to an existing machine, such as devserv.gasullivan.com, then use a CNAME record of ftp.gasullivan.com CNAME devserv.gasullivan.com. |
| HINFO | The host information record type. This is an optional record that enables the information about the DNS hardware implementation and operating system. RFC 1700 covers the appropriate names to fill in these fields. This record is only rarely used. |
| ISDN | Same as an A record, but maps a domain name to an ISDN address. This record is experimental and rarely used. |
| MB | The mailbox resource record. This is an experimental record that is rarely used. |
| MG | The mail group resource record. This is an experimental record that is rarely used. |
| MINFO | The mailbox information record. This is an experimental record that is rarely used. Other experimental records that are related to the MINFO are the MB, MG, and MR records. |
| MR | The mailbox resource record. This is an experimental record that is rarely used. |
| MX | The mail exchange resource record. This record is at the heart of Internet mail distribution. The SMTP mail transport system relies on the MX record to determine how to find the destination of the SMTP message. Servers that are listed in the MX record need to be running an SMTP messaging server that is properly configured. |
| NS | Name sever record. It identifies DNS servers for the domain. Every domain must have a NS record in the zone records and in the reverse zone records. |
| PTR | Reverse name lookup record. This record is used in the in-addr.arpa to support reverse name resolution. |
| RP | Responsible person record. This record is used a lot like the HINFO to provide additional information to those who know to look for it. Multiple records of this type in a domain provides data on those responsible for the domain and how to contact them. Like the HINFO, this is optional and very few people set up this record. |
| RT | Route through resource record. This tells an intermediate host how to route data packets to a destination host. The destination host is usually one that is established in an ISDN or X.25 resource record. This record is experimental and rarely used. |
| SOA | Start of authority record. This tells the DNS systems that this DNS is authoritative for this zone. It contains information on the amount of time that the data from DNS can be cached, and a contact person for this DNS. The rest of the fields in this record affect how secondary backup DNS servers use the data from your DNS server. |
| TXT | Used to generate general textual information. Could be used to indicate the location of a machine. This record is rarely used. |
| WINS | A record that points to the IP address of an available WINS server. This is a record that is specific to Microsoft, and cannot be edited in the DNS manager. |
| WINS_R | This record tells the Microsoft DNS server to use a NetBIOS name request to get the name of a resource. |
| WKS | The well-known service record database. This record enables certain TCP/IP ports to use a specified protocol. The protocol is almost always UDP or TCP. For example, to set up your SMTP gateway to accept the UDP protocol, you would use machine.mycompany.com IN WKS 199.217.160.1 SMTP. At one point, the WKS record was required for SMTP. This has since been dropped: too many sites failed to implement this correctly. |
| X.25 | X.25 resource record. This is very much like the A resource record. It maps a domain name to an X.25 address. |
Although this list looks like a long list of selections, there are only four records that really need to be understood. They are the SOA record, the A record, the PTR record and the MX record. If you have these records set up correctly, your DNS should function correctly.
The implementation of a DNS server on the Windows NT Server operating system is very similar to the steps that are taken when setting up a DNS server on a UNIX system or any other system. There are a series of implementation level concepts that should be understood prior to implementing a DNS server.
CAUTION: The DNS Manager for Windows NT works much better after you apply the first service patch for Windows NT 4.0. You should apply all of the available patches prior to setting up your DNS server.
There are several ways for the network administer to get a real boost in establishing a DNS server. The first place to look at getting a head start is from your ISP. If you are the manager of a small network that is currently getting DNS services from your ISP, then your ISP has already established the majority of the information that is needed to configure your DNS server. Most reasonable ISPs will happily provide you with those portions of the configuration files that impact your network.
A second place to get a head start is a utility that creates DNS configuration files from a hosts file. The utility is called h2n, host to name. It is a Perl script that will take an existing hosts file and generate the associated DNS server configuration files. It will not create exactly all of the files in the right format but is a great starting point. The h2n utility can be found in several locations on the Internet using any of the search engines.
A third place that configuration files can be started is from an existing UNIX DNS server. I will discuss how the UNIX DNS server configuration files can be used directly by the Windows NT DNS server. If your network has a DNS server running on UNIX, then consider establishing a backup DNS server on a Windows NT Advanced Server or moving your DNS server from UNIX to Windows NT Advanced Server. In this case, there are two options for setting up the Windows NT DNS server. The first option is to copy the configuration files from UNIX to your Windows NT DNS server directories. The second option is to set up the Windows NT DNS server as a backup DNS server. Once the zone transfer from the primary to the secondary server has occurred, the new Windows NT DNS server will now have all of the configuration files it needs.
Prior to going into the concepts that are important in setting up the DNS server, I should point out one important difference between the DNS server on Windows NT and the DNS server on text based operating systems, such as UNIX. Windows NT ships with a graphical DNS server administrator tool. This tool greatly simplifies the management of your Windows NT DNS server. By default changes made to the DNS server configuration are stored in the Registry. There is a little known option in the DNS managers options property pages that forces the Windows NT DNS server to read and save the configuration in files instead of the Registry. If you change the setting to use the configuration files, the DNS configuration files from the UNIX system can be copied into the DNS server directory. The DNS server keeps its configuration files in the \winnt\system32\dns directory.
When using configuration files instead of the Registry to store DNS configuration information, the DNS manager will behave slightly different. The subtle differences have to do with that in certain situations the data is not correctly written to the data files. This appears to get better with each Windows NT 4.0 Service Patch. As of Service Patch 2, these differences seem to have diminished to unoticeable.
NOTE: Microsoft placed the configuration files for the Windows NT Advance Servers DNS server in the Registry. This configuration information can be found in the Registry key \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS.
NOTE: The configuration data for the DNS server is placed in the Registry for a reason. The Registry in the Windows NT Advanced Server is a database system that is used to store operating system configuration information. The Registry provides a reliable method of storing this configuration information in a centralized place. Windows NT guarantees the integrity of the Registry. Additionally, the Registry is backed up on the recovery diskette. If you change the DNS sever to use files, you will keep the DNS configuration information from getting backed up with the rest of the Registry.
CAUTION: Even when the Microsoft DNS server is configured to boot from the Registry, there are files in the \systemroot\SYSTEM32\DNS subdirectory that are essential for your DNS server. This directory should be backed up any time that you make changes to your DNS server.
In this example of setting up a DNS server, I show the fundamentals of setting up a DNS server. The network consists of three computers on an external network segment that are outside of the corporate firewall and four computers that reside inside of the firewall. In Figure 10.10, there are two DNS servers set up on the external network and two DNS servers set up on the internal network.
The network configuration for the DNS setup.
We will step through the setup of the four DNS servers. In this simple network, there is probably not a need to have the internal DNS servers. Name resolution on a small network could be handled by using a hosts file. The external name servers are more important as they tell people on the Internet how to get to your Web and FTP servers.
The External DNS Servers
The first steps in creating the Primary DNS server is to create a new DNS server. First make sure that TCP/IP is properly installed on the Windows NT Server, www.gasullivan.com. Also make sure the domain name and workstation name are properly configured.
To create a new DNS server, follow these steps:
1. Start the DNS Manager.
2. Right-click the Server list selection item.
3. Select New Server from the pop-menu. This brings up the New Server dialog box.
4. Add the IP address of the new DNS server. This is typically the IP address of the machine where you are running the DNS Manager.
5. Click the
OK button. This closes the DNS Manager and creates the new zone. Figure 10.11 shows the default zones that are created by the DNS manager when the new server is created.
The DNS Manager has created the default domains.
On occasion, the DNS Manager does not correctly create the new default zones for our domain. The following steps show how to create these zones and ensure they are properly set up:
NOTE: It is only necessary to create the 0.0.0.0.in-addr.arpa and 0.0.0.127.in-addr.arpa zones on DNS if the DNS manager did not create these zones in the previous step.
1. Right-click the server where the new zones are to be created.
2. Choose the Create New Zone option. This brings up the create New Zone Wizard.
3. Enter 0.0.0.0.in-addr.arpa as the zone name. Select
Next to move to the next step in the Create Zone Wizard.4. Check the Create as a Primary Domain check box. Select
Finish button to close the New Zone Wizard and create the zone.
Repeat the above steps to create the 0.0.0.127.in-addr.arpa domain.
Now that you have the basic server setup, you can go in and set up the actual zone records. This involves creating two more zone records. The first is the forward zone for the gasullivan.com domain. The second zone is the reverse name lookup specified in the in-addr.arpa domain, this is the 177.217.199.in-addr.arpa zone.
NOTE: Creating the reverse domain prior to entering any of the host data will enable you to automatically create PTR records while you are entering the A records for the host.
The first zone to create is the gasullivan.com zone. This is done from the DNS Manager with the following steps:
The next step is to create a reverse DNS zone for your domain. The reverse zone for the example is easily calculated from the IP address. The IP address for your domain is 199.217.177. The DNS reverse domain for this domain is 177.217.199.in-addr.arpa. Creating this domain is exactly the same as creating the primary domain that we just completed. Figure 10.13 shows the domain with the all of the zones completed.
CAUTION: The DNS Manger does not create the PTR record for the DNS server in the reverse name domain. Not having this record will cause your server to be set up incorrectly. There are two ways to create this record. The first is to create the PTR record in the reverse domain directly. (This is done later in this section.) The second is to delete the A record created in the forward name domain, and again add the DNS servers domain name to the forward domain. When adding the DNS servers name to the forward domain the second time, select Create Associated PTR Record in the dialog box.
The DNS Manager displays the DNS tree after the new reverse name zone has been created.
The next step is setting up your DNS servers is to create the backup secondary DNS server for the external network segment. The secondary DNS server is going to reside on ftp.gasullivan.com. The steps for this section proceed much like the creating the primary DNS server:
1. Start the DNS Manager on the backup DNS server.
2. Right-click the Server List icon and choose New
Server from the pop-up menu.3. Enter the IP address of the new Server. Select
Finish to create the new DNS Server.
Next, you will create the 0.0.0.0.in-addr.arpa and 0.0.0.127.in-addr.arpa zones in this domain. To do so, repeat the steps you performed in the section "Configuring the 0.0.0.0.in-arpa.addr and the 0.0.0.127.in-addr.arpa Zones."
Again, you need to create two new zonesñone for the forward resolution of the gasullivan.com domain, the second for the reverse name domain. This time the two domains will be secondary domains:
1. Start the DNS Manager on the backup DNS server.
2. Right-click the Server List icon and choose
New Zone from the pop-up menu. This brings up the New Zone Wizard.3. Enter the name of the zone to be createdñgasullivan.com, in this example. Click the
Next button to go to the the next page on the New Zone Wizard.4. Select
Finish to create the new zone. The DNS Manager displays the new backup server (see Figure 10.14).
The DNS Manager shows the newly created backup DNS server on www.gasullivan.com. The X over the domain indicates that the backup has not synced up with the primary DNS.
NOTE: The DNS Manager is very handy in creating backup domain servers. In the New Zone screen, a hand appears when the Secondary zone option is selected. This hand can be picked up and used to point at the zone that is to be backed up. This will create all of the appropriate zones and attach the backup DNS to the primary DNS server. This is the recommended method of establishing a backup DNS server.
CAUTION: The data will not show up on the backup DNS server until the backup DNS server pulls the data from the primary DNS server. You can force this to happen by stopping and starting the backup DNS server.
Now that you have constructed the two primary zones that construct the forward and reverse domain name spaces for the gasullivan.com domain, you can begin to add hosts and other relevant records.
Now you will have to go back to the first DNS server on www.gasullivan.com. You need to edit the properties of the gasullivan.com zone and the reverse name zone so that they will notify the backup DNS server when changes are made.
Then you will need to add the machines that are on your network so that they appear
in your domain. This is done through the DNS manager. You add hosts by right-clicking
the zone that is to be added to and selecting the New Host option.
This causes the New Host dialog box to appear (see Figure 10.15).
The New Host dialog box is used to add hosts to the domain.
The New Host dialog box contains the host name field and the IP address field. Fill in the host name for your the Firewall sever, firewall.gasullivan.com, and the IP address 199.217.177.3. Make sure that you select the Create Associated PTR Record so that you do not have to create identical records on the DNS server for the reverse name.
You have now completed the basic requirements for your network to be on the Internet with your own DNS system. Now enhance the external network to provide some additional resources by creating a mail system for your inbound e-mail. Your Firewall server provides the capability to accept the e-mail and ensure that it is safely brought into the internal network. Unfortunately, everyone has your main e-mail setup to be sent as bradr@gasullivan.com. You need to create an MX record to tell mailers to send e-mail bound for gasullivan.com to firewall.gasullivan.com. This is done by selecting the New Record option from the zone pop-up menu. The New Record option enables you to create records that are not new host records. Figure 10.16 shows the New Resource Record dialog box for the MX record so that your e-mail will be forwarded to the right machine. (See Chapter 26, "An Inside Look at Exchange Server," for more information.)
The New Record dialog box in the DNS Manger enables you to enter the data for the mail exchanger record.
You have one more item to create and that is an alias for the FTP server. You have some extra capacity on your FTP server and can use this capacity to set up a second smaller Web server. You want the users to get to this new Web sever via the URL http://www_good_deal.gasullivan.com. You do this by creating a CNAME record that points www_good_deal.gasullivan.com to ftp.gasullivan.com. The New Resource Record screen in Figure 10.17 shows how to enter the CNAME record.
The New Resource Record dialog box is used to set up the alias (CNAME) record.
The Internal DNS Servers
Now to create the Internal DNS servers. These servers are necessary to ensure that the the firewall is keeping people off of your internal network. Without the internal DNS servers, it would be necessary for your internal workstations to access the DNS servers on the external DNS servers. This opens additional paths for people to enter your network from the outside.
In a sense, creating the internal DNS domain is like creating a subdomain of the gasullivan.com domain. The new domain will also result in a new zone that has its data files on the primary DNS server busserv.int.gasullivan.com. Begin this by creating a new DNS server on the server busserv.int.gasullivan.com. This is done just like the previous example.
First a small aside would be to create a subdomain without creating the new zone. This is a very easy task. This is done by going back to www.gasullivan.com and right-clicking the gasullivan.com domain. Selecting New Domain will create a subfolder of the gasullivan.com domain. The screen below shows the new subdomains that have been created. You can now create machines in the new domains. The domain records are stored in the main zone on www.gasullivan.com. The new subdomain is called int.gasullivan.com in the DNS Manager. It is the resource records that determine the name of the new subdomain. Figure 10.18 shows the creation of the new subdomain on www.gasullivan.com.
The new int.gasullivan.com domain has been set up in the DNS Manager.
Your real objective is create a new zone. This is a lot more difficult than creating a domain or a sub domain in the same zone. There are five main steps to creating the new zone for the new subdomain:
1. Set up and test the new domain. (This is similar to creating a domain shown in "The External DNS Servers.")
2. Add the backup DNS server for your new domain. (This was also explained in "The External DNS Servers.")
3. Delegate the authority for the new subdomain.
4. Delegate the authority for the reverse subdomain.
5. Add new host and resource records for hosts on the Internal network.
The first step is to set up and test the new zone on the internal primary DNS server busserv.int.gasullivan.com. The second part is to add the secondary DNS server on devserv.int.gasullivan.com and configure it as a back up server. The third step is to delegate the authority for the new forward name domain from the DNS www.gasullivan.com to busserv.int.gasullivan.com. The fourth step is to delegate the reverse name domain, 178.217.199.in-addr.arpa, for the zone from the DNS server www.gasullivan.com to busserv.gasullivan.com. The fifth part is to add the new host and resource records for the hosts in the Internal network. The key to creating the new name server it the delegation of the authority from the upper-level DNS server www.gasullivan.com to the lower level DNS server.
Figure 10.19 contains the results of creating the new primary internal domain DNS server.
The DNS Manager main view on the primary DNS server for the internal network. All of the internal domains and resources have been created on the new DNS internal primary DNS server.
Now to delegate the forward name domain from www.gasullivan.com to busserv.int.gasullivan.com. There are two sets of records that need to be created on www.gasullivan.com for the delegation to happen. The first set of records let the int.gasullivan.com DNS servers be seen by higher order DNS servers as the name servers for the int.gasullivan.com domain. These records look like the following:
int.gasullivan.com IN NS busserv.int.gasullivan.com int.gasullivan.com IN NS devserv.int.gasullivan.com
Now the problem is that someone looking to get to the name servers do not have the name servers IP address. This is done by creating two new DNS A records to tell the IP address of the DNS servers. These records look like the following:
busserv.int.gasullivan.com 86400 IN A 199.217.177.100 devserv.int.gasullivan.com 86400 IN A 199.217.177.102
This gives the forward name resolution delegation to the new name servers.
The reverse name resolution delegation is trickier than the forward domain name resolution. You must apply to the InterNIC at www.internic.com and apply for the new IP address to get the reverse name resolution domain delegated to you. Another likely source of getting an IP address that can be delegated to you is to work with your ISP. Many ISPs will submit the paperwork for you and let you know what the IP address assigned is when the InterNIC registers you. Once you have the IP address, you simply create the reverse domain name space just like you did on the first domain. Assume that you got lucky with your InterNIC request and got the IP address 199.217.178 as your new Class C IP address. There is no reason that you should expect to get any specific IP address.
After completing the reverse name resolution domain, you will have a domain that looks like the one shown in Figure 10.20.
The DNS manager after adding the reverse domain name space for the internal network. All of the internal resources for the reverse domain have been added.
In the DNS system, there are actually two cache files. The first cache file is created by the DNS manager when it creates a new zone. The second cache file is the DNS server's internal cache of resolved names.
The cache file that is created by the DNS manager when a new zone is created is actually the root name server hints file. In early incarnations of the DNS server, this file was read into the start of the cache when the DNS server was started. The meaning of the actual cache file changed slightly and it is now necessary to have the root name server hints file also. The root name server hints file is still called a cache file. The root name server hints file enables the DNS system to jump to the top of the domain whenever it is looking for a host that is not in the DNS servers domain hierarchy or its cache. This keeps the DNS server from having to try successive operations to get to the top of the DNS domain hierarchy.
The contents of the root name hints cache file should look similar to that in Listing 10.2.
; ; Cache file: ; ; ; Cache file: ; . 3631294208 IN NS A.ROOT-SERVERS.net. A.ROOT-SERVERS.net. 1484215808 IN A 198.41.0.4 . 3631294208 IN NS H.ROOT-SERVERS.net. H.ROOT-SERVERS.net. 1484215808 IN A 128.63.2.53 . 3631294208 IN NS B.ROOT-SERVERS.net. B.ROOT-SERVERS.net. 1484215808 IN A 128.9.0.107 . 3631294208 IN NS C.ROOT-SERVERS.net. C.ROOT-SERVERS.net. 1484215808 IN A 192.33.4.12 . 3631294208 IN NS D.ROOT-SERVERS.net. D.ROOT-SERVERS.net. 1484215808 IN A 128.8.10.90 . 3631294208 IN NS E.ROOT-SERVERS.net. E.ROOT-SERVERS.net. 1484215808 IN A 192.203.230.10 . 3631294208 IN NS I.ROOT-SERVERS.net. I.ROOT-SERVERS.net. 1484215808 IN A 192.36.148.17 . 3631294208 IN NS F.ROOT-SERVERS.net. F.ROOT-SERVERS.net. 1484215808 IN A 192.5.5.241 . 3631294208 IN NS G.ROOT-SERVERS.net. G.ROOT-SERVERS.net. 1484215808 IN A 192.112.36.4
The DNS system maintains an internal cache file where it records not only the host once the name is resolved but all of the DNS servers that it talks to on its way to resolving the host name. The TTL entry in the SOA record tells the DNS server how long to keep the record in the cache.
The setup of the DNS Server shown in the section "The External DNS Server" was done using fully qualified domain names. This is done because it is confusing enough to understand the complexities of the DNS system without adding short, cryptic names that will need to be interpreted before they can be understood. When setting up a DNS server, I always try to use the fully qualified domain name for the machines. This makes the files easier for me to read. The amount of time spent creating the files is small compared to the amount of time spent maintaining the files.
The DNS system has extensive abilities that enable you to abbreviate about any name. If you receive your DNS files from someone else or use the h2n tool, you may end up with all of the names being abbreviated. Therefore it is important to note the how the abbreviation occur.
When the DNS server is processing the DNS forward name data, it "knows" that it is processing the data for gasullivan.com in the DNS files that were setup. The names of the hosts in the A records in the domain can therefore be abbreviated as the following:
www IN A 199.217.177.2
This will be expanded to:
www.gasullivan.com IN A 199.217.177.2
when it is entered into the DNS database. In this example, gasullivan.com is origin for the DNS server during the processing of this record. A second abbreviation is the at sign (@). This is the same as leaving the domain name blank. The origin is substituted for the @. The following record:
www.@ IN A 199.217.177.2
is the same as:
www.gasullivan.com IN A 199.217.177.2
There is one last substitution that is worth mentioning. The repeat last name substitution enables you to specify a domain name once and to have multiple records from that domain to the host without repeating the host name. The following section:
www.gasullivan.com IN A 199.217.177.2
IN CNAME funnyfarm.gasullivan.com
IN CNAME crazynames.gasullivan.com
is the same as:
www.gasullivan.com IN A 199.217.177.2 www.gasullivan.com IN CNAME funnyfarm.gasullivan.com www.gasullivan.com IN CNAME crazynames.gasullivan.com
A lot of the existing DNS files use these substitutions extensively.
The two primary tools for managing a DNS server on a Windows NT Advanced Server is the DNS manager tool and the nslookup command utility. The DNS manager tool enables the network manger to configure the DNS server data. The nslookup tool provides a method of in depth analysis of the DNS server data.
This tool operates a little like the File Explorer in the Windows NT operating system. A domain can be selected and expanded like a directory structure. A node in the domain tree can be configured by double-clicking the node. The main uses of the DNS Manager for creating and maintaining DNS data is described in the previous section.
The nslookup command is a query tool that can be used to query the data that is on a DNS server. The nslookup tool has an interactive and command-line mode. It is run in a command window and will be available on any Windows NT machine that has the TCP/IP stack properly installed. Table 10.2 contains the commands that are available in the nslookup tool.
| Command | Description |
| exit | Exits the interactive nslookup utility. |
| finger | Used to Finger a user on a system. The finger command is a UNIX utility that enables you to query for information on users connected to the system. For example, finger bradr@hstld.com would return information about the user bradr on the host hsltd.com. The finger command in the nslookup utility will reference the current host when no host is specified. The current host is the last host for which an IP address was resolved. |
| help | Displays a short list of the commands and their meanings. |
| ls | Lists information for the DNS domain. This command will list all of the host names and their IP address. |
| lserver | The lserver, server, and root commands are closely related. The lserver command changes the default server to the server specified. The lserver command will use the DNS sever that was specified as the valid DNS sever when nslookup was started. This is the initial DNS server. |
| root | Root is a convenience command. Its use is exactly the same as typing lserver g.root-server.net. g.root-server.net is the current root sever for the Internet. |
| server | Changes the default server used for DNS queries to the specified host. |
| set | The set command is used in conjunction with the options shown in Table 10.3. |
| view | Changes how the output of the ls command is sorted and listed. |
In addition to these commands, there are a number of options that control the behavior of the nslookup command. These options, shown in Table 10.3, can be used in the set command or passed in on the command line.
| Option | Purpose |
| set all | Lists the available set options on this nslookup system. |
| cl[ass]=IN | The class is the protocol group. Currently, the only class in wide use is the Internet class. MIT has a domain that uses the Hesiod class. |
| [no]d2 | Turns on and off the highest level of debug information. It basically provides every byte of every packet to and from the server, and provides the most debug information. |
| [no]debug | Turns on and off the low level of debugging information. It enables more information about each query to be printed. |
| [no]def[name] | Turns on and off the appending of the machine defined domain name to lookup requests. When requests are a single name, they do not contain the domain; the domain is appended to the name to form the query. |
| Do[main]=mydomain.com | Changes the default domain. (See the defname option.) |
| [no] ig[nore] | Turns on and off packet truncation errors. |
| Po[rt]=53 | Changes the default DNS name server port. Useful for debugging. A test DNS system could be established on a unique port and tested by nslookup. |
| q[uerytype]=A | Changes the query type. By default, DNS is searching for A type records, forward name resolution. If the query is an IP address, then the query type is set to PTR. This option forces the query type. |
| [no] rec[urse] | Turns on and off recursive queries of DNS severs. Nslookup requests recursive lookups by default. This enables you to query a DNS server like another DNS server sends queries. |
| Ret[ry]=4 | Sets the number of retries. After each retry, the time out value is doubled. |
| [no] sea[rch] | Turns on and off the use of the search list. On is the default. If set to on, the names in the srchlist option and the domain name are appended to the host request until a request is resolved or a list is searched. |
| Ti[meout]=5 | Time out is five seconds. The time out will double with each usage. |
| Ty[pe]=In | Changes the type of the query. Exactly the same as querytype. |
| [no] v[c] | Turns on and off the use of a virtual circuit. Default is on. If on, nslookup uses the TCP protocol for name resolution. If off, nslookup uses UDP for name resolution. |
Some things that can be accomplished are to lookup the IP address of host. This is typically done by first using the server command to change to a DNS and then looking up a hosts name.
The lserver, server, and root commands are used to set the default and initial DNS server. They are primarily used to browse or view the information in DNS servers that are foreign. One common use of the lserver and root commands is to set your initial server to a server that is correctly resolving names. This is often necessary when you are first setting up your DNS server. When you want to look at some important DNS information, the initial DNS server is used to provide reverse name resolution for the nslookup commands. If your server is not correctly configured, then requests that rely on the reverse lookup will not work. Using root or lserver allows this problem to be worked around.
WINS is Microsoft's implementation of a NetBIOS Name Server (NBNS). It is implemented as a Windows NT Server service, with an administrative utility program called the WINS Manager and appropriate client software. WINS registers the NetBIOS names used by computers, both clients and servers, as they start. When a Microsoft networking command, such as NET USE, initiates a networking operation using the Windows interface, the subsequent need to resolve a NetBIOS name to complete the command will be handled by WINS. TCP/IP host names can also be resolved by WINS, after the local HOSTS file has been checked, and the DNS (if any) has been consulted.
The primary advantage of WINS is that it dramatically reduces the amount of broadcast traffic on the network. Because name resolution with WINS is handled by direct communication between WINS servers and clients, broadcast name registration requests and name query requests are therefore minimized. You do not need to configure all clients to use WINSñyou can operate a mixed environment. WINS resolves names from clients across routers and can therefore support multiple subnets. If a WINS server is not available, the design of the system still enables clients to use broadcasts so that they are not disabled when the WINS servers are down. WINS servers can replicate the names in their databases to other WINS servers so that a single, dynamic names database is represented and managed across the enterprise network.
To use WINS, you must configure a WINS server and start the service, whose formal name is listed in the Services dialog box simply as Windows Internet Name Service. The steps involved in configuring a WINS server are covered in the next section.
Once you have set up one or more WINS servers and WINS enabled clients, the process of registering and resolving names involves a number of distinct processes that are carried out in a natural order.
Prior to configuring a WINS server, it is helpful to understand the configuration of the client and how WINS name resolution happens. The steps involved in WINS name registration are as follows:
1. A WINS client is configured with the address of the primary and an optional secondary WINS server. This can be directly configured on the client, or received with an IP address as one of the optional DHCP parameters passed from a DHCP server. As the client starts, it sends its NetBIOS name directly to the WINS server in a name registration request.
2. If the WINS server is available and the name is not already registered to another client, the registration is successful, and a message is returned to the client with a positive registration and the amount of time for which the name is registered, known as the Time to Live (TTL).
3. If a duplicate name is found, the server sends a name challenge to the currently registered client. If the client responds and affirms that it is using the name, the new registration is denied by sending a message to the requesting client. If the currently registered client does not respond to three queries, the name is released and registered to the new client.
4. If the primary WINS server cannot be found after three attempts by the client using ARP, an attempt will be made to find the secondary WINS server (if the client has been configured for a secondary WINS server). If it also cannot be found with three ARP requests, the client resorts to a standard b-node broadcast to register its name with the local subnet.
A WINS client, by default, will use the h-node (hybrid) implementation of NetBIOS over TCP/IP. The steps involved in WINS name resolution are as follows:
1. When a command is entered or implicitly specified by actions in the Windows interface, a name resolution is required. The NetBIOS name cache is checked first to see if the NetBIOS name mapping to an IP address is available.
2. If the mapping is not in the NetBIOS name cache, a name resolution query is sent directly to the primary WINS server. If no response is returned, the request is sent three times.
3. If the primary WINS server does not respond, the secondary WINS server (if configured) is tried as many as three times. If either the primary or secondary WINS server receives the request, it looks up the name in its database and sends the IP address back to the client, or replies with a Requested name does not exist message if it is not listed in the database.
4. If the name cannot be resolved by a WINS server, either because the server is unavailable or because the name is not in the database, a b-node name resolution query is broadcast as many as three times.
5. If the name is still not resolved, the LMHOSTS file (if configured) and the HOSTS file are searched.
6. If the name is not in either LMHOSTS or HOSTS, the DNS (if configured) is consulted.
NOTE: An entirely different order is used to resolve host names used in traditional TCP/IP utilities. See "Domain Name System Name Resolution" earlier in this chapter.
A single WINS server can resolve names for an entire WAN because the requests are sent as directed datagrams and can be routed. A secondary WINS server provides redundancy and fault tolerance. Additional WINS servers can be provided based on the number of client requests received and performance considerations in large network environments. A rough rule of thumb is that a typical WINS server can handle as many as 1,200 name registrations and 700 name queries per minute. A pair of WINS servers should be able to handle as many as 8,000 WINS clients under typical network conditions. If you implement servers with two or more processors, a pair of WINS servers should handle more than 12,000 clients.
WINS servers do not need to be domain controllers as well. They should be configured with a static IP address, subnet mask, default gateway address, and other TCP/IP options. The use of DHCP assigned options is possible, but not recommended.
Entering Basic Configuration Information
To configure the basic operation of your WINS server, follow these steps:
Entering Static Mappings for Non-WINS Clients
If you have non-WINS clients on your network, you may want to enter static mappings for these computers, especially if they are involved in resource sharing as is possible with Windows for Workgroups, Windows 95, and Windows NT Workstation. If another computer attempts to use a shared resource on one of these devices, the WINS server can still provide name resolution, even though the original (non-WINS) computer did not register its name. By entering a static mapping, the non-WINS client appears in the WINS database anyway. To enter a static mapping, follow these steps:
The Add Static Mappings dialog box is used to map the NetBIOS name of a non-WINS client to an IP address for inclusion in the WINS database.
Configuring WINS Clients
WINS clients are configured by simply entering the address of a primary WINS server, and optionally a secondary WINS server, into the client's configuration. This can be done manually, using the Network icon on the Control Panel (run Network Setup for Windows for Workgroups clients), or you can automatically configure WINS addresses using DHCP. If you are using DHCP, you can manually configure individual clients, and those settings will take precedence over the DHCP settings. If you use DHCP to configure WINS addresses, you must also configure clients using option 046 WINS/NBT Node type or it will not work. A message box prompts you to do so if you forget. Set this option to 0x8 (h-node or hybrid).
Viewing WINS Name Mappings
To view the NetBIOS name/IP address mappings currently registered on a WINS server, follow these steps:
Configuring WINS Push/Pull Partners
WINS servers can replicate their mappings database to other WINS servers. When you configure a WINS server to replicate with another server, you can configure the server as a push partner with the other server, a pull partner, or both. Designating a WINS server as a push partner causes the server to send messages to its partners when its WINS database has received a specified number of changes. When the partners respond, only the changes to the database will be replicated to the other servers.
Configuring a server as a pull partner gives you the option to specify a time when requests should be made from its partner. This is the recommended way to provide replication of a WINS database over slow links because you can schedule the transfer for off-peak time periods. For example, two servers on either side of a slow link can each be configured to pull from the other server at different times during the night. A server can be configured to act in both roles with one or more other WINS servers.
To configure a push or pull partner, follow these steps:
Maintaining the WINS Database
The JETPACK utility used to compact the DHCP database can be used to compact the WINS database as well. It is recommended that you compact the database if it grows to a size of more than 30M. This maintenance on the WINS database is required for the same reasons you must maintain the DHCP database. See the section "Maintaining the DHCP Database" earlier in this chapter for more information. Also, see "Restoring the WINS Database" in the Windows NT Server Networking Guide for information on restoring a corrupted WINS database. To use JETPACK to compact the WINS database, follow these steps:
net stop wins
copy wins.mdb wins.bak
jetpack wins.mdb temp.mdb
del wins.mdb
ren temp.mdb wins.mdb
net start wins
The primary location for the DNS system and the WINS system to integrate is on the DNS server. The Microsoft DNS server that is shipped with Windows NT can be configured to utilize WINS resolution. If the DNS server is configured to use WINS resolution, it will first look try to resolve the host name via the normal DNS name resolution scheme. If the host name is not resolved via the DNS resolution, the DNS server will issue a WINS request. This WINS request is the same as any other client attempting a WINS lookup. If the WINS host name is found, the DNS server will respond to the DNS name query as though the name was found in the DNS servers own data files.
The second location for DNS and WINS integration is on a network client. A Windows NT or Windows 95 network client can be configured for WINS and DNS resolution. This allows the most flexibility in establishing your network. When the client is configured this way, it first looks at the host name that is being resolved. Standard NetBIOS names are always less than 15 characters and do not contain any special characters including the period. If the host name is a standard NetBIOS name, the resolver first attempts a NetBIOS resolution of the host name. This would involve querying the WINS server. If the host is not found this way, the resolver will query the DNS system.
In this chapter, you learned how name resolution takes place in the Windows NT system, and about the architecture Domain Name System. You also learned how to setup up TCP/IP domains using the DNS Manager and DNS server. You created a subdomains and learned how to delegate domain authority to the subdomain. You also discovered the tools used to troubleshoot a DNS server.
You also learned about the WINS system and how WINS provides name resolution for the NetBIOS networking architecture
For more information on these and related topics, see the following chapters:
© Copyright, Macmillan Computer Publishing. All rights reserved.