Monday, March 21, 2011

Reverse DNS

I recently had a guy ask me how he could fix a corrupt reverse DNS.

Simple enough, I thought and proceeded to instruct him how to change the AD Integrated DNS zone to a "Standard Primary" DNS zone, then take the DNS file, import it into Excel and manipulate the data however he wanted. He could then just put the file back and reload the DNS zone and that's that.

I also told him how he could use DNSCMD to export the DNS data from an AD Integrated zone.:
dnscmd /ZoneExport FQDN_of_zonename Zone_export_file

He then started telling me he had problems locating the reverse DNS information and it was at this point my techie sense started tingling. He may not even have a reverse DNS zone (it is completely optional, but can be quite useful), or may actually be referring to his DNS resolver cache. (I haven't determined the answer yet).

Reverse DNS operates just like regular DNS, but instead of looking up an IP address using a hostname, you look up the hostname from the IP address. This can be very useful in easily determining which host is the source or destination of traffic, instead of finding the port on the local switch.

Reverse DNS zones use the network address in reverse notation and the suffix So if your network's IP Schema is based on subnets of the private range, you could have a reverse DNS zone of, which could contain entries for all hosts within all subnets on your network. Of course, if you have an extremely large network, you probably want to break this down further, such as, etc.

So, if your host has an (A) record of, he can have a pointer DNS record type (PTR) in the reverse DNS zone of pointing back to its designated hostname of

Reverse DNS zones for IPv6 use the special zone and store their loooong IPv6 addresses as a sequence of nibbles in reverse order in much the same way as the IPv4 addresses are stored in reverse order. So an IPv6 address of 2001:0db8:85a3::62cd will be stored as a PTR record as

A DNS resolver cache on a caching name server will resolve a query, even though they are not authoritative for the result, by making a query to the authoritative server on behalf of the client. The caching name server will then store this record for it's Time-To-Live (TTL) in a local cache. This will result in quicker resolutions and reduced load on Internet name servers. A corrupted resolver cache can simply be cleared and it will rebuild itself with use.