<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>Hallo zusammen,</div><div><br></div><div>um dies abzuschließen: Das Problem lag an der Nutzung von musl-libc in Alpine.</div><div>Die Implementierung kann die nötigen Flags nicht an den resolver weiterleiten und Postfix funktioniert entsprechend nicht auf musl-libc.</div><div><br></div><div>Ich war dazu mit Viktor Dukhovni im Austausch, er hat sich auch den Code angeschaut und einige andere fehlende Implementierungen in musl-libc gefunden.</div><div>Sein abschließendes Verdict: "DO NOT run Postfix over musl-libc."</div><div><br></div><div>Damit auch nicht auf Alpine.</div><div><br></div><div>Danke an alle die geholfen haben!</div><div><br></div><div>Am Sonntag, den 12.04.2020, 14:14 +0200 schrieb Christian:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hallo zusammen,</div><div><br></div><div>nach weiteren Tests, habe ich nun die queries im unbound mitgeschrieben. Postfix kontaktiert den richtigen resolver, allerdings scheint kein TLSA Record angefragt zu werden:</div><div><br></div><div>Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. MX IN#015</div><div>Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. A IN#015</div><div>Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0] info: 192.168.4.5 do.havedane.net. AAAA IN#015</div><div></div><div><br></div><div>Ich hätte auch eine Abfrage des TLSA Records erwartet (Hier mal mit dig vom Postfix host angefordert)</div><div>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</div><div><br></div><div>Hat jemand das schon mal gehabt?</div><div><br></div><div><br></div><div><br></div><div>Am Samstag, den 11.04.2020, 19:21 +0200 schrieb Christian:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hallo Michael,</div><div><br></div><div>ich habe nun mal havedane.net auf dane-only gesetzt. Und siehe da, endlich meckert Postfix.</div><div><br></div><div>Apr 11 19:14:39 server docker/postfix/smtp[904]: warning: TLS policy lookup for do.havedane.net/do.havedane.net: non DNSSEC destination</div><div>Apr 11 19:14:39 server docker/postfix/smtp[904]: warning: TLS policy lookup for do.havedane.net/do.havedane.net: non DNSSEC destination</div><div><br></div><div>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.</div><div>Nicht das ich nun ein Lösung wüsste.... :-D</div><div><br></div><div><br></div><div>Am Samstag, den 11.04.2020, 18:58 +0200 schrieb Christian:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>Hallo Michael,</div><div><br></div><div>da haben sich unsere E-Mails überschnitten.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Das sollte eigentlich nur ein lokaler Unbound schaffen, oder?</div><div><br></div><div>Kennst Du einen Weg um die Ausführung des DANE Tests sichtbar zu machen?</div><div><br></div><div><br></div><div>/ # dig _25._tcp.do.havedane.net TLSA +dnssec</div><div><br></div><div>; <<>> DiG 9.14.8 <<>> _25._tcp.do.havedane.net TLSA +dnssec</div><div>;; global options: +cmd</div><div>;; Got answer:</div><div>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16107</div><div>;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1</div><div><br></div><div>;; OPT PSEUDOSECTION:</div><div>; EDNS: version: 0, flags: do; udp: 4096</div><div>;; QUESTION SECTION:</div><div>;_25._tcp.do.havedane.net.   IN      TLSA</div><div><br></div><div>;; ANSWER SECTION:</div><div>_25._tcp.do.havedane.net. 3600     IN      TLSA    2 1 1 27B694B51D1FEF8885372ACFB39193759722B736B0426864DC1C79D0 651FEF73</div><div>_25._tcp.do.havedane.net. 3600    IN      TLSA    3 1 1 553ACF88F9EE18CCAAE635CA540F32CB84ACA77C47916682BCB542D5 1DAA871F</div><div>_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=</div><div><br></div><div>;; Query time: 112 msec</div><div>;; SERVER: 127.0.0.11#53(127.0.0.11)</div><div>;; WHEN: Sat Apr 11 18:47:35 CEST 2020</div><div>;; MSG SIZE  rcvd: 319</div><div><br></div><div>Am Samstag, den 11.04.2020, 18:28 +0200 schrieb Michael Ströder:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>On 4/11/20 6:03 PM, Walter H. wrote:</pre><pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"></blockquote></pre><pre>On 11.04.2020 14:35, Christian wrote:</pre><pre><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"></blockquote></pre><pre><br></pre><pre>Bei DANE hätte ich nun erwartet, dass dies keine, bzw. geringere Rolle</pre><pre>spielt.</pre><pre></pre><pre><br></pre><pre>genau das ist ein Fehler, den viele machen; DANE ist nur ein Add-on, das</pre><pre>bereits valididierte zu verifizieren;</pre><pre></pre><pre><br></pre><pre>Woraus schliesst Du das?</pre><pre>Das Gegenteil ist der Fall. DANE ist explizit angetreten, X.509 komplett</pre><pre>zu ersetzen.</pre><pre><br></pre><pre>Zum ursprünglichen Problem:</pre><pre><br></pre><pre><a href="http://www.postfix.org/TLS_README.html#client_tls_dane">http://www.postfix.org/TLS_README.html#client_tls_dane</a></pre><pre><br></pre><pre>"Therefore, it is strongly recommended (DANE security guarantee void</pre><pre>otherwise) that each MTA run a local DNSSEC-validating recursive</pre><pre>resolver [..] listening on the loopback interface, and that the system</pre><pre>be configured to use only this local nameserver."</pre><pre><br></pre><pre>Frage an den Original-Poster:</pre><pre>Wird von Deinem postfix wirklich ein lokaler DNS-Resolver auf 127.0.0.1</pre><pre>(oder ::1) benutzt?</pre><pre><br></pre><pre>Ciao, Michael.</pre><pre><br></pre></blockquote>
</blockquote>
</blockquote>
</blockquote></body></html>