Back To Basics: DNS Server Roles -- Caching-only Servers

by ServerWatch Staff

Last week we began our discussion of DNS Server roles by examining some of the important characteristics of Primary and Secondary DNS Server. If you missed out on that discussion, you can check it out HERE.

Thomas Shinder

Last week we began our discussion of DNS Server roles by examining some of the important characteristics of Primary and Secondary DNS Server. If you missed out on that discussion, you can check it out HERE.

This week well take a look at some of the other important roles that DNS Servers take on:

  • Caching Only Servers
  • Forwarding Servers
  • Slave Servers
  • Dynamic DNS Servers

Caching Only Servers

All DNS Servers cache the results of their queries. However, some DNS Servers are put into place to provide only this caching function. The Caching-only DNS server does not contain zone information or a zone database file. The Caching-only server only contains information based on the results of queries that it has already performed. In this case, the cache takes the place of the zone database file. These Caching-only DNS Servers can be set up quickly, and are an important ally in your network and Internet security design.

All DNS servers have a cache.dns file that contains the IP addresses of all Internet root servers. The Windows 2000 cache.dns file is also referred to as the root hints file. The caching only server uses this list to begin building its cache. It adds to the cache as it issues iterative queries when responding to client requests to resolve Fully Qualified Domain Names to IP addresses. After the FQDNs are resolved to IP addresses, this information is stored in the DNS Server cache.

Caching only servers are valuable because:

  • They do not participate in zone transfer, and therefore there is no zone transfer traffic
  • They can be placed on the far side of a slow WAN link and provide host name resolution for remote offices that do not require a high level of host name resolution support
  • They can be implemented to provide secure host name resolution when configured as Forwarders

Remote offices are often connected to the main office via slow WAN links. These locations benefit from Caching-only servers because:

  1. There is no zone transfer traffic. For large corporate intranets with small remote offices, eliminating zone transfer traffic can be very beneficial since zone transfer traffic could have a negative effect on their slow link.
  2. There is a reduction in the amount of DNS query traffic that traverses the WAN to the corporate DNS Servers.

These Caching-only servers do not require expert administration. A satellite office is unlikely to have trained DNS administrative staff on-site. This saves the cost of having an experienced DNS administrator visit the site. However, in order to gain the most benefit from a Caching-only DNS Server, you must not reboot the computer. Since the DNS Cache only remains in RAM (or sometimes on disk in the page file), the contents of the cache will be lost if the server is rebooted. Be sure to include fault-tolerance mechanisms such as an UPS, Disk Mirroring, and redundant power supplies on such a machine.

Thomas Shinder

DNS Forwarders and Slave Servers

A Forwarder is a DNS server that accepts recursive queries from a DNS Server downstream in the query chain. Caching-only servers make good forwarders. A Caching-only forwarder can be used to protect internal zone files from Internet intruders.

For example, a DNS client sends a recursive query to its Preferred DNS server for a host located on the Internet. Since the DNS Client's Preferred DNS Server is located on the company's internal network, that corporate DNS Server will not be authoritative for the domain in question.

The Preferred server must resolve the host name for the client or return an error. You can configure the DNS client's Preferred DNS server to forward all queries for zones for which it is not authoritative. This DNS server will then issue a recursive query to a DNS Server configured as its Forwarder.

Forwarding and Forwarder Servers

Some of the terms used in the forwarding process require clarification. In this example, the client's Preferred server is "forwarding" the request to the "forwarder". The client's Preferred server is the forwarding DNS server. The DNS server receiving the forwarding server's query is the Forwarder. Therefore, the process of forwarding a DNS query involves both a forwarding DNS server and a forwarderDNS server.

Host Name Lookup Using Forwarders

The forwarder begins to resolve the host name in the query. It can do this by retrieving the information from its cache, from a zone file, or by issuing a series of iterative queries. If successful, it will answer the recursive query affirmatively and return the IP address to the forwarding server. The forwarding server completes its recursion by returning this IP address to the DNS client that initiated the query.

If the forwarder cannot resolve the hostname to an IP address, it will return to the forwarding DNS server a "host not found" error. If this happens, the Preferred DNS server (the forwarding server) will attempt to resolve the host name itself. The forwarding server will check its cache, zone files, or perform iterative queries to resolve the host name. If unsuccessful, a "host not found" or similar error is finally returned to the client.

You may not want the forwarding DNS server to issue iterative queries to servers located on the Internet. This will typically be the case when the forwarding server is an internal DNS server. Internal DNS servers that issue iterative queries for Internet host name resolution can become targets for hackers seeking information about your internal host naming scheme.

You can configure the forwarding server to not resolve host names when the forwarder fails to return a valid IP address. When the forwarding computer is configured in this fashion, it is referred to as a slave server. The slave server accepts responses from the forwarder and relays them to the client without attempting host name resolution itself, which it would do if the forwarder were not able to answer the query.

Thomas Shinder

Forwarders and Firewalls

The Slave Server/Caching-only forwarder combination is very helpful in protecting your intranet zone data. We can use this combination to prevent users on the other side of a firewall from having access to information on our internal DNS Server.

For example, at tacteam.net we have an internal DNS server we use to resolve DNS requests for resources inside of our corporate environment. As long as the requests are for only hosts in our internal network, DNS requests represent no security risk. However, what happens when users on the internal network need to access resources on the Internet?

What happens when one of our users wants to go to www.funtimes.com? When the recursive request hits our internal DNS server (which is authoritative for only tacteam.net), what does the server do? It begins to issue iterative queries to other DNS servers on the Internet in order to resolve the Internet host name. In the process, Internet DNS servers must send their responses directly to our Internal DNS machine through the firewall. The firewall must have the DNS ports open to Internet users in order for DNS responses to be send to our internal server. This exposes our internal DNS server, its zone data, and the nature of our requests to users on the Internet. How can we avoid this potentially dangerous situation?

The Solution

We can place a caching-only forwarder on the outside of a firewall and configure our internal DNS server to be a slave server. Now when one of our clients issues a name resolution request for an Internet host to our internal DNS server, the internal server will forward the request to the forwarder on the outside of the firewall. The forwarder will attempt to resolve the host name to an IP address. If successful, it will return the IP address to our internal DNS server, who will in turn return the IP address to the client that issued the request. If the forwarder is unsuccessful, it will report that to our internal server, who will report to the client that the host was not found. Our internal slave server will NOT attempt to resolve the host name itself. The slave then returns what the forward told it to the DNS client and the query fails.

At no time does an Internet DNS server attempt to send a response directly to our Internal server when we use the slave server/Caching only forwarder combination. The firewall is configured to allow outbound and inbound messages only to and from the forwarder.  In this way, our internal zone records are safe. 

Thomas Shinder

Dynamic DNS Servers (DDNS)

If there is one characteristic the defines the difference between the Windows 2000 DNS Server and previous versions of Microsoft DNS Servers, it is the Windows 2000 DNS Server's ability to dynamically update the information contained in its zone databases.

This behavior is very much like what you have seen with WINS Servers. A WINS Server allows NetBIOS nodes on the network to update their NetBIOS name and IP address mappings dynamically. This was a real advantage on earlier versions of Microsoft networks since all of them had been NetBIOS based.

Windows 2000 is free of the shackles of NetBIOS (for the most part) and uses the DNS scheme for computer and domain naming. While there are many advantages to using the DNS rather than NetBIOS, there is a major problem: zone database files were originally designed to be static databases. If any update needed to be done to the zone contents, it would have to be done manually by the DNS administrator.

Manual administration of the zone databases on a large a DNS based network, such as an enterprise Windows 2000 network, would be a very large and difficult task. The task would be even more onerous when DHCP is used extensively and when DHCP assigns varying IP addresses to shared network resources. The Dynamic DNS Update Protocol solves this major hurdle to widespread implementation of DNS on Windows networks.

Dynamic DNS works more effortlessly when all the clients on the network are running Windows 2000. A Windows 2000 client can register its own Host (A) record and Pointer (PTR) record information in the DDNS zone database file. Most network won't work this way, and you'll have a mix of network clients. In this case, you should take advantage of the Windows 2000 DHCP Server's ability to dynamic register Host and Pointer record information at the DDNS Server on the behalf of downlevel Windows based clients.

Bottom Line

The Windows 2000 Server can take on many different roles. What role the server takes depends on what requirements you have for your network. DNS Server roles are also dependent on whether or not you choose to integrate DNS with the Active Directory. We haven't address Active Directory Integrated DNS Servers yet, but they are something you should become familiar with before implementing DNS on your network, and definitely before you take your Windows 2000 exams!

This article was originally published on Tuesday Sep 26th 2000
Mobile Site | Full Site