How to Publish a DNS Server Part 1 – The Pathophysiology of the Same Internal andExternal Domain Name.








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.

All DNS servers are not created equal. DNS servers take on a variety of roles and the publishing of each type of DNS server may require different techniques. Some types of DNS servers you don’t want to publish at all! Common DNS server roles include:



  • DNS caching-only server
  • Active Directory integrated DNS server
  • Standard Primary DNS server
  • Standard Secondary DNS server
  • DNS Forwarder
  • DNS Slave server

Configuring ISA Server 2000 : Building Firewalls for Windows 2000
By Deb and Tom Shinder


Amazon.com

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.

In this article we’ll examine:




  • Problems with using the same domain name for internal and external resources
  • Network Designs to handle the problem
  • Security considerations and solutions for public DNS servers on the internal network

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:




  • Internal network clients will not be able to access internal SMTP, NNTP and POP3 resources using resource records that map to the published IP address of these services
  • The dreaded 14120 error
  • Exposure of your entire internal network’s resource records to external network clients

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:




  • Place the publicly accessible DNS server on the DMZ between the router and the ISA Server
  • Publish a second DNS server on the internal network that is authoritative for the internal domain name, but is used by only external network clients

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.


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