[Bug 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

[Dan Streetman]

ubuntu at 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 at 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 at lp1796501-b:~$ dpkg -l systemd|grep ii
ii  systemd        237-3ubuntu10.31 amd64        system and service manager
ubuntu at lp1796501-b:~$ host test.asdf
Host test.asdf not found: 2(SERVFAIL)


ubuntu at lp1796501-b:~$ dpkg -l systemd|grep ii
ii  systemd        237-3ubuntu10.33 amd64        system and service manager
ubuntu at 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
Foundations Bugs, 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