Outgoing DANE ignoriert fehlerhafte DANE Einträge

[Christian]

Hallo zusammen,
um dies abzuschließen: Das Problem lag an der Nutzung von musl-libc in
Alpine.Die Implementierung kann die nötigen Flags nicht an den resolver
weiterleiten und Postfix funktioniert entsprechend nicht auf musl-libc.
Ich war dazu mit Viktor Dukhovni im Austausch, er hat sich auch den
Code angeschaut und einige andere fehlende Implementierungen in musl-
libc gefunden.Sein abschließendes Verdict: "DO NOT run Postfix over
musl-libc."
Damit auch nicht auf Alpine.
Danke an alle die geholfen haben!
Am Sonntag, den 12.04.2020, 14:14 +0200 schrieb Christian:
> Hallo zusammen,
> nach weiteren Tests, habe ich nun die queries im unbound
> mitgeschrieben. Postfix kontaktiert den richtigen resolver,
> allerdings scheint kein TLSA Record angefragt zu werden:
> Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0]
> info: 192.168.4.5 do.havedane.net. MX IN#015Apr 12 14:00:56 server
> docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5
> do.havedane.net. A IN#015Apr 12 14:00:56 server docker/unbound[567]:
> [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. AAAA
> IN#015
> Ich hätte auch eine Abfrage des TLSA Records erwartet (Hier mal mit
> dig vom Postfix host angefordert)Apr 12 14:01:25 server
> docker/unbound[567]: [1586692885] unbound[1:0] info: 192.168.4.5
> _25._tcp.do.havedane.net. TLSA IN#015
> Hat jemand das schon mal gehabt?
>
>
> Am Samstag, den 11.04.2020, 19:21 +0200 schrieb Christian:
> > Hallo Michael,
> > ich habe nun mal havedane.net auf dane-only gesetzt. Und siehe da,
> > endlich meckert Postfix.
> > Apr 11 19:14:39 server docker/postfix/smtp[904]: warning: TLS
> > policy lookup for do.havedane.net/do.havedane.net: non DNSSEC
> > destinationApr 11 19:14:39 server docker/postfix/smtp[904]:
> > warning: TLS policy lookup for do.havedane.net/do.havedane.net: non
> > DNSSEC destination
> > Also scheint es tatsächlich ein Problem mit dem DNS Resolver zu
> > sein und der Test ob ich DNSSEC Informationen im System bekomme
> > nicht aussagekräftig zu sein.Nicht das ich nun ein Lösung
> > wüsste.... :-D
> >
> > Am Samstag, den 11.04.2020, 18:58 +0200 schrieb Christian:
> > > Hallo Michael,
> > > da haben sich unsere E-Mails überschnitten.
> > > Ich laufe in einem Docker Setup und habe einen eigenen Unbound
> > > container laufen. Der ist explizit Postfix zugeordnet. Er ist
> > > also nicht auf localhost, sondern a la Docker auf 127.0.0.11. So
> > > ist es auch in der resolv.conf eingetragen.
> > > Nach der verlinkten Doku nutzt Postfix den System-Resolver. Ich
> > > hab es verstanden als: es muss kein localhost sein, wäre nur aus
> > > Sicherheitsgründen wünschenswert.
> > > Ein Test aus dem Postfix Container sieht dann wie unten angehängt
> > > aus. Da es immer schwer ist einen Unbound zu identifizieren, kann
> > > ich nur mit dem Cache arbeiten. Erneuter Aufruf der selben
> > > Records ergibt eine Query time von 0ms.
> > > Das sollte eigentlich nur ein lokaler Unbound schaffen, oder?
> > > Kennst Du einen Weg um die Ausführung des DANE Tests sichtbar zu
> > > machen?
> > >
> > > / # dig _25._tcp.do.havedane.net TLSA +dnssec
> > > ; <<>> DiG 9.14.8 <<>> _25._tcp.do.havedane.net TLSA +dnssec;;
> > > global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY,
> > > status: NOERROR, id: 16107;; flags: qr rd ra ad; QUERY: 1,
> > > ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> > > ;; OPT PSEUDOSECTION:; EDNS: version: 0, flags: do; udp: 4096;;
> > > QUESTION SECTION:;_25._tcp.do.havedane.net.	IN	TLSA
> > > ;; ANSWER SECTION:_25._tcp.do.havedane.net. 3600	IN	TLSA	2
> > > 1 1 27B694B51D1FEF8885372ACFB39193759722B736B0426864DC1C79D0
> > > 651FEF73_25._tcp.do.havedane.net. 3600	IN	TLSA	3 1 1
> > > 553ACF88F9EE18CCAAE635CA540F32CB84ACA77C47916682BCB542D5
> > > 1DAA871F_25._tcp.do.havedane.net. 3600	IN	RRSIG	TLSA 8 5
> > > 3600 20200423000000 20200402000000 42609 havedane.net.
> > > OH0RwDScHtrf8z2GNJ4KnRi+fjTvcJJUyke0eA94IntRn4qDCzRVz4/Q
> > > bfojdMGSsKg0KqBVuCdWzwI2Tv2mPQVGJW3uIcBllwkHAJd0JSLZjLpg
> > > jR7r9ew/KrI/G31cuZn3TLbzW44b/VD4mmDjsZ71XyRUrSuZRE0pYAyo 8nE=
> > > ;; Query time: 112 msec;; SERVER: 127.0.0.11#53(127.0.0.11);;
> > > WHEN: Sat Apr 11 18:47:35 CEST 2020;; MSG SIZE  rcvd: 319
> > > Am Samstag, den 11.04.2020, 18:28 +0200 schrieb Michael Ströder:
> > > > On 4/11/20 6:03 PM, Walter H. wrote:
> > > > On 11.04.2020 14:35, Christian wrote:
> > > >
> > > > Bei DANE hätte ich nun erwartet, dass dies keine, bzw.
> > > > geringere Rollespielt.
> > > > genau das ist ein Fehler, den viele machen; DANE ist nur ein
> > > > Add-on, dasbereits valididierte zu verifizieren;
> > > > Woraus schliesst Du das?Das Gegenteil ist der Fall. DANE ist
> > > > explizit angetreten, X.509 komplettzu ersetzen.
> > > > Zum ursprünglichen Problem:
> > > > http://www.postfix.org/TLS_README.html#client_tls_dane
> > > > "Therefore, it is strongly recommended (DANE security guarantee
> > > > voidotherwise) that each MTA run a local DNSSEC-validating
> > > > recursiveresolver [..] listening on the loopback interface, and
> > > > that the systembe configured to use only this local
> > > > nameserver."
> > > > Frage an den Original-Poster:Wird von Deinem postfix wirklich
> > > > ein lokaler DNS-Resolver auf 127.0.0.1(oder ::1) benutzt?
> > > > Ciao, Michael.
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://de.postfix.org/pipermail/postfix-users/attachments/20200413/a004c805/attachment.htm>