Friday , 29 March 2024
Home 4 Exchange server 4 DNS Publishing Topologies

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.

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.

DNS Advertiser on the ISA Firewall
In this scenario the DNS Advertiser is installed on the ISA Firewall itself. An external client makes a DNS query request to the IP address on the external interface of the ISA Firewall. The DNS server installed on the ISA Firewall is configured to listen only on the internal interface of the ISA Firewall and a DNS Server Publishing Rule is created that publishes this DNS server interface.

The reason why we want to use a DNS Server Publishing Rule instead of an Access Rule (which we could use if we configured the DNS server to listen on the external interface) is that when we use a Server Publishing Rule we can leverage the DNS application filter to secure our DNS server.

This scenario is obviously not an optimal one because when we install extraneous services on the ISA Firewall that allow anonymous inbound connections, we significantly increase the attack surface. While the Windows Server 2003 SP2 DNS server isn’t known for having any vulnerabilities, it’s still a valid theoretical concern. For this reason, I would only recommend this configuration for those companies who don’t have the resources to dedicated separate machines to act as their DNS advertisers.

Another limitation of this solution is that you only have a single DNS server so there is no fault tolerance – although this limitation may be more apparent than real since if the ISA Firewall goes down, so does access to any published DNS Advertisers that might be located behind the ISA Firewall. However, there is the possibility that the DNS service on the ISA Firewall could go down without having the entire firewall machine becoming unavailable.

The figure below shows the topologies of the DNS Advertiser on the ISA Firewall scenario.


Figure 1

Requirements for this scenario include:

  • Installing the DNS Server service on the ISA Firewall
  • Configuring the DNS Server service to listen only on the Internal interface
  • Creating a DNS Server Publishing Rule that publishes the internal IP address that the DNS Server service is listening on
  • Creating entries with the domain registrar indicating the IP address used in the DNS Server Publishing Rule is the authoritative DNS server address for the domain(s) being advertised

This is a fairly simple solution for a SOHO or small business, but not recommended for businesses that can afford to separate DNS server duties from the ISA Firewall

Scenario 2: DNS Advertisers on an Anonymous Access DMZ
In the second DNS Advertiser publishing scenario, the DNS Advertiser sits on an anonymous access DMZ. Many traditional firewall admins see a DMZ as a single type of network, but in practice this is not true. A DMZ is a location where Internet facing computers accept inbound connections from the Internet. The purpose of the DMZ is to separate these Internet facing devices from the internal network and network services security perimeters within the internal network. It’s for this reason that front-end Exchange Servers and Exchange Client Access Servers should never be placed on the internal network or in a network services security segment.

However, not all DMZs are the same. There are two major categories of DMZ enabled by the advanced firewall features provided by the ISA Firewall. These are:

  • The anonymous access DMZ
  • The authenticated access DMZ

An anonymous access DMZ is just that – a DMZ segment that allows anonymous inbound connections to hosts located in the anonymous access DMZ. Types of servers that would be placed in an anonymous access DMZ include DNS servers, SMTP relays, public access Web servers and public access FTP servers. What all these servers have in common is that there are no authentication requirements for accessing information on the servers located on the anonymous access DMZ.

As you can see, the anonymous access DMZ is the most insecure of the various network security zones because hosts on the anonymous access DMZ accept anonymous inbound connections from all Internet connected computers for the protocols allowed to those hosts.

On the other hand, an authenticated access DMZ contains hosts that require authentication before allowing access to resources. The authenticated access DMZ is more secure than the anonymous access DMZ because no unauthenticated connections are ever passed to servers on the authenticated access DMZ. However, the authenticated access DMZ is still less secure than hosts on the internal network or on internal network security perimeters because they are Internet facing devices and thus at a greater risk exposure than hosts that do not access inbound connections from Internet hosts.

In order for the authenticated access DMZ to actually be more secure than the anonymous DMZ requires that the ISA Firewall pre-authenticate the connections before passing them to hosts on the authenticated access DMZ. If the ISA Firewall did not pre-authenticate and pre-authorize the connections to hosts on the authenticated access DMZ, then the authenticated access DMZ would be no more secure than the anonymous DMZ, since connections for all Internet connected hosts would still be allowed to the servers on that segment even though the servers themselves might require authentication.

In this scenario the DNS server is on an anonymous access DMZ connected to a third NIC on the ISA Firewall. The connections must be anonymous, since there is no way you can authenticate DNS connections from anonymous hosts located throughout the Internet who need to resolve your public domain name.

You generally want to have at least two DNS Advertisers for your domain(s). As seen in the figure below, there are two DNS resolvers authoritative for the domains that they are advertising. This provides fault tolerance for your DNS server publishing solutions.


Figure 2

Requirements for this solution include:

  • Creating two Server Publishing Rules to publish each service in the anonymous access DMZ
  • At least three NICs in the ISA Firewall: one external, one internal, and one DMZ interface
  • Creating a Network Rule that connects the anonymous access DMZ to the Internet. In general this rule will be a NAT rule (although if you require it, you can use a Route Network Rule if you want to use public addresses in your anonymous access DMZ, however if you use a Route Network Rule, you still want to use a Server Publishing Rule instead of an Access Rule so that you benefit from the DNS application filter)
  • Creating entries with the domain registrar indicating the IP address used in the DNS Server Publishing Rule is the authoritative DNS server address for the domain(s) being advertised

This is a good solution for businesses of all sizes who can dedicate machines for the DNS advertiser role when only a single ISA Firewall is in use.

Scenario 3: DNS Advertisers in Anonymous Access Back to Back DMZ Segment
There are a lot of advantages to using a back to back ISA Firewall configuration. These include:

  • Less risk of firewall compromise because misconfiguration errors are minimized by not having to learn how to use different firewalls. Remember, firewall related security events are very rarely due to a problem with the firewall itself, the problem that leads to a firewall security event is firewall misconfiguration, so it is actually more secure to use two ISA Firewalls than to mix firewalls in most environments
  • The external ISA Firewall does not have to be a member of the domain, since authentication will take place at the internal ISA Firewall
  • The internal ISA Firewall can be a domain member so as to provide transparent and high performance authentication without having to use downlevel, less functional and lower performance authentication methods such as RADIUS or LDAP
  • Separate anonymous DMZ and authenticated DMZ duties. The external ISA Firewall controls the anonymous access DMZ and the internal ISA Firewall is responsible for authenticated access DMZ (which would require a third NIC in the internal ISA Firewall, which is not seen in the figure below).

When we have a back to back ISA Firewall configuration, the DMZ segment between the front-end ISA Firewall and the back-end ISA Firewall represents the anonymous access DMZ segment. DNS Server Publishing Rules are configured on the front-end ISA Firewall that allow DNS connections to the DNS Advertisers on this segment.

The figure below shows the topology used in this scenario


Figure 3

Requirements in this scenario include:

  • Creating DNS Server Publishing Rules on the front-end ISA Firewall that publish the DNS servers in the anonymous access DMZ
  • Creating a Network Rule that connects the anonymous access DMZ to the Internet. In general this rule will be a NAT rule (although if you require it, you can use a Route Network Rule if you want to use public addresses in your anonymous access DMZ, however if you use a Route Network Rule, you still want to use a Server Publishing Rule instead of an Access Rule so that you benefit from the DNS application filter)
  • Creating entries with the domain registrar indicating the IP address used in the DNS Server Publishing Rule is the authoritative DNS server address for the domain(s) being advertised

Note that you do not need to create any rules on the back-end ISA Firewall to allow access to the public access DNS servers. The reason for this is that internal users never need to access the DNS servers in the anonymous access DMZ. Internal users need to use internal DNS servers with DNS zones that are configured to be appropriate for internal user DNS server access.

Now you might ask “what if I have public Web servers in the same anonymous access DMZ segment as the public access DNS servers?” That’s a good question. What you need to do is configure your internal DNS servers with zones and resource records in those zones that point to the actual IP addresses of the Web servers in the anonymous access DMZ segment.

The reason why you don’t want internal users to connect to the DNS Advertisers is that the DNS Advertisers contain IP addressing information that appropriate for external users who will access resources in the anonymous access DMZ through the external interface of the front-end ISA Firewall. That is to say, you don’t want internal users to bounce off the external ISA Firewall to reach resources on the anonymous access DMZ – you want the internal users to connect through the back-end ISA Firewall to the Web servers themselves using an Access Rule on the back-end ISA Firewall.

The bottom line here is that you need to create a split DNS infrastructure to support this configuration if there are resources on the anonymous access DMZ that users need to access. Keep in mind that internal users never need to connect to your DNS advertisers!

Scenario 4: DNS Advertiser on the Internal Network
In the DNS advertiser on the Internal network scenario, the DNS Advertisers are located on the default Internal network. The assumption about the default Internal network is that clients and possibly network servers (Active Directory domain controller, WINS server, RADIUS server, File servers, etc) are located on the same network. On production networks, the default Internal Network is likely segmented into security zones, so that network servers and core services are located on a dedicated network security segment (or multiple segments) so as to correctly segregate security zones from one another.

I mention this scenario only as an object lesson in poor network security design. The reason why this is a poor network security configuration is that Internet facing devices are on the same security segment as non-Internet facing devices. This would be like putting the front-end Exchange Server or the Exchange Client Access Server (CAS) on the same segment as the network clients or even worse, on a network services segment on the internal network.

This is a very common mistake among newcomers to network security but easy to fix. All you need to do is put another NIC in the ISA Firewall and create an anonymous access DMZ and put the DNS servers on the anonymous access DMZ.


Figure 4

Scenario 5: DNS Advertiser on the Domain Controller
This is one of my favorite scenarios, not because I recommend it but because it taught me some important lessons about how DNS and split DNS infrastructures work. This is the worst possible configuration and should never be used, but there is something to learn from it and so I’m going to discuss it here.

Many years ago when I was getting to understand how the Internet works, I began my first attempt at making resources on my internal network available from the Internet. I didn’t know anything about firewalls at the time, and certainly didn’t understand the importance of security zoning. All I wanted to do was host a Web site on my internal network and make it available from the Internet.

Our internal domain at that time was tacteam.net and I wanted to be able to use that name from the Internet as well. What I found out was that I couldn’t do everything I wanted because I used my domain controller, my only DNS server, as the public DNS server for Internet host name resolution as well as for internal name resolution.

For example, if I wanted to use mail.tacteam.net for my mail server, I had to choose either the external address used for reverse NAT for that DNS host entry, or the internal address of the server. We’ll it wouldn’t work to allow internal clients to use the reverse NAT address to access resources on the internal network! That’s what got me to learn about split DNS and the high value that split DNS provides for any organization.

There are several problems with this configuration:

  • It won’t support split DNS
  • It exposes the Active Directory integrated internal names to the Internet
  • It exposes the domain controller to anonymous inbound connections from the Internet
  • It fails to respect the needs to partition Internet facing hosts (such as front-end Exchange Servers, Exchange Client Access Servers and DNS servers) away from network clients and servers

The figure below shows the topology for this configuration


Figure 5

Author: Thomas Shinder

Check Also

What No One Knows About

Charity is a good deed The Bible has a lot to say about charitable giving. In fact, the concept of giving to those in need is a recurring theme throughout the Old and New Testaments. Here are some key verses that highlight the importance of giving and generosity: 1. Deuteronomy 15:10 – ” Give generously …

A Quick History of

The Necessity of Expert Mole and Gopher Management Moles and gophers, despite their small size, …

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.