How do I check a PTR record?

Solution 1:

If you have Unix or Linux, you can do this by typing this on a command prompt:

dig -x xx.yy.zz.aa

You'll get an answer with your authority of aa.zz.yy.xx.in-addr.arpa and server resolving to this address.

In Windows you can do nslookup xx.yy.zz.aa.

You can also check online at www.intodns.com and input your domain... It will error on the results checking for a reverse zone lookup.

xx.yy.zz.aa = The IP address you're trying to resolve


Update:

When using dig, nslookup, or host it is frequently useful to use a DNS server outside of your control like Google (8.8.8.8) so you get confirmation things are right from a 3rd party. – Zoredache

Zoredache makes a good point. Here are the commands for testing/resolving to external/outside DNS servers:

Dig (testing reverse DNS on Google's DNS server of 8.8.8.8):

dig -x zz.yy.xx.aa @8.8.8.8

Host and Nslookup (testing reverse dns on Google's DNS server of 8.8.8.8)

nslookup zz.yy.xx.aa 8.8.8.8
host zz.yy.xx.aa 8.8.8.8

Solution 2:

I know this has been marked as answered but I want to provide a more comprehensive answer. For my examples I will be using:

  1. google.com's IP address 172.217.3.206 because it does have a PTR record.
  2. serverfault.com's IP address 151.101.1.69 because it does not have a PTR record.

The first thing to note is dig is a multiplatform command, you can get it for Windows on the ISC BIND website listed under BIND, then select your Windows platform (32 or 64 bit). It has many other tools including its own nslookup binary. I don't use that nslookup.exe version, instead I use the default one that comes with Windows (C:\Windows\System32\nslookup.exe). However if you want to use dig you may want to edit your local PATH environment variable, or move the dig tool to your C:\Windows\System32 folder.

Command 1) dig PTR 206.3.217.172.in-addr.arpa - Traditionally this is how a user would perform a reverse DNS lookup. They would manually transpose the IP address: 172.217.3.206 to 206.3.217.172 (notice the order of each of the four octets) and add in-addr.arpa to the end of the string. Here is the output:

; <<>> DiG 9.9.5 <<>> PTR 206.3.217.172.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39790
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;206.3.217.172.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
206.3.217.172.in-addr.arpa. 84300 IN    PTR     sea15s12-in-f206.1e100.net.
206.3.217.172.in-addr.arpa. 84300 IN    PTR     sea15s12-in-f14.1e100.net.
206.3.217.172.in-addr.arpa. 84300 IN    PTR     sea15s12-in-f14.1e100.net.
206.3.217.172.in-addr.arpa. 84300 IN    PTR     sea15s12-in-f206.1e100.net.

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Mar 26 04:20:28 Pacific Daylight Time 2017
;; MSG SIZE  rcvd: 153

Command 2) dig -x 172.217.3.206 - This version of the command is a lot simpler, as described in the dig -h, the -x flag is a "shortcut for reverse lookups". The output is identical to the output shown above in the previous command.

Command 3) dig -x 151.101.1.69 - This example is showing what it looks like when a PTR record is not found, using the serverfault.com example. As you can see, the answer does not list a PTR, and can only find the SOA record of 151.in-addr.arpa:

; <<>> DiG 9.9.5 <<>> -x 151.101.1.69
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21854
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;69.1.101.151.in-addr.arpa.     IN      PTR

;; AUTHORITY SECTION:
151.in-addr.arpa.       1786    IN      SOA     pri.authdns.ripe.net. dns.ripe.net. 1490512027 3600 600 864000 3600

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Mar 26 04:30:38 Pacific Daylight Time 2017
;; MSG SIZE  rcvd: 114

Command 4) nslookup 172.217.3.174 - This is the command suggested by user l0c0b0x in the primary answer on this thread. While it is true that there is a result, it is not clear if this is a PTR record or some other type of record. I think it does by default return a PTR if it is given an IP, but I still want to be sure. It also omits other records if there are multiple PTRs:

Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Name:    sea15s11-in-f14.1e100.net
Address:  172.217.3.174

Command 5) nslookup -debug 172.217.3.174 - Use this command instead to see the full list, including the record type and the full list of results. The -debug flag persists, to turn it off you must use -nodebug:

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        8.8.8.8.in-addr.arpa, type = PTR, class = IN
    ANSWERS:
    ->  8.8.8.8.in-addr.arpa
        name = google-public-dns-a.google.com
        ttl = 86141 (23 hours 55 mins 41 secs)

------------
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 4,  authority records = 0,  additional = 0

    QUESTIONS:
        174.3.217.172.in-addr.arpa, type = PTR, class = IN
    ANSWERS:
    ->  174.3.217.172.in-addr.arpa
        name = sea15s11-in-f14.1e100.net
        ttl = 83026 (23 hours 3 mins 46 secs)
    ->  174.3.217.172.in-addr.arpa
        name = sea15s11-in-f174.1e100.net
        ttl = 83026 (23 hours 3 mins 46 secs)
    ->  174.3.217.172.in-addr.arpa
        name = sea15s11-in-f14.1e100.net
        ttl = 83026 (23 hours 3 mins 46 secs)
    ->  174.3.217.172.in-addr.arpa
        name = sea15s11-in-f174.1e100.net
        ttl = 83026 (23 hours 3 mins 46 secs)

------------
Name:    sea15s11-in-f14.1e100.net
Address:  172.217.3.174

Command 6) nslookup -type=PTR 172.217.3.174 - This version of the command specifies PTR records with the -type flag. It is different than the version without the -type flag in two ways. The first is it lists all PTR answers. The second is that it includes the information "Non-authoritative answer" which the other command neglects to include. If you carefully look above at the debug output, the authority records state 0, so both of these commands should state "Non-authoritative answer".

Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
174.3.217.172.in-addr.arpa      name = sea15s11-in-f14.1e100.net
174.3.217.172.in-addr.arpa      name = sea15s11-in-f14.1e100.net
174.3.217.172.in-addr.arpa      name = sea15s11-in-f174.1e100.net
174.3.217.172.in-addr.arpa      name = sea15s11-in-f174.1e100.net

Command 7) nslookup -debug -d2 -type=PTR 151.101.1.69 - Here is how you would get as much detail as possible about the full reverse lookup request. Reminder: To turn it off use -nodebug and -nod2. This example is purposely failing on the serverfault.com example:

------------
SendRequest(), len 38
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        8.8.8.8.in-addr.arpa, type = PTR, class = IN

------------
------------
Got answer (82 bytes):
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        8.8.8.8.in-addr.arpa, type = PTR, class = IN
    ANSWERS:
    ->  8.8.8.8.in-addr.arpa
        type = PTR, class = IN, dlen = 32
        name = google-public-dns-a.google.com
        ttl = 86280 (23 hours 58 mins)

------------
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

------------
SendRequest(), len 43
    HEADER:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        69.1.101.151.in-addr.arpa, type = PTR, class = IN

------------
------------
Got answer (103 bytes):
    HEADER:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        69.1.101.151.in-addr.arpa, type = PTR, class = IN
    AUTHORITY RECORDS:
    ->  151.in-addr.arpa
        type = SOA, class = IN, dlen = 48
        ttl = 1787 (29 mins 47 secs)
        primary name server = pri.authdns.ripe.net
        responsible mail addr = dns.ripe.net
        serial  = 1490512027
        refresh = 3600 (1 hour)
        retry   = 600 (10 mins)
        expire  = 864000 (10 days)
        default TTL = 3600 (1 hour)

------------
*** google-public-dns-a.google.com can't find 69.1.101.151.in-addr.arpa.: Non-ex
istent domain

Command 8) nslookup 174.3.217.172.in-addr.arpa - You may be wondering if you can use the traditional reverse DNS lookup method with nslookup as we did in Command 1 with dig. You can. Notice the same nslookup failings as I listed above (Command 6) between this command and the one with the -type=PTR flag set below (Command 9):

Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Name:    174.3.217.172.in-addr.arpa

Command 9) nslookup -type=PTR 174.3.217.172.in-addr.arpa - As you may expect, it looks identical to Command 6.

Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
174.3.217.172.in-addr.arpa      name = sea15s11-in-f14.1e100.net
174.3.217.172.in-addr.arpa      name = sea15s11-in-f14.1e100.net
174.3.217.172.in-addr.arpa      name = sea15s11-in-f174.1e100.net
174.3.217.172.in-addr.arpa      name = sea15s11-in-f174.1e100.net