Disable DNSSEC by default

[Dimitri John Ledkov]

[Impact]

 * dnssec functionality in systemd-resolved prevents network access in certain intra and extra net cases, due to failure to correctly validate dnssec entries. As a work-around we should disable dnssec by default.

[Test Case]

 * Validate systemd-resolved is compiled with --with-default-dnssec=no
 * Validate that systemd-resolve --status says that DNSSEC setting is no

$ systemd-resolve --status

good output:
...
  DNSSEC setting: no
DNSSEC supported: no
...

bad output:
...
  DNSSEC setting: allow-downgrade
DNSSEC supported: yes
...

[Regression Potential]

 * People who expect DNSSEC to be available by default will need to re-enable it by modifying systemd-resolve configuration file

[Other Info]

 * See duplicate bugs and other bug reports in systemd for scenarios of DNS resolution failures when DNSSEC is enabled.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Adam Conrad (adconrad)]

Hello Dimitri, or anyone else affected,

Accepted systemd into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/232-21ubuntu3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Török Edwin (edwintorok)]

systemd version 232-21ubuntu3: verified OK.

[Sudeep Duggal (duggalsudeep-deactivatedaccount)]

systemd version 232-21ubuntu3: verified OK.

How do I correctly enable DNSSEC as default ?

[Sudeep Duggal (duggalsudeep-deactivatedaccount)]

Regression Confirmed: Setting DNSSEC=yes in /etc/systemd/resolved.conf after 232-21ubuntu3 update

[Dimitri John Ledkov (xnox)]

@duggalsudeep

This is not a regression, we are intentionally disabling DNSSEC by default; and yes you do need to change /etc/systemd/resolved.conf to enable DNSSEC - just like in yakkety. It was a mistake that we enabled it for zesty.

[Paul Natsuo Kishimoto (khaeru)]

Bug #1650877 and the others linked there (see comment #7) appear to be duplicates.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 232-21ubuntu3

---------------
systemd (232-21ubuntu3) zesty; urgency=medium

  [ Martin Pitt ]
  * resolved: Disable DNSSEC by default on stretch and zesty.
    Both Debian stretch and Ubuntu zesty are close to releasing, switch to
    DNSSEC=off by default for those. Users can still turn it back on with
    DNSSEC=allow-downgrade (or even "yes"). (LP: #1682499)

  [ Michael Biebl ]
  * journal: fix up syslog facility when forwarding native messages.
    Native journal messages (_TRANSPORT=journal) typically don't have a
    syslog facility attached to it. As a result when forwarding the
    messages to syslog they ended up with facility 0 (LOG_KERN).
    Apply syslog_fixup_facility() so we use LOG_USER instead. (Closes: #837893)
    (LP: #1682484)

  [ Dimitri John Ledkov ]
  * networkd: cherry-pick support for setting bridge port's priority.
    This is a useful feature/bugfix to improve feature parity of networkd with
    ifupdown. This matches netplan's expectations to be able to set bridge port's
    priorities via networked. This featue is to be used by netplan/MAAS/OpenStack.
    (LP: #1668347)
  * TEST-12: cherry-pick upstream fix for compat with new netcat-openbsd.
    (LP: #1672542)
  * udev.postinst: preserve virtio interfaces names on upgrades, on s390x.
    New udev generates stable interface names on s390x kvm instances, however, upon
    upgrades existing ethX names should be preserved to prevent breaking networking
    and software configurations. (Closes: #860246) (LP: #1682437)

 -- Dimitri John Ledkov <email address hidden> Thu, 13 Apr 2017 18:10:33 +0100

[Steve Langasek (vorlon)]

The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Sean Dague (sdague)]

For what it's worth, I reported a related issue up to the systemd-devel mailing list, and it looks like in systemd 233 (the next version) things work much better with DNSSEC. https://lists.freedesktop.org/archives/systemd-devel/2017-April/038698.html

I rebuilt the 233 out of debian experimental, and at least for my use case, this all worked now.

[Dimitri John Ledkov (xnox)]

On 20 Apr 2017 22:20, "Sean Dague" <email address hidden> wrote:

For what it's worth, I reported a related issue up to the systemd-devel
mailing list, and it looks like in systemd 233 (the next version) things
work much better with DNSSEC. https://lists.freedesktop.org/archives
/systemd-devel/2017-April/038698.html

I rebuilt the 233 out of debian experimental, and at least for my use case,
this all worked now.

I am preparing merge of 233 for 17.10 and we can re-evaluate enabling
dnssec then.

Regards,

Dimitri.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 232-21ubuntu3

---------------
systemd (232-21ubuntu3) zesty; urgency=medium

  [ Martin Pitt ]
  * resolved: Disable DNSSEC by default on stretch and zesty.
    Both Debian stretch and Ubuntu zesty are close to releasing, switch to
    DNSSEC=off by default for those. Users can still turn it back on with
    DNSSEC=allow-downgrade (or even "yes"). (LP: #1682499)

  [ Michael Biebl ]
  * journal: fix up syslog facility when forwarding native messages.
    Native journal messages (_TRANSPORT=journal) typically don't have a
    syslog facility attached to it. As a result when forwarding the
    messages to syslog they ended up with facility 0 (LOG_KERN).
    Apply syslog_fixup_facility() so we use LOG_USER instead. (Closes: #837893)
    (LP: #1682484)

  [ Dimitri John Ledkov ]
  * networkd: cherry-pick support for setting bridge port's priority.
    This is a useful feature/bugfix to improve feature parity of networkd with
    ifupdown. This matches netplan's expectations to be able to set bridge port's
    priorities via networked. This featue is to be used by netplan/MAAS/OpenStack.
    (LP: #1668347)
  * TEST-12: cherry-pick upstream fix for compat with new netcat-openbsd.
    (LP: #1672542)
  * udev.postinst: preserve virtio interfaces names on upgrades, on s390x.
    New udev generates stable interface names on s390x kvm instances, however, upon
    upgrades existing ethX names should be preserved to prevent breaking networking
    and software configurations. (Closes: #860246) (LP: #1682437)

 -- Dimitri John Ledkov <email address hidden> Thu, 13 Apr 2017 18:10:33 +0100

[allfox_wy (allfoxwy)]

Greetings, everyone.

I'm on Ubuntu GNOME 17.04

I see that DNSSEC is now off by default, however, in my log, I would see something like:
  4 May 2 23:29:31 lavender systemd-resolved[1129]: Grace period over, resuming full feature set (UDP+EDNS0+DO+LARGE) for DNS server 10.2.5.7.
  5 May 2 23:29:31 lavender systemd-resolved[1129]: Using degraded feature set (UDP) for DNS server 10.2.5.7.

And during that, it seems the systemd-resolved would act just like DNSSEC enabled, and Web would fail some time like before.

I don't quite get what is going on. I have dnsmasq run in my network to provide DNS cache, it's the 10.2.5.7 . My upstream server do not support DNSSEC, so the validation would fail certainly.

What I observed is during this feature set test, dnsmasq cache would receive TCP connection from Ubuntu GNOME 17.04 . And take some time, the test fail.

I know this feature test would fail, as I know the upstream server do not support DNSSEC. I don't know what is EDNS0 or LARGE. But the problem here is that even DNSSEC is now off by default, this feature set test would still do the "DO" test, which stands for DNSSEC OK. It would surely fail, and it can not be turned off via configuration, and it would cut the Web for some time.

There is a patch for this: https://github.com/systemd/systemd/issues/5352

Is it possible to cherry pick it please ?

[Dimitri John Ledkov (xnox)]

This particular issue is now closed. Please open a new bug report
requesting a cherrypick.

We really should not use one bug report for all the past and future defects
:-)

We need a new bug number for SRU tracking purposes.

Regards,
Dimitri.

On 2 May 2017 5:01 pm, "allfox_wy" <email address hidden> wrote:

Greetings, everyone.

I'm on Ubuntu GNOME 17.04

I see that DNSSEC is now off by default, however, in my log, I would see
something like:
  4 May 2 23:29:31 lavender systemd-resolved[1129]: Grace period over,
resuming full feature set (UDP+EDNS0+DO+LARGE) for DNS server 10.2.5.7.
  5 May 2 23:29:31 lavender systemd-resolved[1129]: Using degraded feature
set (UDP) for DNS server 10.2.5.7.

And during that, it seems the systemd-resolved would act just like
DNSSEC enabled, and Web would fail some time like before.

I don't quite get what is going on. I have dnsmasq run in my network to
provide DNS cache, it's the 10.2.5.7 . My upstream server do not
support DNSSEC, so the validation would fail certainly.

What I observed is during this feature set test, dnsmasq cache would
receive TCP connection from Ubuntu GNOME 17.04 . And take some time, the
test fail.

I know this feature test would fail, as I know the upstream server do
not support DNSSEC. I don't know what is EDNS0 or LARGE. But the problem
here is that even DNSSEC is now off by default, this feature set test
would still do the "DO" test, which stands for DNSSEC OK. It would
surely fail, and it can not be turned off via configuration, and it
would cut the Web for some time.

There is a patch for this:
https://github.com/systemd/systemd/issues/5352

Is it possible to cherry pick it please ?

** Bug watch added: github.com/systemd/systemd/issues #5352
   https://github.com/systemd/systemd/issues/5352

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1682499

Title:
  disable dnssec

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

[lotuspsychje (lotuspsychje)]

Installed 17.10 64bit development branch on a daily .iso @ 14/5/2017

problem is solved after editing: /etc/systemd/resolved.conf DNSSEC=off and reboot

another duplicate: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1690605

[Jacek Misiurewicz (jmisiure)]

This helped me only partially - I still have issues with DNS lookup.

It seems that the systemd-resolved is broken from the very idea.

After solving DNSSEC problem, I see now a switching problem - if one DNS does not respond, resolved switches to another one, which may be a local DNS not serving all the information, however it responds RELIABLY with .... "REFUSED" for majority of queries! Thus, resolved is stuck with this "reliable" DNS, refusing almost all queries until reboot (or networking reload).

There are so many bugs filled about resolved that somebody should gather them in one place and do something.

Moreover, tracing problems is not easy - they are intermittent, depending on current server load. For some people in fixed setup bug may be nonexistent; when travelling across well-configured, simple and non-overloaded networks everything is OK. Then, at some hour, some connection - I start having to reload network every time I start reading mail.....

For now many people are switching to alternative resolver - e.g. "unbound"; what is going on with resolved looks like sabotage.....