Aus aktuellem Anlass tragen derzeit viele Menschen ein digitales Impfzertifikat in Form eines QR-Codes mit sich herum. Anscheinend steht da nur irgendwelcher binärer Müll drin. Das macht neugierig, also mal genauer hingeschaut. (mehr …)
Sing this song (author unfortunately unknown) to the tune of Yesterday, The Beatles:
Yesterday,
All those backups seemed a waste of pay.
Now my database has gone away.
Oh I believe in yesterday. (mehr …)
Die gängigen zwei Gründe für einen NXDOMAIN bei einer DNS-Anfrage sind: Vertippt und vergessen. Bei vertippt ist es egal ob dies auf der Client Seite oder in der Zonendatei passiert ist: Vertippt bleibt vertippt. Und vergessen kennt jeder: Es hätte schon längst in der Zonendatei drin stehen sollen. Hätte. Nur was ist wenn man wie beim NXDOMAIN kein Ergebnis bekommt und stattdessen als Status FORMERR?
Ich hatte es bereits neulich schon einmal von einem DNS Problem: "lame server" oder viel Spaß mit DNS. Hier verweigerte ein Server die Antwort obwohl er diese liefern müsste. Nur warum hat er dies getan? Was wäre wenn die Zonendatei und die Konfiguration korrekt wären? Was wäre wenn dieser eine Nameserver anstatt NXDOMAIN dann doch tatsächlich einen FORMERR zurück liefert? Und sogar bei Einträgen die es gibt der FORMERR kommt? Was wäre wenn das Dein DNS-Server wäre und Du jetzt nach der Ursache suchen müsstest?
Da kann man allerdings noch einen oben drauf setzen: Das ist kein generelles Problem, bei vielen funktioniert alles wunderbar. Und auch einschlägige Testtools welche man auf diversen Internetseiten findet liefern das korrekte Ergebnis zurück. Also gut, los geht es. Schauen wir uns das doch nochmals genauer an.
Was wissen wir bereits? Grundsätzlich funktioniert der DNS-Server. Der Fehler ist reproduzierbar und er ist selektiv. Das heißt bei den Personen wo dieses Problem auftritt, tritt es bei jeder DNS-Anfrage auf. Für alle anderen ist alles in bester Ordnung. Somit gibt es zwei Gruppen: Die wo es funktioniert und diejenigen wo es nicht funktioniert. Es gilt also den Unterschied zu suchen. Da für beide Gruppen der Server der gleiche ist muss die Ursache auf dem Client liegen. Irgendwas muss bei der vermeintlich gleichen Frage an den Server unterschiedlich sein. Also fangen wir mal an der Stelle an und betrachten die Frage an den Server genauer.
Also gut, es geht darum zu finden was auf Client Seite passiert ist. Somit starte ich mein Werkzeug der Wahl: dig. Schauen wir uns doch mal an was hier zurück kommt:
steffen@gmn:~$ dig <domain>.com @ns1.<domain>.com
; <<>> DiG 9.16.1-Ubuntu <<>> <domain>.com @ns1.<domain>.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 27153;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; COOKIE: 247f6f7828e8660c (echoed);; QUESTION SECTION:;<domain>.com. IN A
;; Query time: 204 msec;; SERVER: 1.2.3.4#53(1.2.3.4);; WHEN: Di Jun 16 21:36:49 CEST 2020;; MSG SIZE rcvd: 55
Grün markiert ist mein eingegebenes Kommando. Rot der FORMERR. Das wissen wir bereits. Aber halt, in der blau markierten Zeile mit Cookie: Da steht echoed in der Klammer, jedoch sollte hier good stehen. Also nochmals die gleiche Anfrage gestellt, dieses mal jedoch mit der zusätzlichen Option +noedns:
steffen@lka:~$ dig <domain>.com @ns1.<domain>.com +noedns
; <<>> DiG 9.16.1-Ubuntu <<>> <domain>.com @ns1.<domain>.com +noedns;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23374;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0;; WARNING: recursion requested but not available
;; QUESTION SECTION:;<domain>.com. IN A
;; ANSWER SECTION:<domain>.com. 3600 IN CNAME sub.<domain>.com.
;; Query time: 204 msec;; SERVER: 1.2.3.4#53(1.2.3.4);; WHEN: Di Jun 16 21:36:57 CEST 2020;; MSG SIZE rcvd: 57
Und siehe an, das hat funktioniert. Dabei wäre es egal ob ich als Option +noedns wie gezeigt oder +nocookie verwendet hätte. Beide Optionen liefern wieder die gewohnten Ergebnisse zurück. Gesucht, gefunden: Der DNS-Server hat ein Problem mit EDNS.
Naja, was kann man tun? Bei mir hier im Netz läuft ein lokaler bind Server fürs DNS Caching. Gemäß Doku kann man hier sagen, dass immer dann wenn er den betroffenen Server kontaktiert werden soll EDNS abschaltet wird:
server <IP address or prefix> { edns no; };Der Link dazu: https://kb.isc.org/docs/aa-01219. Aber mal ehrlich: Will ich das tun? Nein, dass will ich nicht. Warum sollte ich die Probleme eines Dritten bei mir im DNS Resolver lösen? Hier liegt ja offensichtlich ein Fehler vor der klar wird wenn man z.B. ins RFC 6891, Absatz 6.1.2 schaut:
Any OPTION-CODE values not understood by a responder or requestor MUST be ignored.
Der Link zum RFC: https://tools.ietf.org/html/rfc6891#section-6.1.2. "Must be ignored"... Und was bekomme ich? FORMERR. Also alles andere als ignoriert. Soso...
Nein, dann soll doch lieber der DNS-Server Betreiber die passenden Updates einspielen damit EDNS bzw. die Cookies richtig funktionieren. Ich bin garantiert nicht der einzige mit dem Problem und ich werde es auch sicherlich nicht bleiben. EDNS ist nun mal wichtig für die kommenden DNS Erweiterungen.
Weitere Details zu den DNS Cookies sowie zu EDNS gefällig? Ein sehr guter Ausgangspunkt finde ich ist der DNS Flag Day von 2019: https://dnsflagday.net/2019/. Ebenso interessant dazu ist der ISC EDNS Compliance Test: https://ednscomp.isc.org/. Auch hier finden sich viele praktische Infos rund um das Thema EDNS. Und besonders Schick, deswegen heißt das Ding ja "Konformitätstest": Hier kann man den betroffenen Server testen lassen und bekommt einen ausführlichen Bericht mit vielen weiteren Detailinformationen. Neben dem bereits genannten RFC ist auch dieses hier interessant welches die Cookies nochmals erklärt: https://tools.ietf.org/html/rfc7873#section-2.1.
Ein leiser Hilferuf: „Meine Verbindungen auf eine bestimmte Webseite brechen mehrfach am Tag ab“. Aha… Das kann ja so ziemlich alles sein. Spannend, spannend. Die Suche nach der Nadel im Heuhaufen. Ich mag seltene Wunder, genau meine Kragenweite. Dann mal rasch ans Werk. (mehr …)
Irgendwie kommen Freitags regelmäßig die Kuriositäten des Monitorings bei mir auf den Tisch. Heute zum Thema NTP: Der check_ntp_time aus den nagios-plugins wirft einen Offset unknown Fehler. Obwohl die Uhrzeit richtig wäre. Also mal nachgeschaut was da los ist. (mehr …)
Mal wieder ein Problem zum Thema Email und Postfix. Neulich erst SMTPUTF8, jetzt wieder etwas was sich der Admin vor Ort nach Erklärungen und Lösungen sucht.
Fortune hat einmal zu mir folgendes gesagt:
The light at the end of the tunnel may be an oncoming dragon.
Für alle diejenigen die fortune nicht kennen: https://de.wikipedia.org/wiki/Fortune_(Computerprogramm).
Man sollte natürlich richtig prüfen, ob die IPv6 Auflösung eventuell sogar wirklich ein Problem hat. Da die Frage aufkam hier das grobe Vorgehen dazu: In der Fehlermeldung steht eine IPv6 Adresse drin. Diese per Reverse-DNS auflösen. Der Rechnername, der hierbei raus kommt sollte via Forward-DNS wieder zur gleichen IPv6 Adresse führen. Unterm Strich genauso, wie es auch für IPv4 der Fall sein sollte. Bitte dran denken. Nur wenn das alles passt und immer noch nichts hilft, dann kann dieses vorgehen wie hier beschrieben eine sinnvolle Variante sein.
Bevorzugt kommen solche Fragen ja immer am spätem Nachmittag rein. Mal wieder das Thema Email. Mal wieder auf den ersten Blick dubios: Angeblich kann ein Emailserver keine Mails an eine bestimmte Empfangsdomain senden. Als Grund wird der fehlende Reverse DNS-Eintrag angegeben. Dieser ist aber gesetzt. So auf die schnelle passt hier irgendwas nicht zusammen, der detailliertere Blick ins Protokoll muss her. Hier findet sich folgendes - stark gekürzt und anonymisiert. Du weißt schon, Datenschutz und so 😉
May 7 14:12:37 methusalix postfix/smtp[587]: 0D2B11E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.57, delays=0.02/0.01/0.33/0.21, dsn=2.0.0, status=sent (250 OK id=1hNyxZ-00061t-DZ) May 7 14:12:37 methusalix postfix/smtp[587]: 9600B1E0028: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.35, delays=0.01/0/0.22/0.12, dsn=2.0.0, status=sent (250 OK id=1hNyxZ-00068z-RW) May 7 14:13:23 methusalix postfix/smtp[587]: EAE621E0028: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.4, delays=0.01/0/0.21/0.18, dsn=2.0.0, status=sent (250 OK id=1hNyyJ-0007Tp-6X) May 7 14:55:19 methusalix postfix/smtp[6340]: A672D1E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.65, delays=0.01/0/0.5/0.14, dsn=2.0.0, status=sent (250 OK id=1hNzct-0006QR-6i) May 7 15:13:07 methusalix postfix/smtp[8811]: 6C1A31E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1:1:1:1::1:1]:25, delay=0.39, delays=0.03/0.01/0.32/0.03, dsn=5.0.0, status=bounced (host mail.gatew.ay[1:1:1:1::1:1] said: 550-Inconsistent/Missing DNS PTR record (RFC 1912 2.1) 550 (methusalix.doma.in) [1:1:1:1::1]:44636 (in reply to RCPT TO command))
Aha... 4x geht es und einmal nicht. Was bei dem einen Versuch anders ist? Der war per IPv6, die anderen via IPv4. Ok, das mag ja jetzt sein: Reverse-DNS für IPv4 gesetzt, für IPv6 schlichtweg vergessen. Fix via host-Befehl im DNS abgefragt auf die IPv6 Adresse die laut Log keinen Reverse Eintrag haben soll: Oh wunder, der ist richtig auflösbar. Ab jetzt wird es seltsam. Aber wie so oft: Erstmal muss eine Lösung her. Die Suche nach der Ursache wird mal wieder hinten angestellt.
Also gut, das hier ist ganz klar ein Fall für den Blick in die Postfix Dokumentation bzw. in die aktuelle Konfiguration.
Recent Postfix SMTP clients randomly select between IPv4 and IPv6 so that mail won't get stuck when one of the two is down.
smtp_address_preference = any ist wie es sich gehört richtig gesetzt. Das macht so einfach mit am meisten Sinn und wird in der Dokumentation letztendlich genauso empfohlen. inet_protocols brauche ich gar nicht zu kontrollieren, muss auf any stehen. Sonst hätte es gar nicht die beiden unterschiedlichen Zustellvarianten geben dürfen. Um jetzt zu verstehen was da passiert sollte man die Doku kennen oder sich an das im Block links angeführte Zitat von Wietse erinnern.
Somit ist die Lösung für dieses Rätsel fix gefunden: Für diese eine Empfangsdomain sollte der Emailausgang ausschließlich auf IPv4 festgelegt werden. Nur kennt Postfix keine inet_protocol_map in der man dies festlegen könnte. Es ist also mal wieder die Frage nach etwas Kreativität um eine passende Lösung mit Postfix Mitteln entsprechend abzubilden.
Und der Weg zum Ziel ist unterm Strich mal wieder ganz einfach: Man definiert in der master.cf einen weiteren smtp Dienst welcher als Option das oben bereits erwähnte inet_protocols = ipv4 hat. Im zweiten Schritt noch fix einen passenden Eintrag für die Zieldomain in der transport Tabelle gesetzt welche genau diesen Dienst verwendet und voilà: Ziel erreicht.
Die folgenden Beispiele zeigen an reinen Textdateien unter /etc/postfix die passende Konfiguration für die Empfängerdomain gehirn-mag.net. Wer dort bereits eine transport-Tabelle hat kann diese selbstverständlich nutzen. Wer ein Datenbank- oder LDAP-Backend hat kann diese Lösung sinngemäß übertragen. Hier aber, der Einfachheit wegen, das Beispiel an den "blanken" Textdateien. Und Du solltest logischerweise die Empfängerdomain richtig anpassen 🙂
Die erste Datei die geändert wird ist /etc/postfix/master.cf. Hier wird ein weiterer Dienst eingetragen. Eine Zeile analog zur ersten gibt es bereits. Wichtig ist, dass zu Beginn am Anfang und am Ende smtp steht und kein smtpd. Diese kopiert ihr, ändert den Namen (Zeile 2, Spalte 1) und fügt darunter den Inhalt der Zeile 3 ein.
Als nächstes ist /etc/postfix/main.cf dran. Hier ist zu prüfen ob es eine transport_maps Zeile gibt. Falls nicht fügt Ihr diese einfach ein.
Und zu guter Letzt ist die transport Tabelle /etc/postfix/transport selbst. Hier ist der Eintrag für die Zieldomain zu setzen, dass diese unseren neuen IPv4 smtp Dienst verwendet.
smtp unix - - y - - smtp
smtp-ipv4 unix - - y - - smtp
-o inet_protocols=ipv4
transport_maps = hash:/etc/postfix/transport
gehirn-mag.net smtp-ipv4:
Nun müsst Ihr noch via postmap /etc/postfix/transport diese für postfix übersetzen und mit postfix reload den Mailserver neu starten. Postfix versendet nun für Eure Zieldomain alle Mails dorthin via IPv4 anstatt frei zu wählen was er jetzt verwenden könnte.
Was eine Lösung. Ist das wirklich elegant gemacht auf diese Art und Weise? Ja, das ist Sie. Auf ihre ganz spezielle Art. Einen eigenen Dienst in der master.cf anzulegen macht man eigentlich öfters. Am häufigsten wohl als Ziel für irgendwelche Postfachsysteme wie IMAP/POP3 oder Groupware-Systeme. Wenn man diese externe Domain mit der sinngemäßen gleichen Logik betrachtet ist das schon sehr ähnlich: Ein Postfachspeicher welcher Emails via SMTP annimmt und obwohl er eine IPv6 Adresse hat kann der Dienst aber nur IPv4. Ich betreue Postfix Umgebungen bei denen aufgrund von der Vielzahl und der Größe der dahinter liegenden Groupware Lösungen die transport-Tabelle länger ist bei vielen anderen Installationen die virtual-Tabelle. Da erlebt man noch ganz andere Dinge...
In größeren Emailumgebungen ist man gefühlt nie am Ende mit der Konfiguration angekommen. Man mag sich in dem zu Beginn angesprochenen Tunnel fühlen. Sobald die Ursache aber sauber erfasst wurde ist die Lösung des Problems rasch erledigt und das Ende des Tunnels naht. Bis zum nächsten Anruf 😉
Aber morgen kontaktiere ich erstmals den Emailadmin auf der anderen Seite und frage nach den Gründen für diese Fehlermeldung - Feierabend für heute.