Konsole meldet nach Einrichtung DKIM: DNS-Eintrag fehlt

[ZZB]

hallo allerseits,

ist sicher nur ein anfängerfehler, aber ich komme einfach nicht drauf.

habe gerade nach dem nsp-video auf youtube von 2019 DKIM im NSP (aktuell v15.0.0) eingerichtet.
bei domainfactory habe ich auch die txt-einträge mit den keye._domainkey.<TLD> sowie keyr._domainkey.<TLD> nebst den angaben aus NSP zum schlüssel entsprechend videoanleitung angelegt.

verifikation bei mxtoolbox für die SPF- und DKIM-einträge (und später auch für DMARC) erfolgreich - alles grün.

ich habe auch eine testmail an ping@mxtoolbox.com gesandt - dort stand dann aber zu lesen, daß mit den beiden DKIM Signatures (e und r) etwas nicht stimme:

bei der ellyptical (e) dkim signature wäre der wert des tags "a" nicht korrekt: "Must contain one of these values:rsa-sha1" im tag "a" steht: "ed25519-sha256"
für mich aufs konto von mxtoolbox leicht verwunderlich, denn für ellyptical sollte nicht "rsa-sha1" dort stehen, oder?

bei der rsa dkim signature gibt es keine direkte errormessage; das feld ist einfach rötlich unterlegt.
die inhalte des dort angezeigten tags sehen (gekürzt und geschwärzt (kursiv)) so aus:

v=1; c=relaxed/relaxed; d=<TLD> ; s=keyr; t=1758217080; bh=xcafXB4vXGSi+obTc8KRbHg3zuZN+b8dzM1vHA5Vjd0=; h= Subject:Subject:From:Fromateate:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id; a=rsa-sha256; b= OA+7OxRet3i2amqy9At0Pt9jM36/8zXfOlFwC[...]CBJVaP7SXpdl342pJKajosc6AKuSHRttuIaJ1HdIJOxu2/VczGCWyqxKCnlOfPgkl/K8UZaVXOJRbBw4HI/B7zaOgwi0Ro=

all in all ist für den mxtoolbox-prüfschritt "DKIM Signature Verified" das result "Signature Did Not Verify".

zudem fällt auf, daß die intranetrolle des NSP nun bereits auf der startseite die meldungen anzeigt, daß der DNS-Eintrag keye._domainkey.<TLD> sowie keyr._domainkey.<TLD> fehlen würde - "Bitte erstellen Sie diesen DNS-Eintrag, um den Vorfall zu lösen. [...]"

vielleicht noch erwähnenswert ist, daß unsere installation des NSP alle rollen auf einer VM vereint, welche in unserer DMZ steht. alle laut hilfetexten freizugebenden ports sind in der firewall (eine Palo Alto) freigegeben. der NSP liefert alle ausgehenden emails an unseren provider domainfactory unter zuhilfenahme eines authorisierten sendekontos. abruf aller emails erfolgt per NSP-pop-konnektor von den emailkonten von domainfactory.

da die von mxtoolbox bekrittelten DKIM-signaturen anscheinend vom NSP erzeugt wurden, wende ich mich hiermit an euch und bin wirklich sehr gespannt, ob sich das phänomen auflösen lässt.

dankeschön für die hilfe und
beste grüße,
richard rönitz

 

[ffischer]

Guten Morgen,
habt ihr intern das AD mit der selben Domain wie Extern? Also euredomain.de
Wenn der NSP den eigenen AD Server als DNS Server nimmt, frägt er automatisch diesen ab wenn hier die Einträge dann nicht vorhanden sind für DKIM Einträge kommt es zu diesem fehler.

Das kann getestet werden wenn du bsp. den NSP anweißt mal kurz den anderen DNS Server zu verwenden vll. die Firewall, wenn die nach Extern verweißt.

 

[ZZB]

guten morgen frank,

schlaue frage - treffer, versenkt! ja, wir haben intern=extern.
ich kann die einträge natürlich auch gern im internen AD nachholen - aber bekämpfe ich damit nicht nur ein symptom?

ist es denn generell sinnvoller, den NSP eher mit der firewall-IP als DNS-server zu betreiben, anstatt den internen DNS zu nehmen?

und: siehst du einen zusammenhang mit den von MSTOOLBOX angekreideten DKIM-signaturen?

danke und beste grüße,
richard

 

[ffischer]

Hallo Richard,
welchen Test hast du bei mxtoolbox gemacht ich schau mir den mal an ob dieser bei mir das gleiche verhalten an den Tag legt.
Bei mir fand ich bisher keinen Nachteil, ob Interner DNS oder Externer,

Du kannst ja Windows Netzwerk DNS auf den Internen DNS legen
und NSP ja unter Konfiguration - Verbundene Systeme => oben auf DNS Server gehenen. und dann einen Externen angeben oder die Firewall. Firewall würde ich empfehlen, wenn die DNS Abfragen prüft.

 

[StefanCink]

Hallo zusammen,

MXToolbox ist für diesen Test lieder nicht geeignet, da sie keine EdDSA-basierten Signaturen verstehen. :-( Immer noch nicht. :-(

 

[ZZB]

hallo frank,

ich hatte eine mail an ping@tools.mxtoolbox.com gesandt. im reply gibt es dann einen link zur auswertung. bin ich auch sehr gespannt, ob bei deinem test auch die DKIM-signatur angezählt wird.

deine idee mit der verlegung des NSP-DNS auf extern werde ich mal austesten! komme heute allderdings nicht mehr dazu - verlängertes WE ;o)

-richard

 

[ZZB]

Hallo zusammen,

MXToolbox ist für diesen Test lieder nicht geeignet, da sie keine EdDSA-basierten Signaturen verstehen. :-( Immer noch nicht. :-(

hallo stefan,

danke, interessanter hinweis!
dann ist die auswertung von mxtoolbox eventuell nur einen sturm im wasserglas wert? gibts eine andere möglichkeit zur verifikation?

also mein ultimativer test wird sein, endlich eine email an eine patientin mit icloud-emailadresse zur zustellung zu bringen ;o) das war auch der auslöser meines DKIM-DMARC-abenteuers.

-richard

 

[ffischer]

probier doch mal: https://www.appmaildev.com/de/dkim

 

[869288141]

schlaue frage - treffer, versenkt! ja, wir haben intern=extern.
ich kann die einträge natürlich auch gern im internen AD nachholen - aber bekämpfe ich damit nicht nur ein symptom?

Da werdet ihr euch vor der Implementierung von Split DNS (intern=extern) alle Vor- und Nachteile sorgfältig abgewogen haben. Wir seit ihr denn bisher mit solchen Einträge umgegangen?

Bezüglich deiner Frage kann ich dir leider nicht folgen. Wenn die öffentliche DNS-Zone von einem dedizierten DNS-Server bzw. Anbieter verwaltet wird, wirst du alle Einträge doppelt pflegen müssen. Eine andere Option ist den internen DNS als Hidden Primary zu betreiben und die DNS-Zone dadurch ins Internet zu euren/einem Anbieter replizieren. Hat natürlich die Folge, dass standardmäßig alle DNS-Einträge aus dem LAN im Internet auflösbar/einsehbar sind. Da könnte man mit einem Filter dagegen wirken. Ist aber nichts für schwache Nerven...

 

[ZZB]

probier doch mal: https://www.appmaildev.com/de/dkim

hallo frank, danke dir -> das hat geklappt, und es scheint alles soweit richtig eingerichtet zu sein.
-richard

 

[ZZB]

Da werdet ihr euch vor der Implementierung von Split DNS (intern=extern) alle Vor- und Nachteile sorgfältig abgewogen haben. Wir seit ihr denn bisher mit solchen Einträge umgegangen?

Bezüglich deiner Frage kann ich dir leider nicht folgen. Wenn die öffentliche DNS-Zone von einem dedizierten DNS-Server bzw. Anbieter verwaltet wird, wirst du alle Einträge doppelt pflegen müssen. Eine andere Option ist den internen DNS als Hidden Primary zu betreiben und die DNS-Zone dadurch ins Internet zu euren/einem Anbieter replizieren. Hat natürlich die Folge, dass standardmäßig alle DNS-Einträge aus dem LAN im Internet auflösbar/einsehbar sind. Da könnte man mit einem Filter dagegen wirken. Ist aber nichts für schwache Nerven...

nun ja, diese konstellation haben wir schon seit vielen jahren; es geht auf microsofts eigene empfehlung für split-dns aus der zeit zurück, wo ".local" bereits als veraltet markiert war. da war das wissen bei uns um vor- und nachteile nur noch nicht praxisfest ;o)

bislang hat uns das aber noch nie wirklich irgendwelche steine in den weg gelegt, die nicht beiseite zu räumen gewesen wären.

daß du bezüglich meiner frage mir nicht folgen konntest, dürfte wohl meinem mangelnden DNS-fachwissen anzulasten sein - ich dachte einfach nur, daß ich die nameserver-einträge, die ich bei unserem provider für DKIM angelegt hatte, nun auch in unserem internen AD-DNS machen müsste, da frank schrieb: "Wenn der NSP den eigenen AD Server als DNS Server nimmt, frägt er automatisch diesen ab wenn hier die Einträge dann nicht vorhanden sind für DKIM Einträge kommt es zu diesem fehler."
da war mir aber noch nicht bewusst, daß man (wie von frank empfohlen) im NSP unter "Verbundene Systeme" den externen DNS mit der firewall-IP als primäre adresse und mit einer Google-Adresse als sekundäre adresse füttern kann. die netzwerkkarteneinstellungen der VM des NSP zeigen für windows selbst weiterhin auf den internen DNS.

ergebnis: die meldung vom NSP ist verschwunden, eMails werden weiterhin zugestellt und abgeholt, und ich bin glücklich!

danke an alle, die mitgeholfen haben!
beste grüße,
-richard

 

[869288141]

Hallo Richard,

daß du bezüglich meiner frage mir nicht folgen konntest, dürfte wohl meinem mangelnden DNS-fachwissen anzulasten sein - ich dachte einfach nur, daß ich die nameserver-einträge, die ich bei unserem provider für DKIM angelegt hatte,

Manchmal ist es besser weniger zu wissen. Manchmal steh ich auf der Leitung. Manchmal denke ich einfach zu kompliziert. Daher kann es auch auch einfach an mir liegen.

da war mir aber noch nicht bewusst, daß man (wie von frank empfohlen) im NSP unter "Verbundene Systeme" den externen DNS mit der firewall-IP als primäre adresse und mit einer Google-Adresse als sekundäre adresse füttern kann. die netzwerkkarteneinstellungen der VM des NSP zeigen für windows selbst weiterhin auf den internen DNS.

Das kann andere Seiteneffekte haben. Das können wir alle hier auch nicht bewerten. Das kannst du nur.

Evtl. kann ein anderer User oder ein Angestellter von Stefan Cink oder Sören sagen, für welche Aktionen diese Funktion verwendet wird. Nicht das nach einen Neustart von NSP z.B. der Exchange-Server nicht gefunden wird. Weil exchange01.domain.local nicht mehr aufgelöst werden kann.


Gruß,
Daniel

 

[ZZB]

hello daniel,

danke für deinen wertvollen hinweis - ich habe gleich mal montag gespielt und den NSP neu gestartet. ist sonst auch teil meines standardrepertoirs, aber diesmal ists mir nicht von allein eingefallen ;o)
da wir eine kleine firma sind und nur einen exchange on prem haben, habe ich auch direkt seine IP anstatt seines namens im NSP hinterlegt. auflösung ist also zum glück nicht nötig.

ein paar testmails später kann ich also erstmal erleichtert sagen: auch nach neustart des NSP läufts scheinbar sauber.
aber ich werde das weiter beobachten

beste grüße,
-richard

 

[869288141]

ist sonst auch teil meines standardrepertoirs, aber diesmal ists mir nicht von allein eingefallen ;o)

No Problemo. Passiert allen mal.

auflösung ist also zum glück nicht nötig.

Spontan fällt mir noch der automatische User Import über DC/GC ein.

aber ich werde das weiter beobachten

Meine 5 Cent als IT Architekt. Wenn ihr euch für ein Split-DNS Konstrukt entschieden habt, würde ich das Konsequenz umsetzen. Split-DNS ist keinesfalls als schlecht oder minderwertig anzusehen. Wenn man es korrekt mit einer offiziellen Domain ala domain.de umgesetzt hat. Alle Ausnahmen/Abweichungen führen meiner Erfahrung nach früher oder später zu Problemen. Ganz unabhängig davon ob man es dokumentiert hat oder nicht. Weil man diese eben nicht auf den ersten Blick sieht.