System Administration & Network Administration
email reverse-dns godaddy ptr-record
Updated Fri, 26 Aug 2022 13:25:01 GMT

Who is responsible to set up reverse DNS (PTR) for a domain, the DNS host or the MX host?


I have the dns for a domain on GoDaddy and the MX configured for Gmail. All set up ok with spf, dkim and dmarc, and all passes all online tests, beside: intodns.com reports this error for the domain and marks it as severe:

Reverse MX A records (PTR) ERROR: No reverse DNS (PTR) entries. The problem MX records are: 27.4.250.142.in-addr.arpa -> no reverse (PTR) detected You should contact your ISP and ask him to add a PTR record for your ips

I have talked to gsuite tech support and they said I should ask Godaddy. At Godaddy they said they don't support rDNS as it was not required. Now who is responsible to set up this entry for me?




Solution

The DNS delegation for the in-addr.arpa. domain works exactly the same way as for any other domain. The only difference is: instead of registering an in-addr.arpa., you get one whenever you are assigned an IP address pool.

The address pool 142.250.0.0/15 is assigned to Google and their name servers are authoritative for the domain 142.250.in-addr.arpa.:

$ dig @x.arin.net. 27.4.250.142.in-addr.arpa. PTR +norecurse
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @x.arin.net. 27.4.250.142.in-addr.arpa. PTR +norecurse
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6403
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: fea615f1769369c875faa8fe5e1e28450e879031f36ee506 (good)
;; QUESTION SECTION:
;27.4.250.142.in-addr.arpa. IN  PTR
;; AUTHORITY SECTION:
250.142.in-addr.arpa.   86400   IN  NS  ns3.google.com.
250.142.in-addr.arpa.   86400   IN  NS  ns1.google.com.
250.142.in-addr.arpa.   86400   IN  NS  ns4.google.com.
250.142.in-addr.arpa.   86400   IN  NS  ns2.google.com.
;; Query time: 151 msec
;; SERVER: 2001:500:31::63#53(2001:500:31::63)
;; WHEN: wto sty 14 21:44:53 CET 2020
;; MSG SIZE  rcvd: 164

However they refuse to answer queries:

$ dig @ns1.google.com. 27.4.250.142.in-addr.arpa. PTR +norecurse
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @ns1.google.com. 27.4.250.142.in-addr.arpa. PTR +norecurse
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 48561
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;27.4.250.142.in-addr.arpa. IN  PTR
;; Query time: 5 msec
;; SERVER: 2001:4860:4802:32::a#53(2001:4860:4802:32::a)
;; WHEN: wto sty 14 21:46:57 CET 2020
;; MSG SIZE  rcvd: 54

So, you definitively should ask Google, why they don't provide PTR records for their servers (or better they refuse to answer queries). Maybe they just forgot to add the 250.142.in-addr.arpa. zone to their servers or some other misconfiguration.





Comments (5)

  • +1 – Great answer, thank you. I am still trying to discuss this with Google tech support and now I have passed them your answer. First level concluded that 27.4.250.142.in-addr.arpa corresponds to the host 27.4.250.142 in India and I should contact them (lmao). 2nd level refused to check with "3rd party tools" (mxtoolbox, intodns) and suggested to use their toolbox.googleapps.com to confirm that everything is set up ok. But that tool doesn't even test for rDNS. Obv. not much rDNS competence @ google. — Jan 17, 2020 at 11:31  
  • +1 – In an SMTP session the callee is not a suspect, the caller is (may be a potential spammer). Therefore the lack of rDNS on Google's MX servers is not a problem, unless they use the same servers to send e-mail (probably the don't). If they did SpamAssassin would complain. — Jan 17, 2020 at 12:21  
  • +0 – Piotr thanks for the very complete answer. I have the same issue. Do you believe this issue is creating problems in real life, e.g., increased spam? Or is it an alert that can be ignored? Many thanks — Feb 16, 2021 at 10:03  
  • +1 – @mbloch: If a reverse lookup for your IP does not return your fully qualified domain name, there is an increased chance the e-mails you send will be considered spam. — Feb 16, 2021 at 21:22  
  • +0 – @PiotrP.Karwasz thanks ! Not sure how easy it will be to "fix Google" but will try — Feb 17, 2021 at 05:11