If you would like to read the next part in this article series please go to DNS Publishing Scenarios (Part 2): DNS Publishing Topologies
DNS issues come up quite a bit on the ISAserver.org Web boards and mailing list. Recently there have been a flurry of questions related to DNS publishing. This spate of questions regarding DNS publishing intrigued me, since DNS publishing is a pretty straightforward process, and it’s hard to imagine that there could be many problems with the procedure. As it turns out, it’s not the procedure of DNS publishing that gets people into trouble, it’s an understanding of what they’re trying to accomplish that leads to problems.
In this article series I’ll talk about DNS publishing. In the next series, I’ll switch gears and talk about outbound DNS issues. These are two very different topics, and perhaps a discussion of the differences between inbound and outbound DNS will help clarify some issues before we get into the details of DNS publishing scenarios.
DNS Advertisers
When you publish a DNS server, that DNS server lies behind an ISA Firewall Protected Network. The goal of publishing a DNS server is to allow external users access to the DNS server using the DNS protocol to resolve Internet host names (I’m leaving out the scenarios where the ISA Firewall is an internal perimeter firewall that is being used to protect a network services segment that contains DNS servers). When you publish a DNS server, you’re providing information that Internet based clients can use to resolve names for domains that you own.
For example, suppose you host your own Web servers on a DMZ behind the ISA Firewall. When external users want to connect to your Web site, they need to resolve the name of the Web site to the IP address on the external interface of the ISA Firewall that the Web listener for the Web Publishing Rule is using to publish the site. So, if they want to go to your Web site www.company.com, they need to send a DNS query to your published DNS server to resolve the name www.company.com to the IP address on the external interface of the ISA Firewall that’s being used by the Web listener.
That’s just one example of how you might use DNS for external users. Another example might be that you want to host your own DNS, but you host your Web and mail servers somewhere else. In that case, you configure your published DNS server to return the IP addresses of your Web and mail hoster. Just because you host your own DNS services doesn’t mean that you need to host all your other services. In some cases, you’ll host your own services (such as Exchange) but turn over hosting for your Web site to a third party. In this case, your DNS server will return your hoster’s IP addresses for the Web site and IP addresses on the external interface of the ISA Firewall for your E-mail publishing.
One thing that published DNS servers should never do is contain private information. When you publish a DNS server, you do so to provide public access to resources under your control. The goal is not to provide information about your private resources. You would never publish a DNS server that contains your private network records. Published DNS servers are referred to as DNS Advertisers, as they are advertising information about your publicly available resources.
DNS Resolvers
While DNS publishing is used to provide public access to domain names under your control, outbound DNS access is about name resolution for internal clients. When you allow outbound access to DNS, you’re enabling internal clients and servers the ability to resolve Internet host names. For example, if an internal client wants to visit the www.microsoft.com Web site, a DNS server must be put in place that can resolve the name for the client. These DNS servers may be dedicated to resolving only Internet host names, or they may be responsible for resolving both internal and external host names. In both cases, these machines are referred to as DNS resolvers, as their main goal is to resolve names that are external to your organization.
A key concept to understand here is that internal users should never be using your DNS advertisers to resolve names and external users should never be using your internal DNS resolvers to resolve names (the exception here would be VPN clients, where you want the VPN clients to use your internal DNS servers to resolve names of hosts on the internal network).
The reason why we never want internal users to use our advertisers for name resolution is that they can only resolve names for your publicly available resources. They can’t resolve names for any other domain. Also, even if you wanted to use the advertisers to resolve just your publicly available resources, you would have to allow internal clients to bounce back off the ISA Firewall to reach internal or DMZ resources. The solution to this problem is to use a split DNS infrastructure so that internal clients don’t bounce off the external interface ISA Firewall to reach host on the same or other ISA Firewall Networks.
The reason why we never want to allow external users access to our internal DNS servers is that these external users are anonymous, as we have no idea what their intent may be. Malicious users can gain useful information about our internal network if they are able to access our internal DNS servers, and for that reason we never allow external users access to our internal DNS servers (with the exception of the VPN clients that I mentioned earlier).
We’ll talk more about resolvers in a follow up article. This article is focused on DNS advertisers.
Securing the DNS Server Configuration on the DNS Advertiser
At this point you can see that when you publish a DNS server, you are publishing a DNS advertiser. Internet users must have anonymous access to your DNS advertisers, as there is no provision for authentication for DNS name resolution. Because of this, your DNS servers a likely to come under attack from anonymous Internet users and therefore you have to do some things to lock down the configuration of your DNS server. Note that these attacks will come only over UDP and TCP ports 53, because your DNS Server Publishing Rule won’t allow any other connections to access the DNS server.
The figure below shows the Properties dialog box of one of my DNS advertisers. It’s recommended that you have at least two authoritative DNS servers on two different subnets for fault tolerance reasons. However, when you’re publishing your own DNS servers, it doesn’t make much sense to have them on two different subnets, since if your Internet connection goes down, it doesn’t make a different if there is another DNS server somewhere that can resolve the names, because even if the external user could resolve the name, it wouldn’t matter, since the Internet link is down and they won’t be able to access the resources anyway.
However, its good to have at least two DNS servers in case one of them goes down. I typically set up two dedicated DNS resolvers in an anonymous access DMZ. That’s not the only way to do it, as you’ll see later when we talk about different DNS publishing scenarios later.
When in the Properties dialog box for the DNS server, on the Interfaces tab, make sure that you select the Only the following IP addresses option and then select the specific IP address of which you want the DNS server to listen for incoming DNS queries. This isn’t that big of a deal, but I found that doing so can prevent some potential troubleshooting issues in cases where the DNS server may have multiple IP addresses bound to it (such as in the case where the DNS server is also hosting many Web sites that listen on different IP addresses).
Figure 1
On the Forwarders tab, you want to remove the checkmark from the Enable forwarders checkbox. The reason for this is that we never want our DNS advertisers to become DNS resolvers. If you allow your DNS server to become a DNS resolver, you open it up to potential attacks that are not possible when its configured as an advertiser only. Also, this prevents anyone from using your DNS server as a resolver – why should you provide DNS resolution services to anyone and allow them to use your bandwidth? They can use their own DNS resolvers or their ISP’s DNS resolver.
Figure 2
On the Advanced tab, we want to put checkmarks in the Disable recursion and Secure cache against pollution checkboxes. The Disable recursion option prevents the DNS server from resolving names for which the DNS server is not authoritative. That is to say, if the DNS server can’t resolve the name from the Resource Records configured on the DNS server, then the DNS query will fail. The Secure cache against pollution option prevents attackers from polluting the DNS cache, although this technically isn’t possible when recursion is disabled. However, I enable this option anyhow because it makes me feel better (now I’m starting to sound like a “hardware” firewall admin!)
Figure 3
The root hints tab shows a list of Internet root DNS servers. These are the servers that are used when the DNS server needs to perform recursion. Since we don’t ever want our DNS advertisers to perform recursion, why not just remove all the root servers from the list and take away any temptation from ever enabling recursion? That is a good idea and all you have to do is select the root servers in the list and click the Remove button. When you’re done, your Root Hints tab should look like mine in the figure below.
Figure 4
Click the Apply button now to make sure your changes take effect and then click the Monitoring tab. Put a checkmark in the A simple query against this DNS server checkbox and then click the Test Now button. You should see a PASS value for that test. This means that your DNS server can resolve names for which it is authoritative, which is want we want it to do. Remove the checkmark from the A simple query against this DNS server checkbox and put a checkmark in the A recursive query to other DNS servers checkbox. Click the Test Now button. You should see a FAIL value for this test. This is what we want, since we don’t want our DNS advertiser to perform recursion and resolve names for which is not authoritative.
Figure 5
At this point our DNS server configuration is about as secure as we can make it. Note in this example that I’ve used a Windows DNS server, which works fine and is as stable as can be (I’ve had them run for over a year and then I only restarted it to install an update that was related to DNS services). However, you don’t have to use a Windows DNS server. Any DNS server is fine, and if you want to save some money, you can easily use an open source DNS service. Just make sure that you configure it so that it won’t perform recursion of any kind and only answers queries for domains and resources for which it is authoritative.
Before leaving the discussion for today, I’d like to cover one issue that never made much sense to me, but something that I think is worth covering so that no one gets confused. The issues is that of zone transfers. I’d met with a number of people who thought that when they published their DNS advertiser that they had to enable zone transfers from the DNS server on the internal network to the DNS advertiser which is likely located on a DMZ. The reason for why this never made sense to me is that records on your Internal DNS server should never be the same as the records on your DNS advertiser.
If you were to allow zone transfers from an internal DNS server to a DNS advertiser, you would be transferring private records about your internal network to a public DNS server, which is obviously something we don’t want to do! In general, you will not need to enable zone transfers from the internal DNS server to the external DNS advertiser.
Summary
In this article we went over some basic DNS principles as they apply to DNS advertisers and DNS resolvers. A DNS advertiser is a DNS server that only answers queries for domain and resources for which that DNS server is authoritative. When you publish a DNS server, in most cases you’ll be publishing a DNS advertiser so that external users will be able to resolve names for hosts in domains that are under your administrative control. A DNS resolver is a DNS server that can resolve names for Internet hosts and optionally for hosts on your internal network. When you configure a DNS server as a DNS advertiser, you should configure it so that it is unable to perform recursion and set it so that cache pollution is prevented. In the second part of this article we’ll go over some common DNS publishing scenarios and examine the advantages of disadvantage of each one of them. Thanks! –Tom.
If you would like to read the next part in this article series please go to DNS Publishing Scenarios (Part 2): DNS Publishing Topologies
