Outgoing DANE ignoriert fehlerhafte DANE Einträge

[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/20200411/27dfed29/attachment-0001.htm>