Just some terminology adjustments here. Reverse DNS isn't setup on your server. Your server is assigned IP addresses and those IP addresses have reverse DNS entries. Those IPs are completely independent of your server.
Get the IP address of your server
$ ip addr show
now check to see if you can resolve it
$ host 1.2.3.4
where 1.2.3.4 is your IP
e.g.
$ host 74.125.67.100
100.67.125.74.in-addr.arpa domain name pointer gw-in-f100.1e100.net.
This obviously uses your local nameservers and there is always the possibility that you have records cached if you've previously looked it up and it wasn't there. This is a good method to check whether your provider has setup the rDNS properly for you:
Reverse DNS works by reversing each of the octets of the IP address and using the in-addr.arpa domain. Using the IP I've used above (74.125.67.100) as an example, 74 is the first octet, 125 is the second octet etc.
So in reversing it we get 100.67.125.74 ... now add on in-addr.arpa to the end to get the PTR record for that IP
i.e.
100.67.125.74.in-addr.arpa ptr
dig is the canonical tool for debugging DNS, so to find out where the nameservers are for this class, you need to keep stripping off octets to find them.
(Advance warning) - Specifics may be OS-dependent.
Anyway, forward DNS is used to translate a name to an IP address. Reverse DNS is used to translate an IP address to a name.
One obvious way is to use nslookup (or equivalent) on a known IP address. E.g. nslookup 10.0.0.31 should return the hostname of that machine.
Note however that all you have confirmed is that reverse DNS is configured in some shape or form that at least gives the appearance of correctness for the IP address you have just tested. You have no way of knowing that the same applies to all other hosts on your network, short of testing them all individually.
Bottom line is that you're going to have to go into the DNS management tool relating to your OS and flavour of DNS, and check that everything is as it should be in accordance with the documentation (assuming that the documentation is correct and complete).
Just some terminology adjustments here. Reverse DNS isn't setup on your server. Your server is assigned IP addresses and those IP addresses have reverse DNS entries. Those IPs are completely independent of your server.
Get the IP address of your server
now check to see if you can resolve it
where 1.2.3.4 is your IP e.g.
This obviously uses your local nameservers and there is always the possibility that you have records cached if you've previously looked it up and it wasn't there. This is a good method to check whether your provider has setup the rDNS properly for you:
Reverse DNS works by reversing each of the octets of the IP address and using the in-addr.arpa domain. Using the IP I've used above (74.125.67.100) as an example, 74 is the first octet, 125 is the second octet etc.
So in reversing it we get 100.67.125.74 ... now add on in-addr.arpa to the end to get the PTR record for that IP
i.e.
dig is the canonical tool for debugging DNS, so to find out where the nameservers are for this class, you need to keep stripping off octets to find them.
e.g.
Right, we have a match. That means ns{1,2,3,4}.google.com handle the reverse records for all IPs 74.125.x.x
So, to query against their nameservers directly, we use:
On windows (or other platforms with nslookup) do this
This will return the reverse DNS (PTR) record for your IP address, if it exists.
For example:
See Reverse DNS Lookup at http://www.dnsgoodies.com/
(Advance warning) - Specifics may be OS-dependent.
Anyway, forward DNS is used to translate a name to an IP address. Reverse DNS is used to translate an IP address to a name.
One obvious way is to use nslookup (or equivalent) on a known IP address. E.g.
nslookup 10.0.0.31
should return the hostname of that machine.Note however that all you have confirmed is that reverse DNS is configured in some shape or form that at least gives the appearance of correctness for the IP address you have just tested. You have no way of knowing that the same applies to all other hosts on your network, short of testing them all individually.
Bottom line is that you're going to have to go into the DNS management tool relating to your OS and flavour of DNS, and check that everything is as it should be in accordance with the documentation (assuming that the documentation is correct and complete).