Archive for November, 2009

Recently one of my customers moved their office location and in the process moved their Internet connectivity to a T-1. Their provider, Qwest Communications, assigned them a /27 subnet to go along with it and offered to delegate reverse DNS to them. Sounds great, right? Well, there is a problem here; my customer is a Microsoft shop using Windows 2008 for all their public DNS and Windows 2008 DNS does not gracefully handle reverse DNS for classless subnets. This resulted in my customer lacking reverse DNS for their Exchange environment; Since a number of hosts will not accept inbound mail from an IP without reverse DNS this was causing some issues with mail delivery and very much affecting their business.

I eventually tracked down the source of the problem to the method used by Qwest, delegating out a small portion of the classful zone to my customer’s name servers and entering CNAMEs for all the individual IPs. This is not an uncommon solution and when using anything but Windows DNS it is quite easy to accommodate.

Let me lay out the basic scenario I encountered first and then I’ll tell you how to solve this problem.

Note: All IPs and domain names have been changed to protect the innocent.

Public IPs assigned to my customer: 192.168.0.192 – 192.168.0.223

Name servers my customer uses: ns1.customer.com & ns2.customer.com

Public IP that my customer’s Exchange environment uses for outbound mail: 192.168.0.194

What was happening here was that when Qwest delegated rDNS for 192.168.0.194, they told remote servers they should be looking for 194.192-223.0.168.192.in-addr.arpa. The initial and obvious solution is to simply create a reverse DNS zone in Windows DNS for 192-223.0.168.192.in-addr.arpa and create PTR records, right? Not so fast there… You can create the reverse zone easily but you can’t create PTR records in the correct format unfortunately.

Hence the quite simple solution: dnscmd

After you’ve created the zone, simply launch an elevated command prompt (Start -> Right Click on Command Prompt -> Run As Administrator) and use the following syntax to add PTR records manually.

dnscmd <dns server> /recordadd <full zone name – 192-223.0.168.192.in-addr.arpa as an example> <last octet of IP – e.g. 194 for 192.168.0.194> 10 PTR <appropriate fqdn>

So in my customer’s case I used the below command to create a PTR entry for mail.customer.com located at 192.168.0.194:

dnscmd custns1 /recordadd 192-223.0.168.192.in-addr.arpa 194 10 PTR mail.customer.com.

You should then be good to go!