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