I spend a lot of time talking about DNS issues on this site. One of the core competencies that any network engineer needs to master is DNS, since name resolution is critical for almost all network connected devices and applications. You need to have a good grounding in DNS basics to troubleshooting many networking and connectivity related problems.
There are two core concepts that you should master as an ISA Firewall admin. The first is that of the split DNS. This topic is widely misunderstood and has slowed the adoption of robust and highly functional split DNS infrastructures. For detailed information on what a split DNS is, what it does, and why you need to implement a split DNS, please see the following articles:
http://www.windowsecurity.com/articles/Split-DNS-Small-Business-Remote-Access-Connections.html
http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html
http://www.isaserver.org/tutorials/2004illegaltldsplitdns.html
The key DNS concept you need to master is separation of DNS operations. This is important because a well designed, secure infrastructure has at its core an implementation of least privilege. Least privilege is the reason why we create multiple perimeters for multiple security zones. Users and applications should never be able to access protocols and services that they don’t need in order to carry out business operations.
Tim Mullen (Thor) from www.hammerofgod.com provides an excellent treatise on this subject:
“I’ve found that many people seem to dance over the security ramifications of DNS/forwarders when designing an infrastructure. I had some off-list conversations about this, and thought that it may be valuable to fully flesh-out what I think the issues are and how to avoid them. Now’s also probably a good time to share my “trick” regarding publicly available DNS and minimizing service exposure. So, for the benefit of those who are interested:
When AD DNS is configured as a forwarder, all domain members using that DNS server will be able to resolve hostnames directly from their IP stack. There is no operational reason to have this– when one considers that most spyware/malware/trojans/backdoors/shells/etc typically depend on hostname lookups for direct access to a resource, the capability of a client box to
perform direct host lookups outside your network should (to me) be considered unwanted and un-needed. Personally, I qualify it as “dangerous.”
That’s why I always configure my AD DNS with a root (.) zone- that way, only local zones may be queried by the client’s stack. I typically only use web proxy clients for HTTP(S)/FTP where all DNS is proxied by the ISA box. If one needs direct DNS for another application (say DOS FTP) then use the FWC and all DNS will be resolved over the control channel, still being proxied by the ISA server.
The ISA server itself will have whatever “public” DNS server configured in its stack so that it can do the resolution for the clients.
Not only is direct client DNS “dangerous,” but having an AD box set up as a forwarder is “dangerous” as well as the box must be configured to access a remote resource over TCP/UDP 53. This also means that you’ve opened that box up for incoming traffic on TCP/UDP 53 as well. Having static paths into your internal network from source port routing is crazy. I can push anything I want over 53, not just DNS (and have ;). Remember, the DNS filter is only for published DNS servers, not clients requesting DNS lookups.
But there is the issue of one wanting complete control over host names and the need to publish your own DNS. This is what the DMZ is for. The DMZ box is set as a forwarding server, and the internal ISA box is set to use that box for all DNS requests. In this way, only the ISA box itself need to request DNS outside the internal network, and it is already protected. In this manner, there is no DNS leaving the internal network at all, and no static ports into the internal network– only the ISA box looking up DNS, and only to that DMZ resource. The DNS server in the DMZ is protected by the border ISA box, which (where necessary) is publishing DNS to the DMZ for remote hosts to look up your domain information. And here the DNS filter is used.
But you can get even better than that– you can actually be fully in control of your own zone data without having to actually publish your DNS to the world if you have a decent ISP.
Here’s what I do for that– I have DMZ DNS servers set up as primary DNS zones, and have told my ISP to set up their servers as secondary zones for my domains. The DMZ box can only zone transfer to the IP’s of my ISP’s DNS servers. Additionally the DMZ box is set to forward to my ISP’s cache servers. So, at this point, all internal AD DNS is stopped at the controller, and only the ISA box can resolve DNS and only to the DMZ DNS server. My internal Exchange clusters’ stack resolves to the AD controller, and they smart host deliver mail to my DMZ GFI gateway, so still no DNS leaving. The GFI box in the DMZ uses the DMZ DNS.
The trick is that though I’m primary DNS, and though any changes I make to my DNS hosts are immediately replicated to my ISP as secondary DNS, I’ve registered my DNS with the domain registry as my *ISP* being primary. So the world resolves my host names via my *ISP’s* DNS servers, not *mine*. I don’t even have to publish DNS at all.
The end result is that no DNS requests leave my internal network at all, except for a single DNS box in the DMZ that can only resolve to the ISP DNS caches. There is no publishing at all, no internal paths, no vulns, nothing at all since the world resolves to the ISP boxes yet I have full control over all host name entries.
It’s a pretty tight config.”
HTH,
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
Email: [email protected]
MVP — Microsoft Firewalls (ISA)