☰

¿Quién es responsable de configurar el DNS inverso (PTR) para un dominio, el host DNS o el host MX?

tag-icon • tag-icon email reverse-dns godaddy ptr-record
¿Quién es responsable de configurar el DNS inverso (PTR) para un dominio, el host DNS o el host MX?

Tengo el dns de un dominio en GoDaddy y el MX configurado para Gmail. Todo está configurado correctamente con spf, dkim y dmarc, y todo pasa todas las pruebas en línea, además: intodns.com informa este error para el dominio y lo marca como grave:

ERROR de registros MX A inversos (PTR): No hay entradas DNS invertidas (PTR). Los registros MX problemáticos son: 27.4.250.142.in-addr.arpa -> no se detectó reversa (PTR) Debe comunicarse con su ISP y pedirle que agregue un registro PTR para sus ips

Hablé con el soporte técnico de gsuite y me dijeron que debería preguntarle a Godaddy. En Godaddy dijeron que no admiten rDNS porque no era necesario. Ahora ¿quién es responsable de configurar esta entrada por mí?

Respuesta1

La delegación DNS para el in-addr.arpa.dominio funciona exactamente igual que para cualquier otro dominio. La única diferencia es: en lugar de registrar un correo electrónico in-addr.arpa., obtienes uno cada vez que se te asigna un grupo de direcciones IP.

El grupo de direcciones 142.250.0.0/15está asignado a Google y sus servidores de nombres tienen autoridad para el dominio 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

Sin embargo, se niegan a responder consultas:

$ 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

Entonces, definitivamente deberías preguntarle a Google por qué no proporcionan PTRregistros para sus servidores (o mejor, se niegan a responder consultas). Quizás simplemente olvidaron agregar la 250.142.in-addr.arpa.zona a sus servidores o alguna otra mala configuración.

información relacionada