ubuntu@lp1796501-b:~$ cat /etc/systemd/network/10-ens3.network [Match] Name=ens3
[Network] DHCP=ipv4 LinkLocalAddressing=ipv6 DNS=8.8.8.8 DNSSEC=yes [DHCP] UseDNS=no ubuntu@lp1796501-b:~$ systemd-resolve --status ens3 Link 2 (ens3) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: yes DNSSEC supported: yes DNS Servers: 8.8.8.8 DNS Domain: vm ubuntu@lp1796501-b:~$ dpkg -l systemd|grep ii ii systemd 237-3ubuntu10.31 amd64 system and service manager ubuntu@lp1796501-b:~$ host test.asdf Host test.asdf not found: 2(SERVFAIL) ubuntu@lp1796501-b:~$ dpkg -l systemd|grep ii ii systemd 237-3ubuntu10.33 amd64 system and service manager ubuntu@lp1796501-b:~$ host test.asdf Host test.asdf not found: 3(NXDOMAIN) ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic ** Tags removed: sts-sponsor-ddstreet -- 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/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Released Bug description: [impact] an NXDOMAIN response from a dns server when systemd-resolved is configured as DNSSEC=yes breaks dns resolution as it downgrades from DNSSEC. [test case] see comment 9 [regression potential] as with the original patch that introduced this problem, this has the potential to break dns resolution. [other info] original description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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