An alternative to DNS doctoring

This post will cover a simple, server side method for keep internal DNS requests from resolving to external sources.

Say you run an Exchange box with an internal IP of 192.168.1.5.  You have a static NAT which brings public access to this box for services like SMTP, OWA, Activesync, etc.  The public IP you assign is 120.3.4.5 and you also add a public DNS record of mail.mycompany.com which resolves to this IP.

Externally users have no problems accessing mail.mycompany.com.  But on the flip side, internal access to mail.mycompany.com does not seem to work.

Why doesn't this work?  Internal client machines and your mail server reside on the same private network, are both NAT'd behind the same device, and your router is incapable of accepting traffic that was sent from the same interface.

When an internal client machine makes a DNS request for mail.mycompany.com, this request will get passed on to the authoritative public DNS servers for mycompany.com and the resulting A record will be 120.3.4.5.

As far as I know Cisco has a couple of solutions to this.  DNS doctoring which will re-write client's request for the A record for mail.mycompany.com and return the private IP address of 120.3.4.5.  Or hairpinning which is the process where traffic sent back out the same interface on which it arrived.

The suggested alternative to this problem does not involve reconfiguration of your router.  In fact, it is designed catch the client's DNS request on the private network and never let it get out.

So this made up company's internal domain is mycompany.local.  I've seem some people make the mistake of naming their internal Windows domain the same as their public domain but let's not get into that.  By default, you domain controller will be authoritative for DNS zone mycompany.local.  It is here that we will create a new zone for mail.mycompany.com.  It is important to not create the zone for just mycompany.com because this will result in all DNS requests for mycompany.com getting stuck within your internal network.  By making this zone 3 levels deep, you ensure that ONLY requests for mail.mycompany.com stay internal.  Once you create this zone, add an A record that resolves to the root of this domain to the private address of your exchange server 192.168.1.5.



Run a quick nslookup or ping test to confirm and you are done!

Decomission of public/external DNS servers

I came upon a situation where I needed to retire a couple of external DNS servers without having any type of access to update WHOIS information for every domain it hosts.  This post will cover setting up the source BIND DNS server to allow zone transfers to a MS DNS server where we will later convert to a primary zone that feeds additional secondary zones running on PowerDNS as a supermaster.  Lastly, the retired DNS hostnames will be updated with IP addresses of the target hosts.


Configure source server to allow zone transfers to target MS DNS.  (In my case I had to set this per zone)
 
Enter the IP address of the target server here.  Even though it says "from" it seems that it works when transferring "to".

On the target server configure a new secondary DNS zone.


Enter the IP address of the master or source DNS server.

Hit Finish

Next, verify your newly created secondary zone pulled all DNS records from the master/primary server.

Once all records have been verified, the newly created secondary zone can be changed to primary the zone properties page.



Update the Name Servers, SOA, and Zone Transfers tab accordingly.

At this point, one issue that we noticed that changes and newly created records were not being updated from the new primary/master server to its downline secondary/slave servers.  In order to fix this problem, the zone serial number needed to be incremented under the SOA tab.

Lastly, once the newly created zones were tested the SOA, NS, and A records for the old servers were updated to reflect the hostnames and IP addresses of the new ones.