You Need to Create a Split DNS!
By Thomas W Shinder, M.D.
You’ve heard me and other say this over and over again on the www.isaserver.org messages boards: "You need to create a Split DNS!" The reply is most often "what’s a split DNS". At that point we point you to somewhere on the Internet or tell you to look it up on Google yourself 
. I think its about time we covered it here at www.isaserver.orgsince the subject comes up so often and everyone running ISA Server may benefit by implementing a split DNS if they use the same internal and external domain name.
. I think its about time we covered it here at www.isaserver.orgsince the subject comes up so often and everyone running ISA Server may benefit by implementing a split DNS if they use the same internal and external domain name.What is a split DNS and why would you need it? A split DNS infrastructure is a solution to the problem of using the same domain name for internally and externally accessible resources. It’s the difference in how internal and external clients access resources that cause the problem.
Let’s look at an example. Suppose your internal network’s Active Directory domain name is corp.net. You access servers on the internal network using FQDNs that include the corp.net domain name. You also host servers on the internal network that are accessible to external network users via Web Publishing and Server Publishing Rules. Internal network clients need to access those servers you published, so both internal and external network clients need to access the same servers.
In a "non-split" DNS infrastructure, you have a single DNS zone for corp.net. Resource records for internally and externally accessible servers are included in the same zone. You publish your own DNS servers so that external network clients can access your published servers. The resource records in the corp.net zone might look like this:
corp.net
www A 222.222.222.1
ftp A 222.222.222.1
mail A 222.222.222.3
exchange A 192.168.1.15
webserver A 192.168.1.16
ftpserver A 192.168.1.17
[1] When the external network client wants to access the internal network Web server, it needs to resolve the namewww.corp.net to the IP address on the external interface of the ISA Server that is being used to publish the Web server.
[2] The DNS Server responds with the IP address of the external interface of the ISA Server that’s being used to publish the Web server. The DNS server responds with the IP address 222.222.222.1 for www.corp.net.
[3] The external network clients connects to 222.222.222.1 and accesses the Web server on the internal network.
External network client accessing Published Server
Name resolution and inbound access to the published Web server work fine for the external network client. Unfortunately, the internal network client will use the same path to access the same resource. Because there is a single DNS zone for corp.net, the internal network clients query the same DNS servers as the external network clients.
[1] The internal network client queries the DNS server for www.corp.net
[2] The DNS server returns the IP address on the external interface of the ISA Server to the internal network client. This IP address is the same the external network client received, 222.222.222.1
[3] The internal network client then "loops back" through the external interface of the ISA Server. The internal network client sends the request to the external interface of the ISA Server
[4] The ISA Server forwards the request to the Web server on the internal network.
Internal network client accessing the same published Web server
What happens next depends on the type of ISA Server client the internal network computer happens to be. If the internal network client is a Web Proxy or Firewall client, the request is successful and the client receives a response from the Web server.
If the internal network client is a SecureNAT client, the request will fail because the Web server responds directly to the SecureNAT client and not to the ISA Server. The SecureNAT client isn’t expecting a response from the internal network client directly, since it sent its request to the ISA Server, not directly to the internal network Web server. Because of this, the SecureNAT client will drop the packet sent to it by the Web server. I’ll include more details on this in the ISA Server and Beyond Book.
We could have other problems using the same zone for internal and external network client requests. In the case of the SecureNAT client, the request could fail entirely. But even if you used the Web Proxy or Firewall client, you place extra burden on the ISA Server needlessly. There is no reason to waste processor cycles on the ISA Server computer when internal network clients can access resources on the internal network servers by contacting them directly.
A Split DNS Infrastructure Comes to the Rescue
We can solve these problems by creating a split DNS infrastructure. In the split DNS infrastructure you create twozones for the same domain. One of the zones is used by internal network clients and the other zone is used byexternal network clients .
For example, the zone database on the external zone would look like this:
corp.net
www A 222.222.222.1
ftp A 222.222.222.1
mail A 222.222.222.3
MX mail.corp.net
The zone database on the internal zone would look like this:
corp.net
www CNAME webserver.corp.net
ftp CNAME ftpserver.corp.net
mail CNAME exchange.corp.net
exchange A 192.168.1.15
webserver A 192.168.1.16
ftpserver A 192.168.1.17
When external network clients resolve the name www.corp.net they always get the external IP address of the ISA Server. That’s exactly what you want because that’s how the external network clients access resources on the internal network. It would do external network clients no good at all to receive the private IP address of the server on the internal network.
When internal network clients try to access www.corp.net, they will connect to the server using the internal, private IP address of the server. The CNAME record of "www" resolves to the Host (A) record of webserver.corp.net, and requests are forwarded to 192.168.1.16. All you need to do is make sure the LAT contains the appropriate entries for the internal network, and that the Local Domain Table includes the corp.net domain and that the client configuration at the ISA Server is set so that browsers will directly access resources on the LDT. For more information on Direct Access for browsers, check out the end of the my article on automating client configuration athttp://www.isaserver.org/pages/article.asp?id=983
ISA Server Alert
You must have two DNS servers in order for the split DNS infrastructure to work. You can't create the same zone twice on the same DNS server. The internal zone and the external zones must be located on different DNS servers. You can't do this with a single DNS Server!
You must have two DNS servers in order for the split DNS infrastructure to work. You can't create the same zone twice on the same DNS server. The internal zone and the external zones must be located on different DNS servers. You can't do this with a single DNS Server!
DNS Nirvana: The "Split-Split" DNS Infrastructure
Now let’s take a look at an ideal split DNS setup. In fact, this setup is called a "split-split" DNS. In the diagram below we have a back to back private address DMZ segment. On the DMZ and private network we have:
There are two of each type of server to allow for fault tolerance and load balancing. One of each type will be primary and the other a secondary DNS server. Zone transfers take place between the primary and secondary servers.
The Basic Split-Split DNS Infrastructure
A DNS Advertiser is a DNS server containing zones for domains you have authority over. For example, if you had authority over corp.net, corp.com and mycompany.com, you would put zones for each of these domains on the Advertisers. The advertisers are configured to protect against cache poisoning and they do not perform recursion.
To configure an Advertiser, you need to do the following:
You do not want the Advertisers to perform recursion. The Advertisers provide information for the zones under your administrative control and that have zone databases on the Advertising servers. If a DNS client tries to query for a name that the Advertisers is not authoritative, the Advertiser sends back a "server failure" message. You prevent the most common and most problematic DNS exploits when you disable recursion.
The DNS Resolvers in the DMZ are caching-only DNS servers that act as forwarders for the DNS servers on the internal network. These caching-only DNS servers have no zone databases. They only resolve and cache results of queries that they’ve resolved for the DNS servers on the internal network. Since these machines are not authoritative for any domain, there is no risk of your domains being the subject of DNS hijacking on these machines.
The Internal DNS Servers resolves requests for internal network clients. Remember that the path internal network clients use to access resources should be different for internal network hosts compared to external clients. The differences should be reflected by the differences in the zone databases for the same domain on the Internal DNSservers and the DNS Advertisers.
For example, in your private address DMZ, the DNS advertisers would have the following DNS records:
corp.net
www A 222.222.222.1
ftp A 222.222.222.1
mail A 222.222.222.3
MX mail.corp.net
Note that these are the IP addresses on the external interface of the external ISA Server that are being used to publish the servers on the private address DMZ segment.
The internal DNS servers would have the following DNS resource records for the same resources
corp.net
www A 10.0.0.1
ftp A 10.0.0.2
mail A 10.0.0.2
Notice the internal network clients access the servers on the DMZ by going through the internal ISA Server. The internal network clients use the actual IP address of the servers on the DMZ segment to access them. The internal ISA Server controls outbound access from the internal network, and that includes access from internal network clients to servers on the DMZ. The reason for this is that even though the IP addresses in the DMZ are private addresses, they are not trusted by internal network clients.
Let’s see what happens when an internal network clients makes a query for a DMZ resource.
Internal network client accessing a DMZ resource
[1] The internal network client is configured to send DNS queries to the internal network DNS server. The client sends a request for www.corp.com
[2] The DNS server responds to the request with the IP address of www.corpnet.com, which is the actual IP address of the server on the private address DMZ – 10.0.0.1
[3] The internal network client accesses the Web server on the DMZ segment by going through the ISA Server. The internal ISA Server is configured to allow outbound HTTP requests from internal network clients to the Web server on the private address DMZ segment
Now what happens when an external network client tries to access DMZ server resources?
[1] The external network client queries an Advertising DNS server on the DMZ for www.corp.com.
[2] The DNS Advertiser on the DMZ sends the IP address on the external interface that is being used to publish the Web server on the DMZ.
[3] The external network client accesses the Web server on the DMZ by sending a request to the IP address on the external interface of the ISA Server that’s being used to publish the server. The external ISA Server forwards the request to the server on the DMZ.
Once again you see that the external network client uses a different path to access the same resource on the DMZ segment.
Web and DNS Servers Hosted by ISP or 3rd Party Hosting Service
Another situation commonly seen with smaller networks is when the DNS and the Web servers are hosted by an ISP or hosting service. In this case, the internal network uses the same domain name as the Web site. When you try to access the server on the Internet by going to www.domain.com, the request fails. The reason for this is that the internal network clients query your internal DNS server which is authoritative for the domain.com domain (assuming that you’re using an Active Directory domain). The DNS server on your internal network looks for an entry for www in its zone database for domain.com, it doesn’t find an answer and informs you of this fact.
Another situation commonly seen with smaller networks is when the DNS and the Web servers are hosted by an ISP or hosting service. In this case, the internal network uses the same domain name as the Web site. When you try to access the server on the Internet by going to www.domain.com, the request fails. The reason for this is that the internal network clients query your internal DNS server which is authoritative for the domain.com domain (assuming that you’re using an Active Directory domain). The DNS server on your internal network looks for an entry for www in its zone database for domain.com, it doesn’t find an answer and informs you of this fact.
This is an easy problem to solve. All you need to do is enter resource records for the resources that are hosted externally. For example, if you have a Web server hosted by someone else, just put in a Host (A) entry for www in your domain.com forward lookup zone. Put the actual public address in the Host (A) record. The only limitation this creates is that you can’t host a server by the same name on the internal network. That’s because the name is already taken by the external network server!
Conclusion
A split DNS infrastructure is something you should create whenever you use the same domain name to host resources for both internal and external network clients. You’ve got to do this if you want to optimize access for your internal network clients to avoid is looping back through the external interface of the ISA Server. The split DNS infrastructure prevents internal network clients from looping back through the external interface of the ISA Server and lets them connect directly to the publishing servers on the internal network directly via the server’s private, internal network IP address.
If you’re managing a larger network, especially if you’ve got a back to back DMZ segment with either public or private addresses, then you should consider putting together a "split-split" DNS setup. The is the best arrangement for allowing efficient name resolution for internal and external network clients while at the same time protecting your public DNS servers from being compromised by cache pollution and DNS hijacking exploits. Keep in mind that you don’t have to dedicate servers to DNS. These servers could also be acting as SMTP, Web, NNTP or FTP servers. Unless you have an insanely popular site, DNS queries will not generate a significant amount of traffic and will use little RAM or processor cycles.
No comments:
Post a Comment