non DNSSEC destination?

[Peter Bauer]

Hello,

I tried to run DANE on my postfix 2.11.0 server, but it does not make DANE
verifications by connecting on different servers which have officially
switched to DNSSEC & DANE.

I tested it with the following configuration:

smtp_use_tls = yes
smtp_tls_fingerprint_digest = sha1
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_note_starttls_offer = yes
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

# cat tls_policy
trashmail.com dane-only

I get the following error in the logging files:
Aug 31 08:57:12 archivum postfix/smtp[23663]: TLS policy lookup for
trashmail.com/smtp.trashmail.com: non DNSSEC destination
Aug 31 08:57:12 archivum postfix/smtp[23663]: TLS policy lookup for
trashmail.com/smtp.trashmail.com: non DNSSEC destination
Aug 31 08:57:12 archivum postfix/smtp[23663]: TLS policy lookup for
trashmail.com/smtp2.trashmail.com: non DNSSEC destination
Aug 31 08:57:12 archivum postfix/smtp[23663]: TLS policy lookup for
trashmail.com/smtp2.trashmail.com: non DNSSEC destination

I can't understand this result as
http://dnssec-debugger.verisignlabs.com/trashmail.com
says that all is fine.

And posttls-finger does not show anything about DNSSEC or DANE:
# posttls-finger -t30 -T180 -c -L verbose,summary trashmail.com
posttls-finger: initializing the client-side TLS engine
posttls-finger: setting up TLS connection to
smtp.trashmail.com[88.198.11.51]:25
posttls-finger: smtp.trashmail.com[88.198.11.51]:25: TLS cipher list
"aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"
posttls-finger: smtp.trashmail.com[88.198.11.51]:25: depth=1 verify=0
subject=/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Ferraro
Ltd./OU=SMTP/CN=Ferraro Ltd. SMTP CA/emailAddress=***@ferraro.net
posttls-finger: smtp.trashmail.com[88.198.11.51]:25: depth=1 verify=1
subject=/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Ferraro
Ltd./OU=SMTP/CN=Ferraro Ltd. SMTP CA/emailAddress=***@ferraro.net
posttls-finger: smtp.trashmail.com[88.198.11.51]:25: depth=0 verify=1
subject=/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Ferraro
Ltd./OU=TrashMail.net/CN=trashmail.net/emailAddress=***@ferraro.net
posttls-finger: certificate verification failed for
smtp.trashmail.com[88.198.11.51]:25: untrusted issuer
/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Ferraro
Ltd./OU=SMTP/CN=Ferraro Ltd. SMTP CA/emailAddress=***@ferraro.net
posttls-finger: smtp.trashmail.com[88.198.11.51]:25:
subject_CN=trashmail.net, issuer_CN=Ferraro Ltd. SMTP CA,
fingerprint=26:D1:F9:93:4F:EE:A3:52:16:F5:5D:22:98:6B:4F:30:33:5F:1F:F1,
pkey_fingerprint=4A:3F:63:64:AD:A9:E5:D2:6B:C9:A7:8C:E2:89:FA:F6:D0:A7:94:16
posttls-finger: Untrusted TLS connection established to
smtp.trashmail.com[88.198.11.51]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

What I'm doing wrong?

[Patrick Ben Koetter]

Peter,

Post by Peter Bauer
Hello,
I tried to run DANE on my postfix 2.11.0 server, but it does not make DANE
verifications by connecting on different servers which have officially
switched to DNSSEC & DANE.

Postfix can only use DANE verification, if the underlying system is able to
tell DNSSEC enabled domains from regular DNS domains.

Does your resolver suppport DNSSEC? Try this query and watch the 'flags'
section in the outpout. You should see an 'ad' flag as pointed out in the
example below:

***@x240:~$ dig SOA +dnssec sys4.de

; <<>> DiG 9.9.5-3-Ubuntu <<>> SOA +dnssec sys4.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61650
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 3

^^

If you don't see it, you resolver cannot authenticated DNSSEC enabled domains.
Then you need to change that.

Post by Peter Bauer
smtp_use_tls = yes
smtp_tls_fingerprint_digest = sha1
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_tls_note_starttls_offer = yes
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
# cat tls_policy
trashmail.com dane-only
Aug 31 08:57:12 archivum postfix/smtp[23663]: TLS policy lookup for
trashmail.com/smtp.trashmail.com: non DNSSEC destination
Aug 31 08:57:12 archivum postfix/smtp[23663]: TLS policy lookup for
trashmail.com/smtp.trashmail.com: non DNSSEC destination
Aug 31 08:57:12 archivum postfix/smtp[23663]: TLS policy lookup for
trashmail.com/smtp2.trashmail.com: non DNSSEC destination
Aug 31 08:57:12 archivum postfix/smtp[23663]: TLS policy lookup for
trashmail.com/smtp2.trashmail.com: non DNSSEC destination
I can't understand this result as
http://dnssec-debugger.verisignlabs.com/trashmail.com
says that all is fine.
# posttls-finger -t30 -T180 -c -L verbose,summary trashmail.com
posttls-finger: initializing the client-side TLS engine
posttls-finger: setting up TLS connection to
smtp.trashmail.com[88.198.11.51]:25
posttls-finger: smtp.trashmail.com[88.198.11.51]:25: TLS cipher list
posttls-finger: smtp.trashmail.com[88.198.11.51]:25: depth=1 verify=0
subject=/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Ferraro
posttls-finger: smtp.trashmail.com[88.198.11.51]:25: depth=1 verify=1
subject=/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Ferraro
posttls-finger: smtp.trashmail.com[88.198.11.51]:25: depth=0 verify=1
subject=/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Ferraro
posttls-finger: certificate verification failed for
smtp.trashmail.com[88.198.11.51]:25: untrusted issuer
/C=DE/ST=Baden-Wuerttemberg/L=Stuttgart/O=Ferraro
subject_CN=trashmail.net, issuer_CN=Ferraro Ltd. SMTP CA,
fingerprint=26:D1:F9:93:4F:EE:A3:52:16:F5:5D:22:98:6B:4F:30:33:5F:1F:F1,
pkey_fingerprint=4A:3F:63:64:AD:A9:E5:D2:6B:C9:A7:8C:E2:89:FA:F6:D0:A7:94:16
posttls-finger: Untrusted TLS connection established to
smtp.trashmail.com[88.198.11.51]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
What I'm doing wrong?
--
Best regards,
Peter Bauer
Linux & UNIX developper

[Ralf Hildebrandt]

Post by Patrick Ben Koetter
If you don't see it, you resolver cannot authenticated DNSSEC enabled domains.
Then you need to change that.

One solution would be to install "unbound" as local caching resolver
and then let resolv.conf point to 127.0.0.1

[Viktor Dukhovni]

Post by Ralf Hildebrandt

Post by Patrick Ben Koetter
If you don't see it, you resolver cannot authenticated DNSSEC enabled domains.
Then you need to change that.

One solution would be to install "unbound" as local caching resolver
and then let resolv.conf point to 127.0.0.1

As documented, DANE support *requires* a DNSSEC validating recursive
resolver installed on the MTA (unbound or BIND) and /etc/resolv.conf
*must* list only 127.0.0.1.

[Benny Pedersen]

Post by Ralf Hildebrandt

Post by Patrick Ben Koetter
Then you need to change that.

One solution would be to install "unbound" as local caching resolver
and then let resolv.conf point to 127.0.0.1

Post bind9 options section, maybe its needs change to enable it?

man named.conf is it enabled Ralf?

[Peter Bauer]

Post by Patrick Ben Koetter
; <<>> DiG 9.9.5-3-Ubuntu <<>> SOA +dnssec sys4.de
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61650
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 3
^^
If you don't see it, you resolver cannot authenticated DNSSEC enabled domains.
Then you need to change that.

I see this:
# dig SOA +dnssec sys4.de

; <<>> DiG 9.9.5-3-Ubuntu <<>> SOA +dnssec sys4.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22031
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1

As resolver I have Bind:
# cat /etc/resolv.conf
nameserver 10.0.3.1

And on 10.0.3.1 I have this:
forwarders {
213.133.98.98;
213.133.99.99;
213.133.100.100;
};

//========================================================================
// If BIND logs error messages about the root key being
expired,
// you will need to update your keys. See
https://www.isc.org/bind-keys
//========================================================================
dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;

Is it possible that forwarders has more priority than the DNSSEC
options of bind?

[Peter Bauer]

Post by Patrick Ben Koetter
; <<>> DiG 9.9.5-3-Ubuntu <<>> SOA +dnssec sys4.de
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61650
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 3
^^
If you don't see it, you resolver cannot authenticated DNSSEC enabled domains.
Then you need to change that.

I think I found the issue:
LXC has started its own DNS server, and my LXC guest is not using my
bind9 server, but the one provided by LXC:
lxc-dns+ 1848 1 0 Aug22 ? 00:09:45 dnsmasq -u lxc-dnsmasq
--strict-order --bind-interfaces --pid-file=/run/lxc/dnsmasq.pid
--conf-file= --listen-address 10.0.3.1 --dhcp-range
10.0.3.100,10.0.3.254 --dhcp-lease-max=253 --dhcp-no-override
--except-interface=lo --interface=lxcbr0
--dhcp-leasefile=/var/lib/misc/dnsmasq.lxcbr0.leases
--dhcp-authoritative


I will check how to change the configuration of the LXC DNS server
that it resolves too DNSSEC or I will update my /etc/resolve.conf file
on the LXC guest system to ask directly my bind server.

Thanks very much for your helps.

[/dev/rob0]

Post by Peter Bauer
# cat /etc/resolv.conf
nameserver 10.0.3.1
forwarders {
213.133.98.98;
213.133.99.99;
213.133.100.100;
};

Do you control these forwarders? If not you probably do not want
them. As you seem to be running on a virtual host, I probably would
run named on a physical host at the same site, or perhaps on another
virtual host. Then simply point the resolv.conf at it, and do away
with this instance of named.

Post by Peter Bauer
dnssec-enable yes;

This is a default setting; you can take it out. It means your named
understands the DNSSEC RRtypes.

Post by Peter Bauer
dnssec-validation auto;

This is what actually does the work.

Post by Peter Bauer
dnssec-lookaside auto;

This does some of the work too, unfortunately; 4 years after the
signing of the root zone, DLV is still too important.

Post by Peter Bauer
Is it possible that forwarders has more priority than the DNSSEC
options of bind?

You're either forwarding first or only, with global forwarders. If
your forwarders don't support DNSSEC, you get non-DNSSEC answers.

There are other very good reasons why not to use forwarders outside
your control, although if they do support DNSSEC they can't get away
with spoofing records in signed zones.

Post by Peter Bauer
I will check how to change the configuration of the LXC DNS server
that it resolves too DNSSEC or I will update my /etc/resolve.conf
file on the LXC guest system to ask directly my bind server.

Very recent versions of dnsmasq do support DNSSEC, but indeed, just
point at your non-forwarding named server and all is well.