Quem é responsável por configurar o DNS reverso (PTR) para um domínio, o host DNS ou o host MX?

Quem é responsável por configurar o DNS reverso (PTR) para um domínio, o host DNS ou o host MX?

Tenho o DNS de um domínio no GoDaddy e o MX configurado para Gmail. Tudo configurado ok com spf, dkim e dmarc, e tudo passa em todos os testes online, ao lado: intodns.com relata este erro para o domínio e o marca como grave:

ERRO de registros MX A reverso (PTR): Nenhuma entrada de DNS reverso (PTR). Os registros MX problemáticos são: 27.4.250.142.in-addr.arpa -> nenhum reverso (PTR) detectado Você deve entrar em contato com seu ISP e pedir-lhe para adicionar um registro PTR para seus ips

Falei com o suporte técnico do gsuite e eles disseram que eu deveria perguntar ao Godaddy. Na Godaddy eles disseram que não suportam rDNS porque não era necessário. Agora, quem é responsável por configurar esta entrada para mim?

Responder1

A delegação DNS para o in-addr.arpa.domínio funciona exatamente da mesma forma que para qualquer outro domínio. A única diferença é: em vez de registrar um in-addr.arpa., você recebe um sempre que recebe um pool de endereços IP.

O pool de endereços 142.250.0.0/15é atribuído ao Google e seus servidores de nomes têm autoridade para o domínio 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

No entanto, eles se recusam a responder perguntas:

$ 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

Então, você definitivamente deveria perguntar ao Google por que eles não fornecem PTRregistros para seus servidores (ou melhor, eles se recusam a responder a perguntas). Talvez eles simplesmente tenham esquecido de adicionar a 250.142.in-addr.arpa.zona aos seus servidores ou alguma outra configuração incorreta.

informação relacionada