To check that a given host has the reverse DNS setup correctly, you could:
host -t ptr 126.96.36.199
188.8.131.52.in-addr.arpa domain name pointer ww-in-f99.1e100.net.
or to do the same thing with dig:
dig -x 184.108.40.206
; <<>> DiG 9.6-ESV-R3 <<>> -x 220.127.116.11
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41932
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;18.104.22.168.in-addr.arpa. IN PTR
;; ANSWER SECTION:
22.214.171.124.in-addr.arpa. 79482 IN PTR ww-in-f99.1e100.net.
;; Query time: 1 msec
;; SERVER: 126.96.36.199#53(188.8.131.52)
;; WHEN: Wed May 11 12:36:25 2011
;; MSG SIZE rcvd: 77
Do not specify any server to query, and it'll do it via your host's resolver, and prove that
things are working across the 'net
You can try using a remote DNS server to check the reverse lookup. You can do this by
providing the hostname or IP address of a DNS server to your query using nslookup or host.
bigwig:~ jimh$ host 184.108.40.206 220.127.116.11
Using domain server:
18.104.22.168 is a Google DNS server that allows recursive lookups that often comes in useful. It
is handy to check if your DNS record has propagated.
You can also use:
dig -x +trace +all 22.214.171.124
and this will take you through, step-by-step, the queries that are made as it contacts the
root DNS servers downwards and the replies you receive. If there are issues, you can use this
to find out at which point you went astray.
Dig can be really verbose and helps check if it's a live result and not cached. Note that the
/24 IP range is written backwards in essence for the in-addr.arpa notation
dig +multiline @PRI.AUTHDNS.RIPE.NET 123.123.123.in-addr.arpa NS
So if your example range was: 123.456.789.0/24 then the
in-addr.arpa notation would be 789.456.123.in-addr.arpa above.
I'm not sure about a list of NSs with RIPE but the one above seems correct,