Caching-Only Servers
There is a simple way to configure a server for a remote site without forcing it to participate in a zone or perform zone transfers. Configuring a name server as a caching-only server, and configuring it with the IP addresses of upstream DNS servers, does this. When configured this way, the name server will accept DNS queries from clients, check its own cache, and return an answer if it was able to resolve the name from the cache. If the name being resolved was not located in the cache, the DNS server will forward the query on to the upstream DNS server, store the result in its cache, and return the answer to the client.
Caching-only DNS servers are really easy to configure in Windows NT. In fact, any default installation of the DNS Server service is automatically configured as a caching-only server. All you need to do to configure a server in this manner is not configure it as part of a zone.
There are many ways in which you may use a caching-only DNS server:
They may be used at remote sites to reduce the amount of DNS query traffic that must pass across the WAN link. This is similar to the method I described for configuring a secondary name server at a remote site; however, it eliminates the overhead involved in zone transfers.
Caching-only DNS servers are commonly used on the local side of an Internet connection to reduce the amount of queries that must be sent to the ISP’s DNS servers.
Servers that perform a great deal of reverse-DNS lookups, such as Web servers, are often configured as caching-only DNS servers.
How DNS Servers Talk to Each Other
As you already know, primary and secondary servers have methods to exchange data so that they may each have a reasonably accurate copy of the DNS database, known as a zone file. The file transfer between these systems always moves downstream, from the primary name server to the secondary name server(s) within a particular zone.
It is tempting to think of this transfer as taking place in the same way that data is transferred between a primary domain controller and a backup domain controller, but they work in very different ways. While PDC-to-BDC transfers perform a similar function, they are capable of transferring incremental changes. DNS is not this elegant; each time a modification is made, the entire zone file must be transferred. As you can imagine, this can be a bandwidth-consuming transfer in large zones.
ZONE MODIFICATION NOTIFICATION
Zone transfers are inefficient beasts, but they do not happen without some level of intelligence. It would be really wasteful if secondary servers simply downloaded the zone file on a prescheduled basis, so DNS has implemented a method of checking for changes. By default, secondary name servers check for a modification to the zone file when the DNS service starts and every three hours thereafter. The administrator can change this default.
This zone modification check is done by comparing a value in the SOA record of the primary name server with the corresponding value stored by the secondary name server. In this way, the SOA record is used to store information about the status of the zone file. Within that SOA record is a field called Serial Number (also referred to as Version Number), which increments each time a change is made to the database.
Using the serial number, the secondary name server is able to determine whether changes have occurred since it last requested a zone transfer. If the secondary name server finds that the serial number of the primary name server is greater than its own, it will request the newer copy of the database.
The impact on the network of merely checking the version of the zone file is minimal. A single packet is transmitted from the secondary name server to the primary name server, and a single packet is returned in response. The first packet is nothing more than a request for the SOA record, and the response is (logically enough) the current SOA record. Because of this clever design, the version of the DNS database may be checked without adding any complexity to the DNS protocol–the standard method of querying DNS records works well.
ZONE TRANSFERS
As described in the previous section, a zone transfer occurs each time the primary name server notifies a secondary name server that an update has occurred. If the database version reported by the primary name server is indeed greater than the version currently stored on the secondary name server, the secondary will send a request for zone transfer packet to the primary. This is a special type of packet, which shows up in Network Monitor with a description of “Std Qry for <domain name> of type Req. for zn Xfer on class INET addr.” The response will be the sum total of the zone file, which varies widely in length depending on the size of the database.
The fact that there is no incremental zone file transfer is a great reason to keep your zones small, and primary and secondary name servers close together. If you frequently update the DNS database, zone transfers will happen, at most, every three hours. Keeping the zone file small helps to keep the impact on the network low. This is an especially important consideration for zone transfers that occur across low-bandwidth links.
Name Resolution
So far in this chapter, I’ve spent a lot of time talking about clients and servers querying each other, but I haven’t gone into any detail regarding how these queries are performed. There are several different ways, and a lot of complexity, to determine exactly how these queries behave. Essentially, all queries can be divided into one of three families: recursive, iterative, and reverse (or inverse) queries.
Beyond these three types of queries, other functionality can be provided. For example, DNS servers can be configured to return several different IP addresses in response to the same name. Further, Windows NT, since version 4.0, has the ability to resolve NetBIOS name resolution requests using DNS.
RECURSIVE QUERIES
The most common type of query on most networks is the recursive query. This type of query is common because all queries between end-user systems and name servers are recursive. Issuing a recursive query is the client’s way of saying to the name server, “Please resolve this name, and don’t even think about passing the buck!”
When a name server receives a recursive query, it must make a best effort to resolve the name and return an answer to the client. It is not allowed to refer the client to another DNS server: if it can’t return an answer, for whatever reason, it must simply return a “not found” type error message.
Slaves also use recursive queries when querying a forwarding server. Because the forwarding server is the slave name server’s only chance for resolving a given name, the query must be recursive.
ITERATIVE QUERIES
An iterative query is typically passed from one DNS name server to another in an effort to resolve a hostname. A name server that receives an iterative query is allowed to return a result that merely refers the client to another name server with more authority over the domain given in the request.
A typical scenario in which iterative queries will be used is one in which a name server must resolve a name within an unfamiliar domain. For example, if an ISP’s name server is queried for the IP address of the Web server www.idgbooks.com, it will query the root server. The root server will not return the IP address of the site requested but will instead refer the name server to the authoritative name server over the .com top-level domain. The ISP’s name server will, in turn, query the .com name server, which may refer it to the idgbooks.com authoritative name server. In all likelihood, the authoritative name server for idgbooks.com will be able to resolve the name WWW.IDGBOOKS.COM without referring to another name server.
REVERSE LOOKUPS
Commonly used by servers for logging and authentication purposes, reverse lookups resolve an IP address to a DNS name. Ironically enough, they operate exactly the “reverse” of a standard DNS query.
If you don’t have any experience with DNS, it may seem that the name servers would simply look through the list of IP addresses in a zone file and return the name associated with that address. Unfortunately, it is not nearly that simple. There is no direct correlation between IP addresses and DNS names, so a special domain was created in order to facilitate reverse lookups. This domain is called in-addr.arpa, which may seem somewhat cryptic.
Before I describe exactly how reverse name lookups are performed, let’s review a couple of basics of DNS naming. First, a domain name consists of several names separated by dots. These names get less specific as you read them from left to right. Therefore, subdomains within a domain are prepended to the domain name. Confusingly enough, IP addresses are organized entirely the opposite way. An IP address also separates octets with dots, but they get more specific as you read from left to right. With that in mind, read on....
In order to make the IP and DNS naming schemes more compatible, the order of the octets within an IP address is reversed and added to the in-addr.arpa reverse-lookup domain. For example, to allow the IP address 10.3.17.77 to be correctly resolved to the name www.mycompany.com, you would add the entry 77.17.3.10.in-addr.arpa to your DNS servers.
This method works out conveniently for management as well, since administration of the in-addr subdomains may be given to each organization as it is assigned a range of IP addresses. Therefore, each company can administer and manage reverse-lookup DNS records individually.
Once subdomains have been built under the in-addr.arpa domain, records must be added to the zone files to allow for reverse lookup of individual hosts. A special type of record, called a PTR (pointer) record, is reserved for this type of lookup.
IN-ADDR.ARPA: What?
For the curious, the subdomain used for reverse lookups is named as a shortened form of “inverse address.” The “arpa” portion of it refers to the Advanced Research Projects Agency, a division of the government that participated heavily in the development of DNS and the Internet.
ROUND-ROBIN
For many, “round-robin DNS” is the answer to the question, “How do I balance a load between multiple servers?” Others feel it better answers the question, “What is an efficient method of load balancing that can cause numerous, unpredictable, and difficult-to-troubleshoot problems with my end users?” No matter what your opinion, round-robin DNS is a common method of distributing traffic between an array of servers.
Round-robin works by answering DNS queries with an entire list of IP addresses, rather than a single IP address. The application that performed the query generally chooses the first IP address and references that server for all future communications with that server. To ensure that client-side applications do not choose the same IP address, the list is rotated so that a different IP address appears at the top of the list each time. This is considered “round-robin” fashion.
This method of load balancing is extremely common on Internet Web sites. Microsoft is a big fan of round-robin DNS. To get an idea of what these DNS responses look like, perform an NSLOOKUP for www.microsoft.com (a very busy site on the Internet).
As you can see, Microsoft (at the time of this writing) makes use of 15 different IP addresses for the Web server known as www.microsoft.com. To get an idea of how round-robin works, press the Up Arrow key and run the same command again. You will get a very similar response, as shown here:
Notice the difference between the first and second examples? The second example has the same set of IP addresses, but they have all been shifted up one. I think of it as like geese, flying in a V formation. Each goose takes a turn at the head position, and after that goose gets tired, it moves to the back of the V and the next goose in line takes the first position.
If you get bored, do NSLOOKUPs on a few other sites that use round-robin. You will notice that sometimes these systems are not even on the same subnets! It is even possible to perform round-robin load balancing on systems that are in completely different parts of the country, though it is a really bad idea. Here are a few examples:
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
