Feb 112010
 

Here is a short how-to for PTR/RDNS
1. You must have reverse authority delegated to you from your hosting provider. Though common wisdom in forums says most providers do not delegate authority, I have found this to be untrue. I don’t recommend asking for it if you don’t feel confident you can handle the technical end of setting up BIND.
2. You need to have a domain of course, or a few and it helps greatly to have DNS setup and working for a few days prior to attempting this.
3. Every install of cPanel I have done to date comes with a broken BIND server. The issue is always the rndc.key issue. This is my first task for every cPanel install now to do the following fix before I add any information in cPanel WHM at all. To fix it, open /etc/rndc.conf in a text editor and at the top you should see this:

# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "XXXXXXXXXXXXXXX==";
};

options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;

change all the references of “rndc-key” to “rndc.key”.

4. Now open /etc/named.conf and at the top change the rndc-key reference to rndc.key also.
5. in SSH type “rndc reload”
6. in SSH type /scripts/fixndc (try it twice, some people need to but I usually get a message telling me further uses of the script are not needed).
7. It doesn’t hurt to go into cPanel WHM and restart BIND at this point. You should get a clean restart with no connection or rndc error.

Now the real fun begins. There’s a lot of really good technical information to be found in the process of setting up RDNS that helps one gain an understanding of how the DNS process works as a whole.

The current version of BIND for Redhat/CentOS and cPanel uses a database system for the zone files and named.conf entries. It’s basically a two part process. BIND looks at /etc/named.conf for a list of zone entries which tell it what domains your server is responsible for. These entries tell BIND to go look in /var/named/ for zone.db files which contain the actual DNS information such as IP Address, MX records and soon, Reverse (PTR) records.

Reverse DNS is just that, its REVERSE. The server performing the RDNS lookup traces your IP address backwards in order to get to your servers DNS files and pull the PTR entry.
Part1 : Adding the reverse lookup zones

For sake of example, were going to use the IP range 10.1.2.1 thru 10.1.2.4. To make it easy, were going to assign PTR for the domains punk.rocks.org (10.1.2.1) and icecream.ischill.org (10.1.2.2).

First open /etc/named.conf in pico or nano, etc and go down to the bottom of the page. We need to add the “in-addr.arpa” entries for our IP range. Your going to reverse the IP address and leave off the last digit, so our record would be for 2.1.10 instead of 10.1.2.# . The record should llok like this:

};

zone "2.1.10.in-addr.arpa" IN {
type master;
file "/var/named/2.1.10.db";
allow-update { none; };
};

Be sure you have that }; separating your entries. This entry tells the lookup computer that IPs starting with 10.1.2. might belong to us and to go look at the file /var/named/2.1.10.db to get specifics.

That’s it for named.conf. If you own other address ranges you would want to add a separate entry for each of them too and point them each to their own ip block .db file.

Now we need to create a 2.1.10.db file in /var/named and edit it. I prefer to make a copy of another zone.db file and edit it locally using vim. It’s a normal DNS zone file except where you would have full IP address you only put the last digit of the IP.

; Modified by Web Host Manager
; Zone File for 2.1.10
$TTL 86400
@ 14440 IN SOA ns1.rocks.org. root.rocks.org. (
1997022703
28800
14400
3600000
86400
)
14400 IN NS ns1.rocks.org.
14400 IN NS ns2.rocks.org.

1 IN PTR punk.rocks.org.
2 IN PTR icecream.ischill.org.
3 IN PTR res.rocks.org.
4 IN PTR res.ischill.org.

That’s basically it. Your telling the lookup host that ip 10.1.2.1 reverses to punk.rocks.org and that 10.1.2.2 reverses to icecream.ischill.org . In this example ips 3 and 4 aren’t being used yet so I add res to indicate reserved for future domains. You can also leave them out of the .db file but I put them in for testing. Also note the periods after the domain names, they have to be there or it will not work.
I left the default values for TTL, refresh etc, a test on some of the online DNS diagnostic tools indicates these can be improved upon greatly.

Once that’s all complete go to SSH and type rndc reload. If your domains have already propagated you can use an online DNS tool to check your IPs for reverse entry. It usually works very fast for me, changes showing up instantly. A good place to use is: http://www.dnsstuff.com/
You can check you local DNS server by using the dig command in SSH.

Commands: dig your.domain.com and dig –x 10.1.2.1 you should get back lots of useful information, what you don’t want to see is “servfail”. This indicates the DNS server responsible is not responding.

 Posted by at 3:37 am

 Leave a Reply