If there is one question that comes up repeatedly on the ISAserver.org web boards, it’s the question “how do I publish a DNS server”. The standard answer is to “create a server publishing rule”. While its true that you need to create a publishing rule to allow inbound access to the internal DNS server, there is a little more thinking that goes on to make it work.
| |
We don’t have the time to go over all of these DNS server types. But one situation that comes up often is how to publish a Standard Primary or Secondary or Active Directory integrated DNS server where external and internal resources share the same domain name. This configuration poses special problems because internal network clients will likely be asked to use the same DNS server as external network clients’ use.
Problems with Using the Same Domain Name for Internal and External Resources You can use the same domain name, hosted by the same DNS server and DNS zone, to provide name resolution for both internal and external network clients. However, there are some problems that you will run into. Some of these problems include:
A setup where there is a single DNS server on the internal network is shown below. Suppose you wanted to publish a mail server that is located on your internal network. In order for this mail server to be available to external network users and servers, there must be an MX entry on your DNS server to points to the IP address on the external interface of the ISA Server that you used for the SMTP Server Publishing rule. An example of how the Host (A) and Mail Exchanger (MX) records are configured is seen below: Note the mail.tacteam.net maps to the external interface of the ISA Server and an MX record points to this Host (A) record. This works fine because the external network clients are able to resolve the MX domain for tacteam.net to the IP address on the external interface of the ISA Server. The SMTP Server Publishing Rule forwards messages to the internal SMTP relay server, which in turn screens the messages and forwards the allowed messages to the internal Exchange server. If you have relatively sophisticated users that know how to configure their applications, and you don’t mind the dreaded 14120 errors in your event logs, you can implement this configuration with confidence. Problems creep in when you have unsophisticated users that move between internal and external networks and try to use the same DNS server to resolve the address of the internal SMTP relay. For example, we have a network client with an IP address 192.168.1.2 and it has Microsoft Outlook 2000 installed. If we set the SMTP address on the Outlook client to mail.tacteam.net, it will attempt to connect to the external address of the ISA Server and forward the mail back into the internal network through the Server Publishing Rule. This won’t work because the ISA Server will not “loop back” messages from internal network clients to a published SMTP server on the internal network. This phenomenon has been affectionately dubbed Isotropic Bounce by Jim Harrison. Isotropic Bounce is also seen when internal network clients try to access internal NNTP and POP3 servers through the external interface of the ISA Server. Solving the “Isotropic Bounce” Problem The obvious solution to the Isotropic Bounce problem is to create different Host (A) records on the DNS server for the same resources. In the above example, external network clients could be configured to use mail.tacteam.net and internal network clients could be configured to use midas2.tacteam.net. The mail.tacteam.net Host (A) record would point to the external interface of the ISA Server and the midas2.tacteam.net points to the mail server’s internal IP address. That solves the Isotropic Bounce problem, but you will probably have to deal with whining and crying from people who don’t want to change the settings on their mail and news clients. Alternative DNS Server Arrangements A better solution to the problem of using the same domain name for internal and external network clients might include one of following options:
The first option is depicted below: This is the best and most elegant solution because you don’t have to worry about publishing the DNS server. Resource records on the external DNS server point to the various external IP addresses on the ISA Server you use in your Web and Server Publishing rules. This option also obviates the problem of the dreaded 14120 error because the internal FQDN of a published Web server is not resolving to the external IP address of the ISA Server. The second option, where both DNS servers are located on the internal network, would look like this: The Internal DNS server would be used internal network clients only. No public addresses are included on the DNS server and it is never used for Web or Server Publishing. The Internal DNS server should be protected from all external network access. The External DNS server (located on the internal network) is used to host externally available resource records only. The resource records contained on this DNS server all map to addresses on the external interface of the ISA Server. These addresses are the ones you use in your Web and Server Publishing rules. This solution should also help you whack the dreaded 14120 error. Protecting the Internal Network from the Public DNS Server One of the major drawbacks of using the same machine as your public and private DNS server is that if the machine is somehow compromised, an attacker will not only have access to your entire zone database, but may also have access to your entire network. There is no functional way to partition this server away from the internal network because internal network clients need access for internal name resolution. If you choose to put the public DNS server on the DMZ segment between the router and the external interface of the ISA Server, then you don’t have to worry about external network users compromising your internal DNS server because they will never see it. The only DNS contact external users will have is with the DMZ DNS server with the public address. If you decide to place the public DNS server on the internal network, you have the option to partition that server away from the internal network. You can configure an IPSec Policy that prevents communications between internal network hosts (with the exception of the internal interface of the ISA Server) and the internal DNS server. This serves the function of placing the DNS server in its own security zone. The drawback of this solution is that you will have to manage the DNS server from the local console because you won’t be able to access it from any internal network host. Always remember: security and convenience are inversely related. This will always be the case; at least until your low security network is breached. Then there is a direct relationship Summary In this article we explored some of the DNS issues involved with using the same domain name for internal and external network resources. While the preferred method of hosting externally accessible resources is by using a domain name different from that used on the internal network, there are workarounds if you can’t or won’t do this. We examined some of the problems internal network clients encounter when they try to access internal network resources by going through the ISA Server. We also went over some solutions that will allow you to get around the problem of having users change application configuration parameters for when they are at an internal or external network location. Finally, we went over some important security concerns related to having a publicly available DNS server on the internal network. You saw how IPSec Policies can be used to partition the public DNS server away from the internal network and put it in its own security zone without having to deal with creating a separate DMZ for the public DNS server. In the second part of this article we’ll look at the actual procedures you go through to configure the DNS server and how to configure the Server Publishing Rules. We’ll even look at the Versign (Network Solutions) procedure you go through to assign the DNS servers authoritative for your domain. Note: If you want me to write an article on how to configure the IPSec Policies, write to me! Otherwise, I’ll assume you already know how to do this I hope you found this article interesting and/or helpful. If you have any questions on the issues brought up in this article, please post them on the www.isaserver.org message boards. You can also write to me at [email protected] and I’ll get to you as soon as I can. Please put the title of this article in the subject line. Thanks! –Tom. |