I need to check a PTR record to make sure that a script I have is sending emails which will actually be received by my users and not be incorrectly marked as spam.
I understand that the ISP which owns the IP range has to set up the PTR record, but how do I check if it is already set up?
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
I know this has been marked as answered but I want to provide a more comprehensive answer. For my examples I will be using:
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
It is the same as doing any kind of DNS lookup.
From a windows command prompt: nslookup.exe <ip address>
From a linux command line: host <ip address>
Note: It is probably best to run these commands from a computer outside of your network, so that you are accessing a public DNS server. Alternatively, both nslookup and host offer ways to specify the DNS server to use.
(2) examples, one for IPv4 and the other for IPv6.
The IPv6 PTR lookup procedure took me ages to find an answer to...
We'll use Google's IP for the IPv4 example:
host -t PTR 209.85.218.49
Returns the reverse mapping:
49.218.85.209.in-addr.arpa domain name pointer mail-ej1-f49.google.com.
STEP 1: Obtain the IPv6 address of the host (usually a mailserver):
host -t AAAA mail.yourServer.net
This returns the IPv6 address we need for the PTR lookup in the next step:
mail.yourServer.net has IPv6 address 2001:340:1c1e:14::2
STEP 2:Now supply the IPv6 address to the host command:
host -t PTR 2001:340:1c1e:14::2
Returns the IPv6 PTR record:
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.1.0.0.e.1.c.1.0.4.3.0.1.0.0.2.ip6.arpa domain name pointer mail.yourServer.net.
NOTE: the IPv6 address has been anonymized.
Since Hurricane Electric gave me the FREE IPv6 block, I set the reverse IPv6 DNS directly in their DNS control panel for mailserver.
Obviously, the above IPv6 PTR record is a bit crazy and being lazy, I just used a reverse IPv6 Generator to create it for my mailserver. There are others, but I used the following to derive the correct value for the reverse IPv6:
For the IP V4 example on 1.1.1.1 you can try these on Linux to get the name from the IP.
dig -x 1.1.1.1
Or
nslookup 1.1.1.1
Or
host -t PTR 1.1.1.1
