This is on mantic, systemd-resolved 253.5-1ubuntu6.1

** Tags added: mantic

** Description changed:

- This issue surface when researching the issue that Postfix on my system
+ This issue surfaced when researching the issue that Postfix on my system
  (with DANE enabled) deferred mail deliveries with 100s of this warning
  in the log:
  
-     Warning: DANE TLSA lookup problem: Host or domain name not found.
+     Warning: DANE TLSA lookup problem: Host or domain name not found.
  Name service error for name=_25._tcp.cluster5.us.messagelabs.com
  type=TLSA: Host not found, try again
  
  The DNS resolver on my machine was pointing at the systemd-resolved
  stub:
  
-     $ cat /etc/resolv.conf | grep nameserver
-     nameserver 127.0.0.53
+     $ cat /etc/resolv.conf | grep nameserver
+     nameserver 127.0.0.53
  
-     $ resolvectl status
-     Global
-         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported
-         resolv.conf mode: stub
+     $ resolvectl status
+     Global
+         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported
+         resolv.conf mode: stub
  
  Note DNSSEC is enabled (else Postfix couldn't be doing DANE). Now if I
  query the TLSA record for the messagelab server, I get a SERVFAIL from
  the stub resolver:
  
-     $ delv +dnssec _25._tcp.cluster5.us.messagelabs.com TLSA
-     ;; resolution failed: SERVFAIL
+     $ delv +dnssec _25._tcp.cluster5.us.messagelabs.com TLSA
+     ;; resolution failed: SERVFAIL
  
  Whereas if I query my upstream DNS or Google DNS, I get a DNSSEC
  validated (negative) response:
  
-     $ delv @8.8.8.8 +dnssec _25._tcp.cluster5.us.messagelabs.com TLSA
-     ;; resolution failed: ncache nxrrset
-     ; negative response, fully validated
-     ; _25._tcp.cluster5.us.messagelabs.com. 299 IN \-TLSA ;-$NXRRSET
-     ; _25._tcp.cluster5.us.messagelabs.com. RRSIG NSEC ...
-     ; _25._tcp.cluster5.us.messagelabs.com. NSEC 
\000._25._tcp.cluster5.us.messagelabs.com. A PTR HINFO MX TXT RP AAAA SRV NAPTR 
SSHFP RRSIG NSEC SVCB HTTPS SPF IXFR AXFR CAA
-     ; messagelabs.com. SOA ns-1714.awsdns-22.co.uk. 
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
-     ; messagelabs.com. RRSIG SOA ...
+     $ delv @8.8.8.8 +dnssec _25._tcp.cluster5.us.messagelabs.com TLSA
+     ;; resolution failed: ncache nxrrset
+     ; negative response, fully validated
+     ; _25._tcp.cluster5.us.messagelabs.com. 299 IN \-TLSA ;-$NXRRSET
+     ; _25._tcp.cluster5.us.messagelabs.com. RRSIG NSEC ...
+     ; _25._tcp.cluster5.us.messagelabs.com. NSEC 
\000._25._tcp.cluster5.us.messagelabs.com. A PTR HINFO MX TXT RP AAAA SRV NAPTR 
SSHFP RRSIG NSEC SVCB HTTPS SPF IXFR AXFR CAA
+     ; messagelabs.com. SOA ns-1714.awsdns-22.co.uk. 
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
+     ; messagelabs.com. RRSIG SOA ...
  
  I assume Postfix (with smtp_tls_security_level = dane i.e.
  "Opportunistic DANE") deals with the negative response by downgrading to
  "encrypt", whereas the SERVFAIL response makes it refuse to connect
  altogether.
  
  My workaround was to switch from the systemd-resolved stub resolver to
  the upstream servers. In /etc/systemd/resolved.conf set:
  
-     DNS=... your upstream servers if not already given through DHCP ...
-     DNSStubListener=no
+     DNS=... your upstream servers if not already given through DHCP ...
+     DNSStubListener=no
  
  Then restart the service and restart Postfix if it is chrooted (so the
  new /etc/resolv.conf gets copied into the chroot):
  
-     systemctl restart systemd-resolved
-     systemctl restart postfix
+     systemctl restart systemd-resolved
+     systemctl restart postfix
  
  I am not sure if this could be considered a Postfix bug as well (it
  could consider a SERVFAIL on a TLSA record the same as a negative), but
  surely it seems to me the systemd-resolved stub resolver should not
  return the SERVFAIL here.
  
  For more background on this bug report, please see
  https://serverfault.com/a/1158198/299950

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2062542

Title:
  systemd-resolved stub gives SERVFAIL for DNSSEC negative response

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  This issue surfaced when researching the issue that Postfix on my
  system (with DANE enabled) deferred mail deliveries with 100s of this
  warning in the log:

      Warning: DANE TLSA lookup problem: Host or domain name not found.
  Name service error for name=_25._tcp.cluster5.us.messagelabs.com
  type=TLSA: Host not found, try again

  The DNS resolver on my machine was pointing at the systemd-resolved
  stub:

      $ cat /etc/resolv.conf | grep nameserver
      nameserver 127.0.0.53

      $ resolvectl status
      Global
          Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=allow-downgrade/supported
          resolv.conf mode: stub

  Note DNSSEC is enabled (else Postfix couldn't be doing DANE). Now if I
  query the TLSA record for the messagelab server, I get a SERVFAIL from
  the stub resolver:

      $ delv +dnssec _25._tcp.cluster5.us.messagelabs.com TLSA
      ;; resolution failed: SERVFAIL

  Whereas if I query my upstream DNS or Google DNS, I get a DNSSEC
  validated (negative) response:

      $ delv @8.8.8.8 +dnssec _25._tcp.cluster5.us.messagelabs.com TLSA
      ;; resolution failed: ncache nxrrset
      ; negative response, fully validated
      ; _25._tcp.cluster5.us.messagelabs.com. 299 IN \-TLSA ;-$NXRRSET
      ; _25._tcp.cluster5.us.messagelabs.com. RRSIG NSEC ...
      ; _25._tcp.cluster5.us.messagelabs.com. NSEC 
\000._25._tcp.cluster5.us.messagelabs.com. A PTR HINFO MX TXT RP AAAA SRV NAPTR 
SSHFP RRSIG NSEC SVCB HTTPS SPF IXFR AXFR CAA
      ; messagelabs.com. SOA ns-1714.awsdns-22.co.uk. 
awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
      ; messagelabs.com. RRSIG SOA ...

  I assume Postfix (with smtp_tls_security_level = dane i.e.
  "Opportunistic DANE") deals with the negative response by downgrading
  to "encrypt", whereas the SERVFAIL response makes it refuse to connect
  altogether.

  My workaround was to switch from the systemd-resolved stub resolver to
  the upstream servers. In /etc/systemd/resolved.conf set:

      DNS=... your upstream servers if not already given through DHCP ...
      DNSStubListener=no

  Then restart the service and restart Postfix if it is chrooted (so the
  new /etc/resolv.conf gets copied into the chroot):

      systemctl restart systemd-resolved
      systemctl restart postfix

  I am not sure if this could be considered a Postfix bug as well (it
  could consider a SERVFAIL on a TLSA record the same as a negative),
  but surely it seems to me the systemd-resolved stub resolver should
  not return the SERVFAIL here.

  For more background on this bug report, please see
  https://serverfault.com/a/1158198/299950

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2062542/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to