Hi,
I'm already running two DANE enabled MTAs and now tried to enable another one. I think I did all the same (the certificate is currently a self signed one and the hostname does not match the certificate though). But I read the Postfix documentation a few times now and I don't think this is the issue.
Anyway testing sending from one of my already enabled Postfix systems to the new one I only get "Anonymous TLS connection established" while the DANE validator https://dane.sys4.de/smtp reports everything green for the target.
Any ideas? (target is mail.tismail.net)
Thanks, Wolfgang
On Fri, Jan 30, 2015 at 08:54:48AM +0100, Wolfgang Rosenauer wrote:
Anyway testing sending from one of my already enabled Postfix systems to the new one I only get "Anonymous TLS connection established" while the DANE validator https://dane.sys4.de/smtp reports everything green for the target.
Any ideas? (target is mail.tismail.net)
$ postconf mail_version mail_version = 3.0-20150129
$ posttls-finger -c -Lsummary tismail.net posttls-finger: Verified TLS connection established to mail.tismail.net[185.27.180.68]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
(By the way tismail2.net is broken, publishes TLSA RRs, but does not offer STARTTLS).
Your DNS resolver is likely returning non-DNSSEC results. Take this question to the Postfix-users list.
* Your smtp(8) delivery agent may be chrooted, and the resolv.conf file in the chroot jail may differ from the one in /etc, in any case one or the other may not be pointing at a loopback DNSSEC validating resolver.
* Your Postfix configuration settings may be wrong.
smtp_dns_support_level = dnssec smtp_tls_security_level = dane
* Your Postfix version may not be 2.11.3 or later.
* Your C library may not return the "AD" bit in DNSSEC replies (OpenBSD seems to have this problem).
When asking questions on the Postfix-users list, don't forget to include all relevant logging, your "postconf -n" output (not mangled by HTML email and without rewrapping of lines), all relevant master.cf entries, the resolv.conf file content in and out of chroot, relevant TLS policy table entries, the Postfix version, the OS version, ...
Don't provide needlessly verbose logs, just the basics with TLS loglevel=1.
http://www.postfix.org/DEBUG_README.html#mail
Am 30.01.2015 um 09:10 schrieb Viktor Dukhovni:
On Fri, Jan 30, 2015 at 08:54:48AM +0100, Wolfgang Rosenauer wrote:
$ postconf mail_version mail_version = 3.0-20150129 $ posttls-finger -c -Lsummary tismail.net posttls-finger: Verified TLS connection established to mail.tismail.net[185.27.180.68]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
ok, so this confirms that the server is more or less set up correctly. thanks.
(By the way tismail2.net is broken, publishes TLSA RRs, but does not offer STARTTLS).
Yes, it's not yet in production and Postfix config is missing there. Once I got the first one (what apparently is fine) up, I'll complete the other one.
Your DNS resolver is likely returning non-DNSSEC results. Take this question to the Postfix-users list.
I will. Interestingly I see "Verified" to other targets (like mailbox.org and others).
In any case thanks for the check and I'll report to the Postfix list.
Wolfgang
Am 30.01.2015 um 09:10 schrieb Viktor Dukhovni:
- Your C library may not return the "AD" bit in DNSSEC replies
(OpenBSD seems to have this problem).
This may also be the case if your resolver is also authorative for your domain. Then it wont do recursive validation and will not include the AD flag.
There is a LD_PRELOAD wrapper called cwrap/resolv_wrapper which allows to overwrite the resolver per process without changing global resolv.conf:
It was written for samba. I had to add the following patch to make it work with postfix:
https://markusbenning.de/tmp/0001-res_-n-xxx-functions-should-use-global-_re...
Markus
Am 31.01.2015 um 12:29 schrieb Markus Benning:
Am 30.01.2015 um 09:10 schrieb Viktor Dukhovni:
- Your C library may not return the "AD" bit in DNSSEC replies
(OpenBSD seems to have this problem).
This may also be the case if your resolver is also authorative for your domain. Then it wont do recursive validation and will not include the AD flag.
Thanks for that hint. I guess this is exactly the issue. The recursive resolver for the smtp client is actually indeed also the authoritative dns for the target domain. This special case came absolutely unexpected to me though.
Wolfgang
On Sat, Jan 31, 2015 at 04:02:00PM +0100, Wolfgang Rosenauer wrote:
Am 31.01.2015 um 12:29 schrieb Markus Benning:
Am 30.01.2015 um 09:10 schrieb Viktor Dukhovni:
- Your C library may not return the "AD" bit in DNSSEC replies
(OpenBSD seems to have this problem).
This may also be the case if your resolver is also authorative for your domain. Then it wont do recursive validation and will not include the AD flag.
Thanks for that hint. I guess this is exactly the issue. The recursive resolver for the smtp client is actually indeed also the authoritative dns for the target domain. This special case came absolutely unexpected to me though.
Not surprising that it did not occur to you, it is unfortunately not documented.
I've never tested a recursive resolver that is also authoritative for DNSSEC signed domains .
Based on long-standing advice from DJB, that is now considered "best pratice", I always separate the authoritative and recursive DNS servers. On my mail server (which is also the primary nameserver for my domain) I have:
* loopback:53 - Recursive, validating unbound resolver, authoritative only for localhost and loopback addresses:
interface: 127.0.0.1 interface: ::1 do-not-query-address: 127.0.0.0/8 do-not-query-address: ::1 cache-max-ttl: 14400 max-udp-size: 8192 minimal-responses: yes module-config: "validator iterator" auto-trust-anchor-file: "keys/root.key"
local-zone: "localhost." static local-zone: "127.in-addr.arpa." static local-zone: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." static domain-insecure: "localhost." domain-insecure: "127.in-addr.arpa." domain-insecure: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." local-data: "localhost. IN A 127.0.0.1" local-data: "localhost. IN AAAA ::1" local-data-ptr: "127.0.0.1 localhost." local-data-ptr: "::1 localhost."
* <public-address>:53 - Authoritative BIND 9.10p1 server, which serves a few domains.
options { ...
# DNSSEC, with 14 day signatures, the secondary expire # time in the SOA should be at most 7 days. Otherwise, # secondaries might in some cases serve already expired # data. # dnssec-enable yes; sig-validity-interval 14;
# Authoritative service only, listen on external v4/v6 # addresses, but not the loopback ("unbound" resolver). # recursion no; listen-on { <public ip range>; }; listen-on-v6 { <public ipv6 range>; }; ... }
The /etc/resolv.conf file lists only 127.0.0.1, so all queries for my own domain go to "unbound", which does the validation, and sets the AD bit the same way as for "remote" domains, since for "unbound" all domains are "remote".
Hello Wolfgang,
Wolfgang Rosenauer writes:
Thanks for that hint. I guess this is exactly the issue. The recursive resolver for the smtp client is actually indeed also the authoritative dns for the target domain. This special case came absolutely unexpected to me though.
If the DNS server that is the owner of the data (the authoritative server) would also do the DNSSEC verification, not much security would be gained. It would be like having the treasurer and the auditor being the same person, not secure.
With DNSSEC, the validating resolver cannot be authoritative. A DNS server that is authoritative will respond with an AA (Authoritative Answer) flag, but never with AD (Authenticated Data).
I wrote an blog article on this topic some while ago: http://strotmann.de/roller/dnsworkshop/entry/dns_name_resolution_design_for
Best regard
Carsten
participants (4)
-
Carsten Strotmann (sys4) -
Markus Benning -
Viktor Dukhovni -
Wolfgang Rosenauer