On Sun, Apr 12, 2020 at 04:20:48PM +0200, Christian wrote:
> I am running in a docker setup (alpine based on debian host) with my own
> unbound DNS resolver.
What is the content of /etc/resolv.conf?
> I started to check if I have problems in my DNSSEC checks. running a
> "dig com. SOA +dnssec" from my postfix container, I get
> ; <<>> DiG 9.14.8 <<>> com. SOA +dnssec
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> ;; SERVER: 127.0.0.11#53(127.0.0.11)
Ok, the server at 127.0.0.11 appears to support DNSSEC validation.
Was the test in fact run in the same container as Postfix?
> Apr 11 19:14:39 server docker/postfix/smtp[904]: warning: TLS policy
> lookup for do.havedane.net/do.havedane.net: non DNSSEC destination
> Apr 11 19:14:39 server docker/postfix/smtp[904]: warning: TLS policy
> lookup for do.havedane.net/do.havedane.net: non DNSSEC destination
But Postfix does not see the AD bit, so the most plausible explanation
is that it is not using the same resolver. What are the file
permissions on /etc/resolv.conf?
> Hence confirming my theory, that DNSSEC is not properly checked.
> Next thing I did is monitoring the DNS queries in unbound and found,
> that onyl MX, A and AAAA is requested:
>
> ##########
> Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0]
> info: 192.168.4.5 do.havedane.net. MX IN#015
> Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0]
> info: 192.168.4.5 do.havedane.net. A IN#015
> Apr 12 14:00:56 server docker/unbound[567]: [1586692856] unbound[1:0]
> info: 192.168.4.5 do.havedane.net. AAAA IN#015
Yes, as expected when the A records come back with the AD bit not set.
> I read in the documentation, that apparently postfix checks with
> certain FLAGS (RES_USE_DNSSEC and RES_USE_EDNS0) in the MX request for
> DNSSEC validity, however I do not know how to debug if that is
> happening. Hence I am stuck now.
You can capture the DNS traffic into PCAP file, then "Ctrl-C" when
you've sent all the packets of interest. Replace "lo" with the
appropriate interface name if not "lo". I used "-s512" since all the
data of interest (qname, flags, ...) easily fits into the first 512
bytes.
# tcpdump -s512 -w /tmp/dns.pcap -i lo udp port 53
^C
The PCAP file can be analyzed with "tshark -nr /tmp/dns.pcap -V"
You can run "posttls-finger -c -Lsummary do.havedane.net" (if installed)
to generate the DNS traffic of interest.
$ posttls-finger -d sha256 -c -Lsummary,certmatch do.havedane.net
posttls-finger: using DANE RR: _25._tcp.do.havedane.net IN TLSA 2 1 1
27:B6:94:B5:1D:1F:EF:88:85:37:2A:CF:B3:91:93:75:97:22:B7:36:B0:42:68:64:DC:1C:79:D0:65:1F:EF:73
posttls-finger: using DANE RR: _25._tcp.do.havedane.net IN TLSA 3 1 1
55:3A:CF:88:F9:EE:18:CC:AA:E6:35:CA:54:0F:32:CB:84:AC:A7:7C:47:91:66:82:BC:B5:42:D5:1D:AA:87:1F
posttls-finger: do.havedane.net[2001:1af8:4700:a118:90::7c0]:25: depth=1
matched trust anchor public-key sha256
digest=27:B6:94:B5:1D:1F:EF:88:85:37:2A:CF:B3:91:93:75:97:22:B7:36:B0:42:68:64:DC:1C:79:D0:65:1F:EF:73
posttls-finger: do.havedane.net[2001:1af8:4700:a118:90::7c0]:25: depth=0
chain is trust-anchor signed
posttls-finger: do.havedane.net[2001:1af8:4700:a118:90::7c0]:25: depth=0
matched end entity public-key sha256
digest=55:3A:CF:88:F9:EE:18:CC:AA:E6:35:CA:54:0F:32:CB:84:AC:A7:7C:47:91:66:82:BC:B5:42:D5:1D:AA:87:1F
posttls-finger: do.havedane.net[2001:1af8:4700:a118:90::7c0]:25: Matched
subjectAltName: do.havedane.net
posttls-finger: do.havedane.net[2001:1af8:4700:a118:90::7c0]:25 CommonName
do.havedane.net
posttls-finger: do.havedane.net[2001:1af8:4700:a118:90::7c0]:25:
subject_CN=do.havedane.net, issuer_CN=Fort-Funston CA,
fingerprint=AF:BE:72:A5:16:C2:48:65:6D:20:0E:B0:F3:C8:DF:A2:F1:FC:5B:C6:E3:D8:85:48:30:C6:E2:DA:40:28:C9:CC,
pkey_fingerprint=55:3A:CF:88:F9:EE:18:CC:AA:E6:35:CA:54:0F:32:CB:84:AC:A7:7C:47:91:66:82:BC:B5:42:D5:1D:AA:87:1F
posttls-finger: Verified TLS connection established to
do.havedane.net[2001:1af8:4700:a118:90::7c0]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> postconf -n (domain replaced by XXX)
Are these the docker settings?
> debug_peer_list = havedane.net,127.0.0.1,127.0.0.11,192.168.4.254
There's no reason to include the nameserver in debug_peer_list.
> smtp_tls_security_level = dane
> smtp_dns_support_level = dnssec
> smtp_host_lookup = dns
Good, these are needed, though the last one is a default, and
can be (is best) left out.
> tls_high_cipherlist =
> !aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:
> !SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA
This is much too explicit. You're cargo-culting bad advice from some
ill-considered "HOW-TO". The Postfix defaults are better, any (minimal,
previously recommended on this list) exclusions you want to add are best
done with:
smtp_tls_exclude_ciphers =
smtp_tls_mandatory_exclude_ciphers =
smtpd_tls_exclude_ciphers =
smtpd_tls_mandatory_exclude_ciphers =
Excluding "ECDSA" is most unwise, especially if you're planning to
support DANE.
> smtp unix - - n - - smtp
> relay unix - - n - - smtp
Are these the docker settings?
--
Viktor.
