Web Development

SolutionBase: Developing a DNS name resolution strategy for a Windows Server 2003 DNS

It would be nice if you could just load DNS on your server and walk away. But it's not quite that simple. How you implement DNS is just as important as it is to begin with. In this article, Brien Posey shows you how to create a naming strategy.
This article is also available as a TechRepublic download.

One of the most critical components of any TCP/IP network is the DNS server. DNS servers do everything: resolve Internet URLs into IP addresses; resolve host names on the local network; and provide the underlying infrastructure that the Windows Active Directory is dependent on. As such, deploying a DNS server is not a task to be taken lightly.

In this article, I will discuss the process of developing a DNS name resolution strategy. As I do, I will talk about things like your DNS server's role, DNS server placement, and the number of DNS servers that are appropriate for your network.

How many DNS servers do you need?

It is fairly rare for a network to depend on a single DNS server for all of its name resolution needs. That being the case, you are probably wondering how many DNS servers you will require. There are a lot of different factors that go into determining how many DNS servers will be required on a network, but let's begin by talking about the DNS server's capacity.

Even a modestly equipped DNS server is capable of handling a huge number of name resolution requests. For example, while researching this article, I ran across an older Microsoft document that indicated that a 700 MHz Pentium III running Windows Server 2003 as a dedicated DNS server should be able to resolve about 10,000 names per second. If that is true, then you can only imagine how many name resolution requests a newer DNS server could resolve.

Unless you work for a huge company, you are probably looking at this number and thinking to yourself that there is no way that your DNS server will ever have to service that kind of workload. So why not just deploy a single DNS server and call it a day?

There are lots of reasons why deploying a single DNS server is a bad idea. I will talk about these various reasons throughout the article. Probably the best argument against relying on a single DNS server is fault tolerance. After all, your DNS server provides a critical network service. If your network only has a single DNS server and that DNS server fails, then your network will cease to function. You will therefore want to have a minimum of two DNS servers for fault-tolerant purposes.

DNS server roles

Fault tolerance is only one of many different reasons for having multiple DNS servers; a DNS server can perform many different tasks. Companies often determine how many DNS servers to deploy based on the roles those DNS servers will perform. A single DNS server is perfectly capable of performing multiple roles, but configuring a DNS server to handle multiple roles is sometimes a bad idea from a security standpoint. This is especially true when a DNS server is exposed to the outside world. Even if security is not an issue, making a DNS server perform double duty can sometimes impact the server's performance.

In the sections that follow, I will discuss the various roles that a DNS server can perform, and the implications that those roles have on the way that DNS is deployed throughout your network.

Providing Internet access

Technically, a DNS server does not provide Internet access. It does, however, help make the Internet accessible to users on your network. As I'm sure that you know, every Web site has a corresponding IP address. In order to access a Web site, a computer must know that site's IP address. As such, a computer that needs to access a Web site performs a DNS query to determine the requested site's IP address.

If you simply need to provide Internet access to the users on your network, then you technically do not need to deploy a DNS server. Your ISP has DNS servers of its own that it will allow you to use. You can simply configure the machines on your network so that the preferred DNS portion of the TCP/IP configuration points to your ISP's DNS server.

Although a local DNS server is not required for Internet access since your ISP offers the use of their DNS server, some companies choose to implement a local DNS server anyway. The advantage is that having a local DNS server will conserve Internet bandwidth because it will cache names that have been resolved.

Imagine, for example, that someone on your network needs to access www.google.com. They enter the URL into their Web browser, and the browser looks to the DNS server to resolve the google.com domain name. Your DNS server is not authoritative for google.com, so it has no idea what Google's IP address is. However, the DNS server is configured so that if it is unable to resolve a name, then the query is forwarded to your ISP's DNS server. Your ISP's DNS server resolves the query and passes the IP address back to the local DNS server, which then passes the address back to the Web browser that originally made the request.

This process probably sounds inefficient (and it is), but your DNS server now knows the IP address for the Google Web site. When another user tries to visit the Google Web site, the local DNS server already knows IP address, so it does not have to forward the request to your ISP’s DNS server. You can implement a caching-only DNS, such as the one that I have just described, without having to register the DNS server’s IP address. In fact, it is best -- from a security standpoint -- if you use a private IP address and do not allow the server to be publically accessible.

Having a local DNS server that already knows the necessary IP address makes the name resolution process much more efficient. The name resolution takes less time because it is being done locally, and you save Internet bandwidth to boot.

Active Directory

If you are planning on deploying a Windows network that makes use of Active Directory, then you will have no choice but to deploy at least one DNS server, because Active Directory can not function without a DNS server. As I explained before though, DNS is a critical service, so it would behoove you to deploy multiple DNS servers for fault-tolerant purposes.

In an Active Directory environment, the DNS server is used as a mechanism for assisting in locating domain controllers. As such, Active Directory requires that the DNS server that you use support DRV records. As you would expect, the DNS services that are included with Windows Server 2003 meet the necessary criteria.

Active Directory requires a DNS server to locate domain controllers; computers on an Active Directory based network typically also use the DNS services to resolve the names of network hosts. Versions of Windows prior to Windows 2000 used NetBIOS names, so they were able to use WINS as their primary name resolution method. Today, WINS is all but extinct, and most companies use NDS as a mechanism for resolving the names of network hosts.

If you find yourself having to deploy DNS because you are building an Active Directory network, you will be happy to know that, in doing so, you automatically gain the benefits of a caching-only DNS such as the one that I described in the previous section. In an Active Directory network, you can’t use your ISP’s DNS server to resolve host names on your local network (unless those hosts are publicly accessible and your ISP’s DNS is authoritative for the domain). As such, you will need a DNS server that is local to your network. All of the hosts on the network are typically configured so that the Primary DNS portion of their TCP/IP configuration points to that DNS server.

The problem with this type of configuration is that if network hosts are pointed to a local DNS server rather than to an ISP’s DNS server, then there is no means for resolving Internet domain names. Unless, that is, you add the IP address of your ISP’s DNS server to your DNS server as a forwarding address. In doing so, you create a caching-only DNS that meets all of the criteria for supporting Active Directory, and for resolving names on your local network.

Hosting an Internet domain

Another situation that requires a DNS server is hosting an Internet domain. Typically, when a company hosts an Internet domain, they are actually hosting a Web site that uses the domain name, but they may also host Web servers or any other type of Internet accessible resource. To keep things simple, I will assume for the purposes of this article that the company in question wants to host their own Web site.

As I have already explained, every Web site has an IP address. When a user decides to visit that Web site, they enter the site’s URL, but their Web browser must perform a DNS query to resolve the URL to an IP address.

What this means is that if you want to host your own Web site, you will need to have a publicly-accessible DNS server that contains the IP address of the server that is hosting the Web site. Furthermore, the DNS server should be in place at the time that you register your domain name because the registrar will ask you for the IP address of the DNS server that should be considered authoritative for the domain. You do have the option of changing the DNS server’s IP address later, but it usually takes 24-48 hours for the switch to go into effect.

When you are planning the DNS server that will be authoritative for your Internet domain, the biggest thing to remember is that the DNS server does not have to be a part of your network. In fact, most ISPs will allow you to use their DNS server as the server that is authoritative for your domain. This service is typically included for free when you allow the ISP to host your Web site, but the ISP will usually charge you a fee to host the DNS if you are hosting the site yourself.

Depending on the level of service that your ISP offers, it might be best to let them host the DNS records associated with your Web site. Doing so frees you from the burden of maintaining the DNS server yourself, and it provides a degree of security since users won’t be accessing a server on your network (not for name resolution, anyway). It is important to look at your ISP’s service level agreement (SLA), because the DNS server will need to be available 24/7.

Another advantage to allowing an ISP to host your DNS records is that doing so helps preserve your Internet bandwidth. Recursive DNS queries can consume a significant amount of bandwidth, which would flow across your routers and consume your bandwidth if you host your own DNS server. Allowing your ISP to host the DNS services for you keeps this traffic off of your network.

There is one disadvantage to allowing an ISP to host your DNS records on your behalf. Occasionally, the DNS records will need to be updated. For example, if you were to replace your Web server, then your DNS records would need to be updated with the new server’s IP address. If your DNS records are hosted with an ISP, then you may not be able to update the records yourself. It could be that any time the DNS records need to be updated, you have to submit a request, pay a fee, and then wait for your ISP to make the change.

Performance

So far in this article, I have talked about some of the more common uses for DNS servers, and about how multiple DNS servers should be used for fault-tolerant purposes. When deciding how to deploy DNS on your network, it is also important to take performance into account.

For example, earlier I mentioned that even an older DNS server is theoretically capable of performing up to 10,000 name resolutions per second. Having a server that can perform such a high number of name resolutions is great, but you must consider the impact on the rest of your network. Suppose, for instance, that you had a network made up of five segments and you put two DNS servers (for fault tolerance) on one of the segments.

In a situation like this, network nodes on all of the other segments would have to perform cross-segment DNS queries. This could potentially overload your routers or congest the segment that the DNS server resides on. It would therefore be wise to estimate the impact of DNS queries on the network as you are choosing the number of DNS servers to use and their placement.

If your network spans one or more WAN links, then I would recommend placing a DNS server on each side of those links. This will keep DNS queries from congesting the WAN links. If you are deploying an Active Directory environment, then you could create Active Directory integrated zones. You could then place the primary DNS server in the main office and secondary DNS servers in the branch locations. Zone transfers could be used to keep the DNS zone data in the branch locations current with a minimum of impact on bandwidth. Of course computers in the branch locations would need to have their TCP/IP configuration adjusted so that the computer will use the nearest DNS server.

How you do DNS is as important as DNS itself

As you can see, deciding how DNS servers will be distributed throughout your organization is an important job. In doing so, you should consider the roles that the DNS servers will need to perform, as well as security and performance.

3 comments
cousintroy
cousintroy

Yes, very good article. Though like Dumphrey said that this just touches the basics...DNS in itself is a beast that you think you might think you have an understanding of but can come back to haunt you. But I believe that with the advent of Active Directory Integrated Zones DNS server setups are much easier in Windows networks. But I am still very new to actually setting up and administering DNS.

Dumphrey
Dumphrey

Alot of relevent info in a short space. Too bad this is at best just an intro to DNS =\ I have spent way to much time in the past year dealing with DNS. Now days it just works, but it was a trial getting it repaired without taking down the whole network.