Zone Hierarchy
The DNS name space is also divided into zones, subdivisions of a domain. A zone actually refers to a zone file, which contains the DNS information for that portion of the domain. While a domain is a logical grouping within the DNS name space, the zone is an actual file on DNS server’s hard disk, which stores the DNS records themselves. For any given domain, there are one or more zones. Each zone may encompass a domain and/or subdomains, and different zones may manage various subdomains. Make sense? Hopefully the next example will help.
Imagine that you are an administrator for the cleverly named company “MyCompany.” Fortunately for you, nobody has registered that name with the InterNIC, so you register and receive the domain name. You are responsible for configuring the organization’s internal DNS servers and designing a DNS architecture. In order to divide your portion of the name space, you create four subdomains within mycompany.com, one for each division of the company: pilfering, looting, plundering, and accounting.
You will personally manage the pilfering and looting subdomains, but you know the IT manager for the accounting group will want to manage both the accounting name space and the plundering subdomain’s name space. In order to allow that manager to have free reign over his subdomains without bothering you, you create a different zone for them. The zone and domain architectures are illustrated in Figure 12-2.
The Server Hierarchy
As the number and importance of DNS servers increases, it becomes more and more important to ensure that they are both scalable and reliable. The DNS protocol itself has the capability to allow DNS servers to fail-over for each other and to share a load between multiple systems.
There are two levels of name servers: primary and secondary. The primary name server is the definitive source of DNS information for the domain. All other DNS servers for a domain ultimately pull their information from the primary name server, which stores the master copy of the zone file locally.
Secondary name servers exist to provide redundancy, load balancing, and distributed access. Secondary name servers gather all their information from the primary name server. In other words, secondary name servers are not responsible for any unique information; everything they know is handed from the primary name server. Secondary name servers serve a similar role to backup domain controllers in a Windows NT domain.
Secondary name servers transfer the zone file from the primary name server using a process called a zone transfer (cleverly enough!). A zone transfer is little more than a file copy between the two systems, but it gets the job done. Once the secondary name server has a copy of the primary name server’s zone file, it is able to answer DNS queries in the same way the primary name server would.
The roles name servers play is both flexible and complicated. Unlike primary and backup domain controllers in a Windows NT domain, name servers can play multiple roles in different domains. For example, the primary name server for the domain accounting.mycompany.com can be the secondary name server for the domain looting.mycompany.com. This is done merely by specifying the correct properties in the DNS Manager.
Specifically, secondary name servers must be configured with the IP address of the upstream DNS server–either the primary name server or another secondary name server.
PLANNING FOR REDUNDANCY
So as you can see, configuring secondary domain servers can provide a level of redundancy by making an extra copy of the zone file available to network clients. Having an extra copy of the database is only one part of an effective DNS fail-over solution, however. DNS does not take into account how clients that have been configured to query a particular DNS server will contact a different DNS server in the event the first fails. This fail-over is implemented on the client-side operating system. In Windows NT, an unlimited number of DNS servers should be configured on all clients, as illustrated in Figure 12-3.
The client always begins queries by checking with the first listed server. If that server fails to respond, it will work its way down the list until it finds an active server. By listing multiple DNS servers in the TCP/IP property sheet for each client on your network, you may provide for fail-over of DNS without making any changes to the server configuration. Therefore, if your NT clients were configured as shown in Figure 12-3, they would query 192.168.10.5 until it failed to respond. At that point, queries would instead go to 192.168.20.5.
The two servers should operate as independently as possible. This is not only a good rule of thumb for DNS servers but works well anywhere redundancy is desired. Place your DNS servers on separate networks, on different electrical circuits, and even in separate buildings if at all possible. By separating redundant servers as much as possible, you greatly increase your chance that a secondary name server will still be available in the event of a failure of the primary name server.
PLANNING FOR LOAD BALANCING
Redundancy and load balancing are often thought of together. Redundancy is generally the priority; after all, you should make sure critical systems will be online at all times before you start to worry about their performance. However, once an administrator configures multiple servers to do essentially the same jobs, such as primary and secondary name servers, it becomes tempting to put both machines to work at the same time.
Redundancy is easily configured with name servers because the fail-over responsibilities are placed on the client. As described earlier, DNS clients are generally configured with a list of DNS servers to check, and they will work their way down the list until they find a DNS server that responds appropriately. Creating load balancing between these servers is as simple as configuring different clients with the same list of servers, but in a different order.
For example, consider an organization with three DNS servers. These DNS servers have the IP addresses 192.168.10.5, 192.168.20.5, and 192.168.30.5. The first of these servers is the primary name server; the other two act as secondary name servers. The third server, located at 192.168.30.5, is really just an administrator’s desktop system and shouldn’t be relied upon, but it could be used in a pinch. The administrator wants to put less of a load on the primary name server, and no load on his desktop machine unless it’s an emergency. Therefore, one-third of the clients on the network should be configured with DNS servers as listed in Table 12-2. The other two-thirds should be configured as shown in Table 12-3.
Of course, this is a simple example. Your networks may be much more complicated and may have a different DNS server configuration for each subnet. As a general rule, configure at least three DNS servers, and place them in the following order:
First DNS Server: The server closest logically to the client. This is often a DNS server with a network interface card on the same subnet.
Second DNS Server: The server second-closest logically to the client. It is preferable that it not be on the same subnet as the first listed DNS server; however, this is not essential. Your primary goal here is to provide for system-level redundancy because the likelihood of the network failing is far lower than that of the system failing.
Third DNS Server: A last-resort. This system should be an authoritative name server and should act as the third name server for all systems within an organization. In this way, if a large section of your network has some kind of failure, clients may still be able to access a DNS server that can respond to their queries. If a nonauthoritative system were listed here, it is possible that the clients would be able to query the DNS server but that the name server would not be able to respond to the queries because it could not reach an authoritative server. The third name server should never be queried unless things are going really, really bad anyway.
PLANNING FOR DISTRIBUTED ACCESS
Another excellent reason to use secondary name servers as part of your DNS architecture is to allow for distributed access in a wide area network environment. An excellent way to reduce the amount of traffic generated by DNS queries across a WAN link is to place a secondary name server at the remote site and configure all clients at the remote site to query their local name server first, as illustrated in Figure 12-4. Naturally, the secondary name server will generate some traffic of its own in the form of zone transfers, but in most cases this will be substantially less than the traffic generated by DNS queries from the clients.
Distributing network services is a common method for reducing WAN traffic and is mentioned in several places throughout this book. Earlier in this chapter, I compared secondary name servers to backup domain controllers. To extend this analogy, placing a secondary name server at a remote site is done for the same reasons that most organizations place a backup domain controller at a remote site: to provide services to clients without forcing them to generate traffic across the WAN link, to provide some redundancy, and to reduce the load on the primary system.
Forwarders
In a DNS architecture, a DNS forwarder is similar to a proxy server. Forwarders are used to allow internal name servers the ability to resolve queries for external names, without giving the internal name servers access to the external network (whew!). Forwarders are specified at each name server and are used to help resolve all queries that the queried name server cannot answer directly, as shown in Figure 12-5.
An example is definitely in order....
You are in charge of the internal DNS infrastructure of your organization. You are in the process of connecting the domain to the public Internet and have decided to have only a single entry point, through which all traffic must pass. This server acts as an HTTP and SOCKS4 proxy to the rest of the domain, allowing access for many different types of traffic. Because SOCKS proxy clients require the ability to resolve IP addresses for the external network, your internal DNS servers must be able to resolve names on the public Internet.
Because you cannot put them all on the external network, the best method to provide this functionality is to configure the existing proxy server as a forwarder. You configure all other DNS servers as slaves to these forwarders. When a client attempts to resolve an external DNS name, such as www.idgbooks.com, it will pass it to the nearest DNS server. That DNS server will check its own zone file for the entry but will not find it. Because it has been configured as a slave, it will forward the request to the name server forwarder, which can resolve the name because it has access to the public DNS servers at your ISP’s premises.
Masters and Slaves
I hope you didn’t jump to this section after glancing at the table of contents, thinking you finally found an interesting topic in this book (unless, of course, you consider DNS architecture interesting, in which case you’re in the right place).
As described earlier, secondary name servers perform zone transfers to retrieve the zone file. The secondary name server may be configured to retrieve this information from either the primary name server or another secondary name server. In either configuration, the systems participating in the relationship receive special titles: master and slave.
The master name server is the system from which the slave draws its information. You may also think of these systems as being upstream and downstream.
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
