ubuntuusers.de

Auf meinem Server für ganske.org läuft postfix. Konfiguriert habe ich DNSSEC, DANE, SPF etc. Mein Problem ist, dass Mails zu vielen Outlook-Mailadressen nicht versendet werden können.

Beispiel ist eine Mail an support@switch-bot.com. Im Mail.log steht

warning: no MX host for switch-bot.com has a valid address record
421A792021B: to=<support@switch-bot.com>, relay=none, delay=201290, delays=201279/0.06/11/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=switchbot-com01e.mail.protection.partner.outlook.cn type=AAAA: Host not found, try again)

Aber alle anderen Mails, die nicht über einen MX mit "protection" und "outlook" im Namen laufen, können einwandfrei versendet werden. Folgendes sagt dnsviz über den MX der Zieladresse:

https://dnsviz.net/d/switchbot-com01e.mail.protection.partner.outlook.cn/analyze/

Problem scheint zu sein, dass SERVFAIL als Status für die Einträge bei dig A und dig AAAA zurückkommt. Damit gilt der DNS nicht als validiert für DNSSEC und der Eintrag wird nicht akzeptiert. Das betrifft aber recht viele Mailadressen, nicht nur einzelne. Wie kann ich dieses Problem lösen, ohne DNSSEC/DANE auszuschalten? Oder sollte ich das sogar tun?

Bei mir funktioniert die Auflösung, aber DNSSEC scheint da nicht eingerichtet zu sein.

m@ryz:~$ dig a switchbot-com01e.mail.protection.partner.outlook.cn +dnssec 

; <<>> DiG 9.19.21-1+b1-Debian <<>> a switchbot-com01e.mail.protection.partner.outlook.cn +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27088
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;;hier fehlt ad als Flag für DNSSEC.
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 0651eb0d57c337a9010000006602abc848bb2d5e1221f427 (good)
;; QUESTION SECTION:
;switchbot-com01e.mail.protection.partner.outlook.cn. IN        A

;; ANSWER SECTION:
switchbot-com01e.mail.protection.partner.outlook.cn. 10 IN A 139.219.146.10
switchbot-com01e.mail.protection.partner.outlook.cn. 10 IN A 139.219.17.10

;; Query time: 43 msec
;; SERVER: xx#53(xx) (UDP)
;; WHEN: Tue Mar 26 12:04:40 CET 2024
;; MSG SIZE  rcvd: 140

m@ryz:~$ 

Wie sieht das bei dir aus?

Da kommt eben dieses status: SERVFAIL, das ich bei vielen Outlook-Domains bekomme.

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> a switchbot-com01e.mail.protection.partner.outlook.cn +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39447
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
;; QUESTION SECTION:
;switchbot-com01e.mail.protection.partner.outlook.cn. IN        A

;; ANSWER SECTION:
switchbot-com01e.mail.protection.partner.outlook.cn. 10 IN A 139.219.17.10
switchbot-com01e.mail.protection.partner.outlook.cn. 10 IN A 139.219.146.10

;; Query time: 2619 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Mar 26 12:21:23 CET 2024
;; MSG SIZE  rcvd: 112

Bei mir nicht, ich befrage aber auch direkt den BIND9 bei mir. Mal direkt den Resolver mit dig abfragen und systemd-resolve als Ursache ausschließen. Geht bei dig mit

dig example.org aaaa @2001:db8::53 +crypto 

Direkt geht. Da kommt NOERROR. Einfach @(DNS) hintendran und alles ist gut. Habe extra den gleichen DNS verwendet, der vorher ausgegeben wurde. Also ist systemd-resolve wohl schuld. Wie korrigiere ich das denn am einfachsten?

Edit: Microsoft hat einen Rollout bis Ende 2024 geplant, das kann ja was ändern. Aber wenn ein Mailserver DANE/DNSSEC nicht unterstützt, sollte die Mail trotzdem ausgeliefert werden. Halt ohne sicheres DNS. Klappt hier aber irgendwie nicht. Also verhält sich systemd-resolve doch fehlerhaft?

# dig a switchbot-com01e.mail.protection.partner.outlook.cn +dnssec @208.67.222.222

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> a switchbot-com01e.mail.protection.partner.outlook.cn +dnssec @208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19416
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1410
;; QUESTION SECTION:
;switchbot-com01e.mail.protection.partner.outlook.cn. IN	A

;; ANSWER SECTION:
switchbot-com01e.mail.protection.partner.outlook.cn. 10	IN A 139.219.146.10
switchbot-com01e.mail.protection.partner.outlook.cn. 10	IN A 139.219.17.10

;; Query time: 443 msec
;; SERVER: 208.67.222.222#53(208.67.222.222) (UDP)
;; WHEN: Tue Mar 26 13:01:33 CET 2024
;; MSG SIZE  rcvd: 112

DNSSEC ist hier nicht aktiv.

m@ryz:~$ delv switchbot-com01e.mail.protection.partner.outlook.cn aaaa
;; resolution failed: ncache nxrrset
; negative response, unsigned additional data
; m@ryz:~$ delv switchbot-com01e.mail.protection.partner.outlook.cn aaaa
;; resolution failed: ncache nxrrset
; negative response, unsigned additional data
; m@ryz:~$ delv switchbot-com01e.mail.protection.partner.outlook.cn a
; unsigned answer
switchbot-com01e.mail.protection.partner.outlook.cn. 10 IN A 139.219.17.10
switchbot-com01e.mail.protection.partner.outlook.cn. 10 IN A 139.219.146.10
m@ryz:~$ 

Jetzt ist die Frage, wie die Konfiguration deines systemd-resolve aussieht.

Da sind 4 Zeilen aktiv in resolved.conf

[Resolve]
DNS=
DNSSEC=
DNSOverTLS=

DNS ist unkritisch, wie wir festgestellt haben. Habe ich zwischendurch geändert, kein Unterschied.

DNSOverTLS stand auf yes, aber die Änderung auf opportunistic hat nichts gebracht. Habe es trotzdem so gelassen.

DNSSEC stand auf yes. Die Änderung auf allow-downgrade hat nichts gebracht.

Stelle ich DNSSEC auf no, dann funktioniert die Anfrage. Aber das ist ja nicht der Sinn der Sache.

(Jede Änderung mit systemctl restart systemd-resolved)

Wie löst man das nun richtig?

Dein Resolver macht doch DNSSEC. Warum willst du das nochmal von resolved prüfen lassen?

Dann habe ich was falsch verstanden. Ich dachte systemd-resolved sei der resolver. Warum gibt man ihm sonst die Adressen der DNS, wenn er sie gar nicht selbst benutzt? Wer macht es denn dann? Auch andere bezeichnen systemd-resolved als resolver.

Im resolvectl status steht nun DNSSEC=no/unsupported - und das soll wirklich passen?

systemd-resolve ist nur ein stub-resolver, der alle Anfragen an einen Upstream-Resolver weitergibt. Dieser geht dann iterativ die hierarchie entlang und holt die DNS-Daten. Betreibst du einen solchen?

Laut manpage ist systemd-resolved ein stub-Resolver, aber implementiert auch LLMNR und MulticastDNS resolver.

Mir ist nicht bewusst, etwas anderes zu betreiben.

Im systemctl status sehe ich aber zwei Abschnitte. Global mit mode stub und Link 2 (eth0) mit Scope DNS und Protocols +DefaultRoute und +LLMNR

# resolvectl status
Global
         Protocols: -LLMNR -mDNS DNSOverTLS=opportunistic DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 1.0.0.1

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS DNSOverTLS=opportunistic
                    DNSSEC=no/unsupported
Current DNS Server: 208.67.222.222
       DNS Servers: 208.67.222.222 208.67.220.220 2620:119:35::35 2620:119:53::53
        DNS Domain: invalid

Kann es sein, dass der zweite Abschnitt für den resolver steht und systemd-resolved also doch der resolver ist?

Ich kann das gerne umstellen und einen anderen Resolver verwenden, wenn ein anderer Resolver für DNSSEC besser ist.

Wenn du DNSSEC sinnvoll betreiben willst musst du auf deiner Seite verifizieren. Spricht für dich was dagegen, lokal einen BIND zu betreiben und systemd-resolve abzustellen?

Es scheint, als ob systemd-resolve hier das Problem verursacht. Ggf. auch mal da auf ner Mailingliste o.Ä. ansprechen.

Ne der war ja billig.

apt install bind9

Und alles läuft. Den braucht man ja nicht mal irgendwie konfigurieren.

Noch den DNS 127.0.0.1 gesetzt in resolved.conf, und DNSSEC konnte ich auf allow-downgrade stellen (mag unsinnig sein, schaden wird es wohl doch nicht) und alles läuft prima.

systemd-resolve muss nun deaktiviert werden.

sudo systemctl mask systemd-resolved

DJKUhpisse schrieb:

systemd-resolve muss nun deaktiviert werden.

sudo systemctl mask systemd-resolved

Das ist OK?

# resolvectl status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service failed to load properly, please adjust/correct and reload service manager: File exists