[Bug 2038897] Re: systemd-resolved: not all records flushed when using 'resolvectl flush-caches'

[Imre Jonk (SIDN)]

Hi Eduardo,

Thanks a lot for your reply. I've just tested this with systemd 254.5
(the latest stable version) on Arch Linux, and systemd 253.5-1ubuntu6 on
Ubuntu 23.10. I could *not* reproduce the issue on either of these
installs. This makes me confident that the issue has been fixed
upstream, even though I cannot find a reference of this in the upstream
release notes.

I can still reproduce the issue on Ubuntu 22.04 LTS with the latest
systemd update (249.11-0ubuntu3.11). My understanding is that this will
not be fixed by the Ubuntu security team as DNSSEC support in systemd is
considered experimental. I was not aware of this, thank you for pointing
it out.

I will now close this bug report as Won't Fix and make it public for
later reference.

Kind regards,

Imre Jonk

** Information type changed from Private Security to Public Security

-- 
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/2038897

Title:
  systemd-resolved: not all records flushed when using 'resolvectl
  flush-caches'

Status in systemd package in Ubuntu:
  New

Bug description:
  *Expected behavior*
  After flushing DNS resource record caches with `resolvectl flush-caches`, I
  expect all resource records to have been flushed. I also expect
  DNSSEC validation on these resource records to be reperformed upon request when
  DNSSEC validation is enabled.

  *Actual behavior*
  When I enable DNSSEC validation on the only DNS-scope link and use 'resolvectl
  flush-caches' to flush the systemd-resolved cache, I can still resolve the
  purposefully DNSSEC-invalid domain name dnssec-failed.org.

  *Steps to reproduce*
  1. Configure a resolver that does not perform DNSSEC-validation. I picked
     Quad9's 'Unsecured' resolver: 9.9.9.9 / 2620:fe::10
  2. Resolve dnssec-failed.org, which puts the answer in the cache:
       $ resolvectl query dnssec-failed.org
       dnssec-failed.org: 96.99.227.255               -- link: wlp0s20f3
  3. Enable DNSSEC validation on the DNS-scope link:
       $ sudo resolvectl dnssec wlp0s20f3 yes
  4. Flush the caches:
       $ sudo resolvectl flush-caches
  5. Attempt to resolve dnssec-failed.org again:
       $ resolvectl query dnssec-failed.org
       dnssec-failed.org: 96.99.227.255               -- link: wlp0s20f3

  *System information*
  OS: Ubuntu 22.04.3 LTS
  systemd version: 249.11-0ubuntu3.10
  Architecture: x86_64

  *Additional information*
  I've also tried flushing the caches by sending the SIGUSR2 and SIGRTMIN+1
  signals to systemd-resolved, without result. Only restarting the
  systemd-resolved service results in the expected behavior:
    $ resolvectl query dnssec-failed.org
    dnssec-failed.org: resolve call failed: DNSSEC validation failed: missing-key
  This is currently my workaround.

  *Rationale for reporting this as a vulnerability*
  I am interested in dynamically enabling DNSSEC validation in systemd-resolved
  whenever my VPN connection comes up, so that my SSH client can rely on SSHFP
  resource records for SSH host fingerprint checking. The VPN server pushes a
  resolver that is DNSSEC-capable, unlike many resolvers on public networks. I
  use a custom NetworkManager dispatcher script to call resolvectl in order to
  enable local DNSSEC validation on the VPN interface, as well as the physical
  interface to prevent fallback. Since the caches now potentially contain
  DNSSEC-invalid (tainted) responses, I want to flush the caches so that
  validation is reperformed. Having tainted SSHFP responses in the
  systemd-resolved caches is a MitM attack vector.

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