DNS Doctoring is a very useful tool, if your firewall supports it. It does pretty much what the title says, it “doctors” the responses of DNS. I use it alot in my existing infrastructure using my Cisco ASA firewalls. Recently, we are migrating away from Cisco ASA, and I needed to know how to preform DNS Doctoring on Juniper SRX’s. Google to the rescue.
While Juniper does an ‘ok’ job documenting this, in my searches, I ran across this blog post from Bart Jansens, where he gave his opinions about DNS Doctoring on a Juniper SRX. The author made this comment, which I do not necessarily agree with:
This behavior is wrong in so many ways. There is very little documentation about this – as far as I know this behavior gets triggered when both the DNS server and the response have a static NAT rule, but I may be wrong. If you think you need functionality like this, you should rethink your DNS infrastructure.
The statement “if you need this functionality, you should rethink your DNS” is a bit broad and a little presumptuous. I partially agree with this statement, but not fully.
First, let me explain the need for DNS Doctoring. Let’s say you have a web server in your DMZ at 10.20.30.44 which is hosting the website www.company.com. Also, let’s assume you do NOT have a zone in your internal DNS servers for company.com.
The process for accessing this website is to ask DNS for www.company.com. Your internal DNS servers do not have the zone, so they use their forwarders to ask (usually a provider-based DNS). They will query the internet to see who is authoritative (provided the record is not cached) and return the public IP of the server. At this point, everything is working as it should.
The problem comes from the fact that you now have a public IP to access the server, but since you are behind the “outside” or “public” interface that the server is NAT’d to, you have no access to 188.8.131.52. You need to access 10.20.30.44, not 184.108.40.206. Now, you may be saying, “Well, just create a zone on your internal DNS to point to 10.20.30.44″, and you’d be exactly right. However, that solution is problematic. Now, you have to remember to update BOTH zones if additions, changes, or deletions are ever made. And if you forget one, some communications will stop.
Enter DNS Doctoring. This is where the firewall will inspect the DNS Response and check it’s NAT tables to see if it has an entry. If it does, it will re-write the response with the “real” address before sending to the client. As far as the client is concerned, the DNS server magically knew the private IP.
Now, to Bart’s point…. this is a hack. But, it’s an efficient hack. You now only need to update the external zones once, and everything just works. Now, would you use this in your line-of-business critical applications? Maybe not. It’s another point of failure. But, you should determine the risk. The way I use it, is for what marketing calls “micro-sites”. These are small sites that are created to support or track marketing campaigns, and build SEO. Because it’s not a business app, we don’t create zones internally (we can have 100+ sites at any given time). Just create the external DNS zone, add the A-record, and perform DNS Doctoring. Now, internal AND external users can access it.
In Bart’s post, he also says it will break DNSSec. And he’s right there too. This will, most definitely, break it, because the digital signature in the response packet has changed (it came from the firewall, not the originating DNS server). However, because you aren’t using it for critical business processes, it should not be a problem.
In conclusion, DNS Doctoring is a time saver and simplifies the process. However, use it for the right circumstance. It’s not always the best tool, but it’s a great tool in some situations.