DOMAIN NAME SYSTEM

Although programs theoretically could refer to hosts, mailboxs and other resources by their network (e.g., IP) addresses, these addresses are hard for people to remember. Also, sending e-mail to tana@128.111.24.41 means that if Tana’s ISP or organization moves the mail server to a different machine with a different IP address, her e-mail address has to change.Consequently, ASCII names were introduced to decouple machine name from machine addresses. In this way, Tana’s address might be something like that tana@art.ucsb.edu.Nevertheless, the network itself understands only numerical address-es, so some mechanism is required to convert the ASCII strings to network addresses. In the following sections we will study how this mapping is accomplished in the internet. 

Way back in the ARPANET, there was simply a file, hosts.txt that listed all the hosts & their IP addresses. Every night, all the hosts would fetch it from the site at which it was maintained. For a network of a few hundred large timesharing machines, this approach worked reasonably well.

However, when thousands of minicomputer & PCs were connected to the net, everyone realized that this approach could not continue to work forever. For one thing, the size of the file would become too large. However, even more important, host name conflicts would occur constantly unless names were centrally managed, something unthinkable in a huge international network due to the load and latency. To solve these problems, DNS (the Domain Name System) was invented.

The essence of DNS is the invention of a hierarchical, domain-based naming scheme and a distributed database system for implementing this naming scheme. It is primarily used for mapping host names and e-mail destinations to IP addresses but can also be used for other purposes. DNS is defined in RFCs 1034 and 1035.

Domain Name System

The Domain Name System (DNS) is a set of protocols and services on a TCP/IP network that allows users of the network to utilize hierarchical user-friendly names when looking for other hosts (that is, computers) instead of having to remember and use their IP addresses. This system is used extensively on the Internet and in many private enterprises today. If you've used a Web browser, Telnet application, FTP utility, or other similar TCP/IP utilities on the Internet, then you have probably used a DNS server.

The DNS protocol's best-known function is mapping user-friendly names to IP addresses. For example, suppose the FTP site at Microsoft had an IP address of 157.55.100.1. Most people would reach this computer by specifying FTP.microsoft.com and not the less "friendly" IP address. Besides being easier to remember, the name is more reliable. The numeric address could change for any number of reasons, but the name can always be used.

Before the implementation of DNS, the use of user-friendly computer names was done through the use of HOSTS files, which contained a list of names and associated IP addresses. On the Internet, this file was centrally administered and each location would periodically download a new copy. As the number of machines on the Internet grew, this became an unmanageable solution. The need for something better arose. This better solution became DNS.

According to Dr. Paul Mockapetris, principle designer of DNS, the original design goal for DNS was to replace the cumbersome singularly administered HOSTS file with a lightweight distributed database that would allow for a hierarchical name space, distribution of administration, extensible data types, virtually unlimited database size, and reasonable performance.

DNS maps to level 7 in the OSI model and can use either UDP or TCP as the underlying protocol. Resolvers send UDP queries to servers first for increased performance and only resort to TCP if truncation of the returned data occurs.

The most popular implementation of the DNS protocol "BIND" was originally developed at Berkeley for the 4.3 BSD UNIX operating system. The name "BIND" stands for Berkeley Internet Name Domain. The primary specifications for DNS are defined in Requests for Comments (RFCs) 974, 1034, and 1035.

Domain name space

A Domain Name System is composed of a distributed database of names. The names in the DNS database establish a logical tree structure called the domain name space. Each node or domain in the domain name space is named and can contain sub domains. Domains and sub domains are grouped into zones to allow for distributed administration of the name space (zones will be discussed later in this section). The domain name identifies the domain's position in the logical DNS hierarchy in relation to its parent domain by separating each branch of the tree with a period ".". The following figure shows a few of the top level domains, where the Microsoft domain fits, and a host called "rhino" within the "microsoft.com" domain. If someone wanted to contact that host, they would use the Fully Qualified Domain Name (FQDN) rhino.microsoft.com.

DNS Servers and the Internet

The root of the DNS database on the Internet is managed by the Internet Network Information Center, located at www.internic.net/. The top-level domains were assigned organizationally and by country. These domain names follow the International Standard 3166. Two-letter and three-letter abbreviations are used for countries, and various abbreviations are reserved for use by organizations, as shown in the following examples.

DNS Domain Name	Type of Organization
Com	Commercial (for example, microsoft.com for Microsoft Corporation)
Edu	Educational (for example, mit.edu for Massachusetts Institute of Technology)
Gov	Government (for example, whitehouse.gov for the White House in Washington D.C.)
Int	International organizations (for example, nato.int for NATO)
Mil	Military operations (for example, army.mil for the Army)
Net	Networking organizations (for example, nsf.net for NSFNET)
Org	Noncommercial organizations (for example, fidonet.org for FidoNet)

Domains

Each node in the tree of a DNS database, along with all the nodes below it, is called a domain. Domains can contain both hosts (computers) and other domains (sub domains). For example, the Microsoft domain microsoft.com could contain both computers such as FTP.microsoft.com and sub domains such as dev.microsoft.com, which could contain hosts such as ntserver.dev.microsoft.com.

Note   In general, Domain names and Host names have restrictions in their naming that only allow the use of characters "a-z," "A-Z," "0-9," and "-" (dash or minus sign). The use of characters such as the "/," ".," and "_" (slash, period, and underscore) are not allowed.

Zones

A zone is some portion of the DNS namespace whose database records exist and are managed in a particular zone file. A single DNS server might be configured to manage one or multiple zone files. Each zone is anchored at a specific domain node—referred to as the zone's "root domain." Zone files do not necessarily contain the complete tree (that is, all sub domains) under the zone's root domain. For a comparison of domains and zones, look at the figure that follows. In this example, microsoft.com is a domain but the entire domain is not controlled by one zone file. Part of the domain is actually broken off into a separate zone file for dev.microsoft.com. Breaking up domains across multiple zone files might be needed for distributing management of the domain to different groups or possibly for efficiencies in data replication (that is, zone transfers, which will be discussed later).

Note   It is very important that you understand the difference between a zone and a domain. A zone is a physical file, composed of resource records, that defines a group of domains. A domain is a node in the DNS namespace and all sub domains below it.

Name Servers

DNS servers store information about the domain name space and are referred to as name servers. Name servers generally have one or more zones for which they are responsible. The name server is then said to have authority for those zones.

When you configure a DNS name server (as we will soon see with the "NS" record), you tell it which DNS name servers are in the same domain.

Primary, secondary, and master name servers

A primary name server is a name server that gets the data for its zones from local files. Changes to a zone, such as adding domains or hosts, are done at the Primary Name Server. A secondary name server gets the data for its zones from another name server across the network which is authoritative for that zone. The processes of obtaining this zone information (that is the database file) across the network are referred to as zone transfer.

There are three reasons to have secondary servers within an enterprise:

• Redundancy

You need at least two DNS name servers serving each zone, a primary name server and at least one secondary name server for redundancy. Like any fault-tolerant system, the machines should be as independent as possible (that is, different networks and so forth).

• Remote locations

You should also have secondary servers (or other primary servers for sub domains) in remote locations that have a large number of clients. You would not want these clients to have to communicate across slow links for name resolution.

• Reduce load on the primary

You also need secondary servers to reduce the load on the primary server.

Since information for each zone is stored in separate files, this primary or secondary designation is defined at a zone level. In other words, a particular name server may be a primary name server for certain zones and a secondary name server for other zones.

When defining a zone on a name server as a secondary, you must designate a name server from which to obtain the zone information. The source of zone information for a secondary name server in a DNS hierarchy is referred to as a master name server. A master name server can be either a primary or secondary name server for the requested zone. When a secondary name server starts up, it contacts its master name server and initiates a zone transfer with that server.

Note   Use secondary servers as master servers when the primary is overloaded or when there is a more efficient network path between "secondary to secondary" versus "secondary to primary."

Forwarders and slaves

When a DNS name server receives a DNS request, it attempts to locate the requested information within its own zone files. If this fails because the server is not authoritative for the domain requested, it must communicate with other DNS name servers to resolve the request. Since, on a globally connected network, a DNS resolution request outside a local zone typically requires interaction with DNS name servers outside of the company on the public Internet, you may want to selectively enable specific DNS name servers in your company to do this wide-area communication.

To address this issue, DNS allows for the concept of forwarders. Specific DNS name servers are selected to be forwarders, and only forwarders are allowed to carry out the wide-area communications across the Internet. All other DNS name servers within the company are configured to use forwarders and are configured with the IP addresses of the DNS name servers designated as forwarders. This configuration is done on a per-server basis, not a per-zone basis!

When a server configured to use forwarders receives a DNS request that it is unable to resolve through its own zone files, it passes the request to one of the designated forwarders. The forwarder then carries out whatever communication is necessary to resolve the request and returns the results to the requesting server, which, in turn, returns the results to the original requester. If the forwarder is unable to resolve the query, the DNS server attempts to resolve the query on its own as normal.

Slaves are DNS servers that have been configured to use forwarders and to return a failure message if the forwarder is unable to resolve the request. Slaves make no attempt to contact other name servers if the forwarder is unable to satisfy the request.

Name Resolution

There are three types of queries that a client can make to a DNS server, recursive, iterative, and inverse. While discussing name resolution, keep in mind that a DNS server can be a client to another DNS server.

Recursive queries

In a recursive query, the queried name server is petitioned to respond with the requested data or with an error stating that data of the requested type or the domain name specified doesn't exist. The name server cannot just refer the querier to a different name server.

This type of query is typically done by a DNS client (a resolver) to a DNS server. Also, if a DNS server is configured to use a forwarder, the request from this DNS server to its forwarder will be a recursive query.

 

Iterative queries

In an iterative query, the queried name server gives the best answer it currently has back to the querier. This type of query is typically done by a DNS server to other DNS servers after it has received a recursive query from a resolver.

The following figure shows an example of both types of queries. Query 1/8 is a recursive query from a client resolver to its DNS server while 2/3, 4/5, and 6/7 are iterative queries from the DNS server to other DNS servers.

Getting the Host name given the IP address

What if a resolver has the IP address and would like to know the Host name for a particular machine? Instead of supplying a name and asking for an IP address, the client needs to provide the IP address and ask for the name. Since there is no direct correlation in the DNS name space between the domain names and the associated IP addresses they contain, only a thorough search of all domains could guarantee a correct answer.

To alleviate this problem, a special domain, "in-addr.arpa.", was created in the DNS name space. Nodes in the in-addr.arpa domain are named after the numbers in the dotted-octet representation of IP addresses. But since IP addresses get more specific from left to right and domain names get less specific from left to right, the order of IP address octets must be reversed when building the in-addr.arpa tree. With this arrangement, administration of lower limbs of the DNS in-addr.arpa tree can be given to companies as they are assigned their class A, B, or C subnet address.

Once the domain tree is built into the DNS database, a special pointer record is added to associate the IP addresses to the corresponding host names. In other words, to find a host name for the IP address 157.55.200.2, the resolver would query the DNS server for a pointer record for 2.200.55.157.in-addr.arpa. If this IP address was outside the local domain, the DNS server would start at the root and sequentially resolve the domain nodes until it reached 200.55.157.in-addr.arpa, which should contain the resource PTR record for 2 (that is, 157.55.200.2).

The DNS Files

Most DNS systems must be configured by editing text files. With Microsoft DNS, as with all Microsoft Windows®-based products, there is a user-friendly interface. The new administration interface makes it much easier to configure both local and remote Microsoft DNS servers. The DNS administrative tool configures the RFC-compatible text files for you.

Even though the graphical user interface gives you the ability to modify the DNS files without an editor, you should know the makeup of the DNS system configuration files. In RFC-compliant DNS systems, there are several files which define the DNS system configuration and database. These files include the database, cache, reverse lookup, and

127 reverse lookup files. These files also exist in the Windows NT 4.0 DNS and are RFC-compliant. These files are explained in detail in this section.

The Database File

A database file or "zone file" is the file that contains the resource records for that part of the domain for which the zone is responsible. Some of the common resource records are given below. Windows NT 4.0 supplies a file called "place.DNS” as a template to work with. This file should be edited and renamed before you use it on a production DNS server. It is generally a good idea to name this file the same as the zone it represents. This is the file that will be replicated between masters and secondaries.

The Start of Authority

The first record in any database file is the SOA Record:

IN SOA <source host> <contact e-mail> <ser. no.> <refresh time> <retry time> <expiration time> <TTL>

• source host—the host on which this file is maintained.
• contact e-mail—the Internet e-mail address for the person responsible for this domain's database file.

Note   Instead of writing the "@" symbol in the e-mail name, as would normally be done, the "@" must be replaced with a "." when placed in the zone files. In other words, the e-mail address glennwo@microsoft.com would be represented as glennwo.microsoft.com in the zone file.

• serial number—the "version number" of this database file. This number should increase each time the database file is changed.
• refresh time—the elapsed time (in seconds) that a secondary server will wait between checks to its master server to see if the database file has changed and a zone transfer should be requested.
• retry time—the elapsed time (in seconds) that a secondary server will wait before retrying a failed zone transfer.
• expiration time—the elapsed time (in seconds) that a secondary server will keep trying to download a zone. After this time limit expires, the old zone information will be discarded.

In order for a resource record to span a line in a database file, parentheses must enclose the line breaks.

Note   In a zone file, the "@" symbol represents the root domain of the zone (microsoft.com in the following examples). The "IN" in the following records is the class of data. It stands for Internet. Other classes exist, but none of them are currently in widespread use.

Caution   Any domain name in the database file which is not terminated with a period "." will have the root domain appended to the end.

Example:

@ IN SOA nameserver1.microsoft.com. glennwo.microsoft.com. (

1 ; serial number

10800 ; refresh [3 hours]

3600 ; retry [1hour]

604800 ; expire [7 days]

86400 ) ; time to live [1 day]

Setting the server's refresh interval is a balance between data consistency (accuracy of your data) and your network's load.

The name server record

The name server record lists the name servers for this domain, allowing other name servers to look up names in your domain.

<domain> IN NS <name server host >

Example:

@ IN NS nameserver2.microsoft.com.

@ IN NS nameserver3.microsoft.com.

The e-mail exchange record

This record tells us what host processes e-mail for this domain. If multiple e-mail exchange records exist, the resolver will attempt to contact the e-mail servers in order of preference from lowest value (highest priority) to highest value (lowest priority). By using the example records that follow, e-mail addressed to scottsu@microsoft.com is delivered to scottsu@mailserver0.microsoft.com first, if possible, then to scottsu@mailserver1.microsoft.com if mailserver0 is unavailable.

<domain> IN MX <preference> <mail server host >

Example:

@ IN MX 1 mailserver0

@ IN MX 2 mailserver1

The host record

A host record is used to statically associate host's names to IP addresses within a zone. It should contain entries for all hosts which require static mappings including workstations, name servers, e-mail servers, and so on. These are the records which make up most of the database file when static records are used.

<host name> IN A <ip address of host>

Example:

rhino IN A 157.55.200.143

nameserver2 IN A 157.55.200.2

mailserver1 IN A 157.55.200.51

The local host record

A local host record allows lookups for "localhost.microsoft.com." to return 127.0.0.1.

localhost IN A 127.0.0.1

The CNAME record

These records are sometimes called "aliases" but are technically referred to as "Canonical Name" (CNAME) entries. These records allow you to use more than one name to point to a single host.

Using canonical names makes it easy to do such things as host both an FTP server and a Web server on the same machine.

<host alias name> IN CNAME <host name>

Example:

Assume that www.microsoft.com and FTP.microsoft.com are on the same machine. If this is the case, then you might have the following entries in your zone file:

FileServer1 IN A 157.55.200.41

FTP CNAME FileServer1

www CNAME FileServer1

If you ever intend to move the FTP server service away from the Web service, then all you have to do is change the CNAME in the DNS server for FTP and add an address record for the new server. For example:

FTP CNAME FileServer2

FileServer2 IN A 157.55.200.42

The Reverse Lookup File

This is a database file that is used for reverse lookups, in particular IP DNS zones of host names when supplied with the IP numbers. This allows a resolver to provide an IP address and request a matching host name. This file contains SOA and name server records similar to other DNS database zone files. It also contains pointer records.

This DNS reverse lookup capability is important because some applications provide the capabilities to implement security based on the connecting host names. For instance, if a client tries to link to a Network File System (NFS) volume with this security arrangement, the NFS server would contact the DNS server and do a reverse-name lookup on the client's IP address. If the host name returned by the DNS server is not in the access list for the NFS volume or if the host name was not found by DNS, then the NFS mount request would be denied. This reverse lookup capability is also often used for troubleshooting reasons.

Here are two example zones for different IP class networks.

Example class C zone:

100.200.192.in-addr.arpa

Example class B zone:

55.157.in-addr.arpa

The pointer record

Pointer records provide a static mapping of IP addresses to host names within a reverse lookup zone. IP numbers are written in backward order and "in-addr.arpa." is appended to the end to create this pointer record. As an example, looking up the name for "157.55.200.51" requires a PTR query for the name "51.200.55.157.in-addr.arpa."

<Ip reverse domain name> IN PTR <host name>

Example:

51.200.55.157.in-addr.arpa. IN PTR mailserver1.microsoft.com.

The Arpa-127.rev File

This is a database file for the 127.in-addr.arpa. domain. This domain is used for reverse-lookups of IP numbers in the 127 network, such as "localhost." The only things in this file that change are the SOA and NS records.

The BIND Boot File

Although the boot file is not actually defined in the RFCs and is not needed in order to be RFC-compliant, it is described here for completeness. This file is actually a part of the BIND-specific implementation of DNS. Microsoft DNS can be configured to use a boot file if you are going to administer DNS through changes to the text files instead of using the DNS Administrator UI.

This file controls the startup behavior of the DNS server. Commands must start at the beginning of a line and no spaces may precede commands. Recognized commands are: "directory, cache, primary, and secondary." The syntax for this file is as follows:

Directory command

Specifies a directory where other files referred to in the boot file can be found.

directory <directory> 

Example:

directory c:\winnts\system32\ DNS

Cache command

Specifies a file used to help the DNS service contact name servers for the root domain. This command and the file it refers to must be present. A cache file suitable for use on the Internet is provided with Windows NT 4.0.

cache. <filename> 

Example:

cache . cache

Primary command

Specifies a domain for which this name server is authoritative and a database file that contains the resource records for that domain (that is, zone file). Multiple primary command records could exist in the boot file.

primary <domain> <filename> 

Example:

primary microsoft.com microsoft.DNS

primary dev.microsoft.com dev.DNS

Secondary command

Specifies a domain for which this name server is authoritative and a list of master server IP addresses from which to attempt downloading the zone information, rather than reading it from a file. It also defines the name of the local file for caching this zone. Multiple secondary command records could exist in the boot file.

secondary <domain> <hostlist> <local filename>

Example:

secondary test.microsoft.com 157.55.200.100 test.DNS

Forwarders command

Specifies another server that is willing to try resolving recursive queries on behalf of the system.

forwarders <hostlist>

Example:

forwarders 157.55.200.100 157.55.200.101

Slave command

Specifies that the use of forwarders is the only possible way to resolve queries. Can only follow a forwarders command.

Slave

Example:

forwarders 157.55.200.100 157.55.200.101

slave

Introduction to Microsoft DNS

Some people might ask "what is the Microsoft DNS and why should I use it?" Well, let's start out by telling you what DNS is not. First, the Microsoft DNS server is not a port of the Berkley BIND code (which is currently at revision 10.4 as of the writing of this paper). We made a conscious decision to not port the BIND code, but rather to write our own code that was fully RFC-compliant and compatible with BIND. We made this decision because we wanted to be able to easily add performance enhancements to the product. The Microsoft DNS server is also not the code that was shipped in the Windows NT Resource Kit. If you used that utility, you probably noticed that it had problems with zone transfers. The DNS server service in Windows NT 4.0 is a complete rewrite and is not just a bug-fixed version. Rest assured that in the DNS included with Windows NT 4.0, RFC compliance has been thoroughly tested and it all works as defined, including zone transfers.

Now let's talk about what the Microsoft DNS server is. First and foremost, the DNS server in Windows NT 4.0 is an RFC-compliant implementation of DNS. If there is a required feature in an RFC that is not found in the Microsoft DNS product, this would be considered a bug.

Because Microsoft DNS is an RFC-compliant DNS server, it creates and uses standard DNS zone files and supports all standard resource record types. It is interoperable with other DNS servers and includes the de facto standard DNS diagnostic utility—NSLOOKUP. Microsoft DNS also has many features above and beyond those specified in the RFCs, such as dynamic update through tight integration with WINS and easy administration through the graphical administration utility called DNS Manager.

Note   Microsoft DNS supports RFCs 1033, 1034, 1035, 1101, 1123, 1183, and 1536.

With the Microsoft implementation of DNS, network administers can turn off the legacy DNS systems in favor of a Microsoft Windows NT implementation. They can remove any static entries for Microsoft-based clients in legacy DNS server zone files in favor of the dynamic WINS/ DNS integration. For example, if a non–Microsoft-based client wants to get to a Web page on an HTTP server that is DHCP/WINS-enabled, the client can query the DNS server, the DNS server can query WINS, and the name can be resolved and returned to the client. Previous to the WINS integration, there was no way to reliably resolve the name because of the dynamic IP addressing.

The following figure shows how a non–Microsoft-based client might find a machine named "scottsu1.microsoft.com," running Microsoft Internet Information Server (IIS), which has a dynamically allocated address from DHCP and has registered with WINS.

At this point, a default installation of Microsoft DNS server service will be installed on the Windows NT-based server. This installation will install files in your \<SystemRoot>\system32\ DNS directory as shown. At this point, you will be prompted to restart your server.

Configuring DNS Domains and Zones

To configure the DNS server, run the DNS Manager under the Administrative Tools. Initially, the DNS Manager will not have any servers in its list. To add the local server, pull down the DNS menu and click New Server. Fill in the name of your local server and click OK. The server will then show up in the Server List. Double-click the server to see the server statistics and zones that have been defined.

Since the DNS server initially has no information about your specific network, the DNS server service installs as a caching-only name server for the Internet. This means that DNS only contains information on the Internet root servers. For most DNS configurations, additional information must be supplied to obtain the desired operation.

The first step in configuring the DNS server is to determine the hierarchy for your DNS domains and zones. Design considerations for a DNS hierarchy are discussed in the next section of this paper. Once the domain and zone information have been determined, the information must be entered into the DNS configuration using the DNS Manager.

Since DNS information is grouped and controlled by zones, a zone must first be created. To do this, click the server name with the alternate mouse button and then click New Zone.

Note   If you double-click the CACHE zone, you can see all of the hosts that the DNS server has statically defined and dynamically cached due to a previous query. The CACHE will also show all of the WINS entries that have been resolved and have not elapsed their WINS-specific Cache Time-out Value.

At this point, a dialog is presented that asks if the zone you are creating is a primary zone (information stored locally) or a secondary zone (information obtained from a master server by a zone transfer). If it is a primary zone, no additional information is needed at this step. If it is a secondary zone, you must also enter the zone and master server names in this screen.

The next step is to fill in the zone name and zone file information for the local server. This will determine how the zone shows up in the DNS Manager and what file name it is stored under. If this is a secondary zone, this zone name should match the master server zone name. If this zone file already exists in the DNS directory, DNS will import these records automatically when this zone is created.

If this is a secondary zone, you would then be asked to enter the IP address of the master name servers (the name servers with which you will do zone transfers for this zone).

Once all this information is entered, the zone will be added to the DNS hierarchy. If you have additional zones that need to be added, follow the same procedure for each zone. Once all zones have been added to the server, you should then add any DNS subdomains under the zones that your hierarchy might contain. To do this, click the appropriate zone with the alternate mouse button and click New Domain.

Enter the name of the new sub domain in the dialog box and click OK. If multiple levels of sub domains are needed, create each successive sub domain by clicking the immediate parent with the alternate mouse button, clicking New Domain, and entering the name of the new sub domain.

This process can also be used for adding new host or resource records at any domain location within the DNS hierarchy.

Integration with WINS Lookup

The WINS record

Although DNS may seem similar to Windows Internet Naming Service (WINS), there are a couple of major differences. DNS is a static database of IP addresses for name-to-address mapping, which must be manually updated by an administrator. Also, DNS has the concept of hierarchy which allows the administration and replication of the database to be broken up into "zones." WINS, on the other hand, allows machines to dynamically register their name-to-address mappings and therefore requires far less administration. WINS is also a flat name space, without the concept of hierarchy, and requires each WINS server to maintain a complete database of entries through replication.

The Microsoft DNS server works hand in hand with the Microsoft WINS server and provides a great deal of interoperability. To provide this interoperability, a new record was defined as part of the zone database file. The WINS record is specific to Windows NT and may be attached only to the zone root domain. The presence of a WINS record instructs the name server to use WINS to look up any requests for hosts in the zone root that do not have static addresses in the IP database. This functionality is particularly useful for UNIX-based clients that need to contact DHCP/WINS enabled clients through IP.

<domain> IN WINS <IP address of WINS server>

Example:

@ IN WINS 157.55.200.81

Enabling WINS lookup

WINS Lookup can be enabled for a zone through the DNS Manager instead of requiring manual entry of the WINS record. This is accomplished by clicking the zone with the alternate mouse button and clicking properties. Then click the WINS Lookup tab. Check the Use WINS Resolution checkbox and fill in the IP address of the WINS Server that you wish to use and click Add. Multiple WINS server addresses can be entered.

You probably only need to use WINS lookup if you have non–Microsoft-based TCP/IP clients that need to resolve Host Name to IP addresses, for example, if your organization needs to be able to use FTP or HTTP on servers running Windows NT from non–Microsoft-based (that is, UNIX) clients.

Caution   If you have a zone configured to do WINS lookup, then all DNS servers that are authoritative for that zone need to be able to do WINS lookup or you will have intermittent behavior.

In order to easily add the Microsoft WINS/ DNS lookup to a legacy DNS architecture, simply create a new DNS subdomain in your enterprise and have the Windows NT-based primary and secondary servers enabled to do WINS lookup in this domain. For example, in the following figure there are an acme.com domain and an Msdomain.acme.com domain. All of the Microsoft-based clients register with the WINS server in the Msdomain.acme.com domain.

The Resolver

Setup

The exact procedure needed to setup individual client machines will vary depending on the operating system and TCP/IP software being used. The specific procedures for the clients will not be covered in this paper. However, the general setup parameters required and their use will be discussed.

The Host Name

The host name for the client can be any combination of the letters A through Z, the numerals 0 through 9, and the hyphen (-). By default, in Microsoft networking environments, this value is the NetBIOS computer name, but you can assign a different host name without affecting the NetBIOS computer operation, if desired. If WINS Lookup is used with Microsoft DNS, this value should match your NetBIOS computer name for consistency.

Note   Some characters that can be used in NetBIOS names, especially the underscore and period, cannot be used in DNS host names.

The Domain Name

The domain name is used with the host name to create a fully qualified domain name (FQDN) for the computer. The FQDN is the host name followed by a period (.), followed by the domain name. For example, this could be wkstn1.microsoft.com, where wkstn1 is the host name and microsoft.com is the domain name. During DNS queries, the fully qualified domain name is used.

The DNS Servers

Many operating systems allow you to specify several DNS servers in their configurations. When this capability is provided, a priority order is also provided so that a preferred server can be identified. For a given DNS query, the system attempts to get DNS information from the first IP address in the list. If no response is received, it goes to the next server in the list, and so on.

Note   In most systems, if you have two DNS servers listed, the system only checks the second server if no response is received from the first server. If the system attempts to check a host name with the first server and receives a message that the host name is not recognized, the system does not try the second DNS server.

The Domain Suffix Search Order

In some systems, a Domain Suffix Search Order capability is provided. The Domain Suffix Search Order specifies the DNS domain suffixes to be appended to the host names during name resolution. When attempting to resolve a fully qualified domain name (FQDN) from a host-only name, the system will first append the local domain name. If this is not successful, the system will use the Domain Suffix list to create additional FQDNS in the order listed and query DNS servers for each.

An example client configuration from a machine running Windows NT 4.0 is illustrated below.

Name Resolution

Windows NT TCP/IP 3.5x systems may use several methods for locating NetBIOS resources:

• NetBIOS name cache
• NetBIOS name server
• IP subnet broadcasts
• Static LMHOSTS files
• Static HOSTS files
• DNS servers

Earlier implementations used only cache, broadcasts, and LMHOSTS files; however, in version 3.5, a NetBIOS name server (WINS) was added and modifications were made to allow NetBIOS applications to query the DNS name space by appending configurable domain suffixes to a NetBIOS name. However, the DNS name resolution was always done last, after the NetBIOS cache, LMHOSTS file (if enabled), WINS (if enabled), and broadcast were tried. With Windows NT 4.0, the DNS name resolution will be tried first if the name is greater than 15 characters (maximum length of a NetBIOS computer name on Windows NT). The Host name can now be used in any of the Windows NT utilities (such as Microsoft Explorer, seen below) that previously supported NetBIOS computer names. This functionality will also be made available in the Windows 95 operating system in the future.

Note   Remember that the \%SystemRoot%\system32\drivers\etc\HOSTS file can still be used for Host name resolution. However, DNS will be queried before the HOSTS file is parsed.

If the DNS Host name (larger than 16 characters) is passed to a utility and there are 2 transports loaded on a workstation (TCP and NetBEUI), only the TCP transport will try to set up the session. If the Host name is not used and the NetBIOS name is used, then all transports will be tried.

In this example I could have also used:

\\157.55.100.204\public instead of \\scottsu-7.scottsu.com\public.

For more information on NetBIOS name resolution, you can refer to the white paper "Windows NT Server: Dynamic Host Configuration Protocol and Windows Internet Naming Service."

Note   On a Windows NT-based workstation, if a Host name is not found through DNS resolution, the name will be passed to NetBT (NetBIOS over TCP/IP) for resolution through WINS, LMHOSTS file, or broadcast. This might be seen as a feature for intranets that have many Web or FTP servers and want to get resolution through WINS for host queries.

Prakash Narasimhamurthy of Microsoft Consulting Services provided the flow charts shown in the following figures to illustrate name resolution for the various node types:

DNS Server to Connect to the Internet

Security Considerations

Many corporations today want to connect their internal networks to the Internet toprovide access to external resources to employees who need them to accomplish their assigned tasks. Although this is a very important capability, it is one that must be well planned to avoid possible data security risk from exposing the internal network to users outside the corporation. One common way to provide this protection is the use of a firewall. In Internet terms, a firewall is a system or device which provides network security by allowing only certain authorized activities to be accomplished between internal networks and the Internet.

A firewall system can be very simple or extremely complex depending on the particular requirements of the individual company. This paper is not designed to provide an exhaustive description of firewall design, but we will briefly discuss how the Microsoft DNS server can be used in a firewall environment.

Here is a typical Internet connectivity setup for a company using a dual-homed firewall (that is, proxy).

The firewall protects access from the outside while allowing clients on the internal network access to Internet resources. This design also allows for external WWW and FTP servers. These external servers must be closely monitored and secured as much as possible since they are directly on the Internet network with no "firewall"-type access control. The router can provide some security by providing packet filtering, if desired, to limit the type of traffic allowed. Access to the internal network is controlled by the firewall.

The internal Web server can be set up exactly like the external server except that security concerns are limited to the access controls necessary for company employees. Typically, only those responsible for Web development will actually log on to the internal servers to change the files located there, although everyone would typically be given the right to view the Web pages using a browser.

The Domain Name System for the external and internal networks are usually entirely isolated from one another. This prevents external clients from obtaining the names and addresses for internal resources located inside the firewall. The only thing an outside user will see is the IP addresses of the servers which are providing external services (that is FTP, www, e-mail, and so on).

Typical Internet Connectivity Design

With these security concerns now established, let's look at a typical Internet connectivity design and specifically at the way the DNS servers would be configured. Below is a diagram of a typical large company which has several internal and external resources which require DNS services.

Conclusion

Things You Can Count on for the Future

• Microsoft will adopt a "secure" Dynamic DNS solution and our clients will automatically register with the DNS. There will also be a process for using DNS to locate the closest Directory Services DC.
• The next revision of Directory Services will assume that DNS domains map to DS domains.

Rules to Architect a Good DNS Solution for the Future

• If there are servers within a site, there needs to be a DNS server within that site.
• Create a DNS domain for each Windows NT 4.0 domain.
• Every site DNS server should be a primary for the site-specific DNS domain and a secondary for the parent DNS domain.
• Windows-based clients should be registered in a site-specific DNS domain.
• Servers running Windows NT Server should be registered in a master DNS domain.