DNS Publishing Scenarios (Part 2): DNS Publishing Topologies

If you would like to read the first part in this article series please go to DNS Publishing Scenarios (Part 1).html.

If you would like to be notified of when Tom Shinder releases the next part in this article series please sign up to our ISAserver.org Real Time Article Update newsletter

This week we’ll look at a few of the more common DNS publishing scenarios and the topologies that drive them. The scenarios we’ll examine today include:

  • DNS Advertiser on the ISA Firewall
  • DNS Advertisers on an anonymous access DMZ segment
  • DNS Advertisers on an anonymous access back to back DMZ segment
  • DNS Advertisers on the internal network
  • DNS Advertiser on the domain controller

Discuss this article

Scenario 1: 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.

Discuss this article

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

Discuss this article

Summary

In this article we finished up our two part series on DNS publishing scenarios. We investigated several different scenarios and looked at the advantages and disadvantages of each of them. One common theme for all DNS publishing scenarios is that DNS Advertisers must be able to accept anonymous inbound connections from all Internet connected hosts if you wish them to be able to reach your domain’s resources. Because the DNS Advertisers are Internet facing hosts that require anonymous inbound connections, they must be segregated away from internal clients and servers. The way to accomplish this is by putting the DNS Advertisers on a anonymous access DMZ.

If you would like to read the first part in this article series please go to DNS Publishing Scenarios (Part 1).html.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top