☰

Wer ist für die Einrichtung von Reverse-DNS (PTR) für eine Domäne verantwortlich, der DNS-Host oder der MX-Host?

tag-icon • tag-icon email reverse-dns godaddy ptr-record
Wer ist für die Einrichtung von Reverse-DNS (PTR) für eine Domäne verantwortlich, der DNS-Host oder der MX-Host?

Ich habe den DNS für eine Domain bei GoDaddy und den MX für Gmail konfiguriert. Alles ist mit SPF, DKIM und DMARC ok eingerichtet und besteht alle Online-Tests. Außerdem meldet intodns.com diesen Fehler für die Domain und markiert ihn als schwerwiegend:

Reverse MX A-Einträge (PTR) FEHLER: Keine Reverse DNS (PTR)-Einträge. Die problematischen MX-Einträge sind: 27.4.250.142.in-addr.arpa -> kein Reverse (PTR) erkannt Sie sollten Ihren ISP kontaktieren und ihn bitten, einen PTR-Eintrag für Ihre IPs hinzuzufügen

Ich habe mit dem technischen Support von GSuite gesprochen und sie sagten, ich solle Godaddy fragen. Bei Godaddy sagten sie, sie unterstützen rDNS nicht, da es nicht erforderlich sei. Wer ist nun dafür verantwortlich, diesen Eintrag für mich einzurichten?

Antwort1

Die DNS-Delegation für die in-addr.arpa.Domäne funktioniert genauso wie für jede andere Domäne. Der einzige Unterschied besteht darin, dass Sie keine Domäne registrieren müssen in-addr.arpa., sondern immer dann eine Domäne erhalten, wenn Ihnen ein IP-Adresspool zugewiesen wird.

Der Adresspool 142.250.0.0/15ist Google zugeordnet und deren Nameserver sind für die Domain maßgebend 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

Sie weigern sich jedoch, Anfragen zu beantworten:

$ 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

Sie sollten Google also unbedingt fragen, warum sie keine PTRDatensätze für ihre Server bereitstellen (oder besser noch, sie weigern sich, Anfragen zu beantworten). Vielleicht haben sie einfach vergessen, die Zone zu ihren Servern hinzuzufügen, 250.142.in-addr.arpa.oder es liegt eine andere Fehlkonfiguration vor.

verwandte Informationen