Frage Hat mein ISP meinen DNS-Reverse-Lookup-Datensatz für eine einzelne statische IP-Adresse verändert?


Ich habe die Aufgabe übernommen, einen kleinen E-Mail-Server zu betreiben, und die Welt des Spams macht es für eine Person schwieriger, da viele MTAs sehr paranoid sind, E-Mails zu akzeptieren.

Ich denke, ich habe fast alles konfiguriert, was ein Problem erfolgreich sein könnte: Ein kommerzielles SSL-Zertifikat, DKIM, eine richtige Domäne und statische IP-Adresse. Meine (piddly) E-Mail geht fast immer aus. Aber die meisten paranoiden MTAs lehnen immer noch meine E-Mails ab - Craigslist zum Beispiel - und es scheint meine umgekehrte Suche nach Fehlern zu sein.

Ich habe kürzlich meine statische IP-Adresse und meinen Dienst bei meinem ISP geändert. Als sie es änderten, versuchte ich, das richtig zu konfigurieren, aber ich fürchte, dass es nicht ist. Aber ich bin nicht 100% sicher, was falsch ist oder wie meine umgekehrte Aufzeichnung aussehen soll.

Ich möchte vor allem nicht meinen ISP mit einem "Schau, ich weiß nicht, was das Problem ist, aber Sie müssen es irgendwie beheben" Haltung an. Wenn es ein Problem gibt, möchte ich genau beschreiben können, was es ist, bevor ich mit dem NOC telefoniere. Soweit ich das beurteilen kann, bieten sie dafür kein Kontrollpanel an, also möchte ich mit ein paar Versuchen nicht die Geduld eines anderen versuchen.

OK, die Details, redigiert und fiktiv, aber konsistent:

Domain:                      funkeedomain.org
Mailserver (DNS MX record):  mx.funkeedomain.org
Static IP address:           111.222.333.444
Static IP address reversed:  444.333.222.111
FQDN originally requested of the ISP for reverse lookups: main.funkeedomain.org

Hier ist eine typische Ablehnungsbenachrichtigung von meinem Mailserver (hMailServer):

Your message did not reach some or all of the intended recipients.

   Sent: Thu, 12 Jan 2017 11:53:50 -0800 (PST)
   Subject: Blah blah blah

The following recipient(s) could not be reached:

2125551111@tmomail.net
   Error Type: SMTP
   Remote server (64.235.154.109) issued an error.
   hMailServer sent: .
   Remote server replied: 550 permanent failure for one or more recipients (2125551111@tmomail.net:550 Sender IP reverse lookup rejected)

hMailServer

Ein kommerzieller E-Mail-sendender Checker sagt mir:

main.funkeedomain.org.333.222.111.in-addr.arpa          Failed - No A Record Found in DNS

Also gut. Was sagen mir DNS-Tools?

stew@griffin:~$ host 111.222.333.444
444.333.222.111.in-addr.arpa domain name pointer main.funkeedomain.org.333.222.111.in-addr.arpa.

stew@griffin:~$ dig -x 111.222.333.444
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -x 111.222.333.444
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16150
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;444.333.222.111.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
444.333.222.111.in-addr.arpa. 86365 IN   PTR     main.funkeedomain.org.333.222.111.in-addr.arpa.

;; Query time: 0 msec
;; SERVER: 10.0.0.4#53(10.0.0.4)
;; WHEN: Thu Jan 12 19:09:11 PST 2017
;; MSG SIZE  rcvd: 93

Aus Lesebeispielen (http://www.gettingemaildelivered.com/how-to-set-up-reverse-dns-rdns zum Beispiel), mein starker Eindruck ist, dass dies falsch ist, und meine umgekehrte Aufzeichnung von meinem ISP sollte ein PTR zu "main.funkeedomain.org" sein, NICHT "main.funkeedomain.org.333.222.111.in-addr .arpa. "

Habe ich recht, das zu denken? Was sollte ich in meiner umgekehrten Akte erwarten, wenn nicht was ich finde?


Danke an alle, die geantwortet haben, und an meinen Post-Post-Grammatik-Texteditor.

Sowohl die Antworten von HBruijn als auch von Andrew B waren korrekt, aber sie scheinen zu wollen, dass ich HBruijn wähle, was ebenfalls kürzer ist, und das habe ich auch.

Ich musste nicht weniger als fünf Mal anrufen, um das Problem zu lösen. Eine 100% genaue Diagnose zu haben war sicherlich der Schlüssel zu mir, dass ich erfolgreich 3 Stufen der Eskalation erfolgreich überstehen konnte - ich durfte nie direkt mit der DNS-Abteilung sprechen.

Danke euch allen nochmal.


26
2018-01-13 05:38


Ursprung


Im Allgemeinen hilft DNS bei Problemen mit der tatsächlichen Domain, Probleme viel einfacher zu lösen. - HBruijn
Google überprüft auch den PTR-Datensatz. Nicht sicher, warum du diesen Paranoiden nennst; Es stoppt eine sehr große Menge an Spam. - Michael Hampton♦
Es gab eine Menge Diskussion über die Verwendung der offiziellen Beispieldomänen, nicht einen zufälligen Namen. Da du die IP-Adresse versteckst, vermute ich, dass der Name, den du verwendest, auch nicht deine tatsächliche Domain ist? - JDługosz
xxxxxxxxxxxxxxx - StewLG


Antworten:


444.333.222.111.in-addr.arpa. 86365 IN PTR main.funkeedomain.org.333.222.111.in-addr.arpa.

Scheint, dass in den reversen DNS-Zonendaten jemand vergessen hat, eine nachgestellte Periode hinzuzufügen . zu Ihrem Hostnamen, um anzuzeigen, dass es sich um einen vollständig qualifizierten Hostnamen handelt. In DNS Kurzschrift wird jedem einfachen Hostnamen $ ORIGIN angehängt.

Die richtigen Zonendaten wären

444.333.222.111.in-addr.arpa. 86365 IN   PTR     main.funkeedomain.org.

oder in DNS short-hand können Sie optional das weglassen $ORIGIN d.h. 333.222.111.in-addr.arpa:

444                           86365 IN   PTR     main.funkeedomain.org.

33
2018-01-13 06:49





Sehen Sie sich den Antwortabschnitt etwas genauer an:

;; ANSWER SECTION:
444.333.222.111.in-addr.arpa. 86365 IN   PTR     main.funkeedomain.org.333.222.111.in-addr.arpa.

Insbesondere der Wert des PTR-Datensatzes:

main.funkeedomain.org.333.222.111.in-addr.arpa.

Ihr ISP hat vergessen, den abschließenden Punkt zu Ihrem FQDN hinzuzufügen. Dies führt dazu, dass die DNS-Software den Namen der Zonendatei am Ende der Daten anhängt.

Sagen Sie ihnen, dass sie sich Ihren umgekehrten DNS-Eintrag ansehen sollen, erwähnen Sie den abschließenden Punkt, und wenn sie für sie Sinn haben, werden sie genau wissen, was sie falsch gemacht haben.


49
2018-01-13 06:49



Wenn Sie von Fragen zu einem Hot Network kommen, aktualisieren Sie stattdessen HBrujin. Diese Antwort ist bereits in meinen Top 5 aller Zeiten und es wird ein bisschen albern. (@HBrujin deine psychologische Kampfführung, damit ich bereue, diese 60 Sekunden vor deiner Arbeit beantwortet zu haben) - Andrew B
Wenn Sie das für schlecht halten, werfen Sie einen Blick auf meine Top 5 Antworten in StackOverflow. Nur # 2 ist ziemlich interessant, IMHO. - Barmar
@AndrewB Ich habe bereits Moderatorprivilegien, du könntest die Punkte so nehmen, dass du deine eigenen bekommen kannst Superkräfte der nächsten Stufe bei 20k - HBruijn


Zusätzlich zum Fixieren des umgekehrten Eintrags (siehe die Antworten von Andrew B und HBruijn) klingt es so, als ob Ihre Vorwärtseinträge auch verwechselt werden könnten. Wenn der Hostname des Servers main.funkeedomain.org lautet, sollte mx.funkeedomain.org nicht mit einbezogen sein. Stattdessen sollten Sie eine Aufzeichnung vom Typ "MX" haben, die von funkeedomain.org auf main.funkeedomain.org zeigt, und eine "A" Aufzeichnung, die von main.funkeedomain.org auf 111.222.333.444 zeigt. Grundsätzlich möchten Sie die Vorwärts-Lookups so aussehen:

$ host -t mx funkeedomain.org
funkeedomain.org mail is handled by 10 main.funkeedomain.org.
$ host main.funkeedomain.org
main.funkeedomain.org has address 111.222.333.444

Die Datensätze in Ihrer Zonendatei sollten ungefähr so ​​aussehen:

funkeedomain.org.       MX 10 main.funkeedomain.org.
main.funkeedomain.org.  A 111.222.333.444

Oder sie könnten den Zonennamen (funkeedomain.org) implizit haben, was durch ein fehlendes finales "." (wie Andrew B vermutet, ist das Problem mit der umgekehrten Aufzeichnung), so:

     MX 10 main.funkeedomain.org.
main A 111.222.333.444

... oder eine beliebige Anzahl anderer Varianten.


1
2018-01-13 22:15



MX ist hier unwichtig, da es sich nur um eingehende Post handelt. Um als Quelle für ausgehende E-Mails akkreditiert zu werden, sollte das OP überprüfen, ob es eine Übereinstimmung zwischen (1) dem FQDN, den sein MTA als EHLO-Begrüßung gibt, (2) dem FQDN erhalten wird, wenn er das reverse DNS der IP, die sein MTA verwendet, sucht und (3) die IP, zu der dieser FQDN in Vorwärts-DNS aufgelöst wird. Um Verwirrung zu vermeiden, ist es zusätzlich besser, mehrere PTR und / oder mehrere A-Records für die betroffene ip / fqdn zu vermeiden ... - Hagen von Eitzen