disable dnssec

Bug #1682499 reported by Dimitri John Ledkov on 2017-04-13
100
This bug affects 20 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
High
Unassigned
Zesty
High
Unassigned

Bug Description

[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) wrote :

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

Changed in systemd (Ubuntu):
status: New → Confirmed
Changed in systemd (Ubuntu Zesty):
milestone: none → zesty-updates
Adolfo Jayme (fitojb) on 2017-04-18
Changed in systemd (Ubuntu Zesty):
importance: Undecided → High
description: updated
description: updated

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!

Changed in systemd (Ubuntu Zesty):
status: Confirmed → Fix Committed
tags: added: verification-needed
Török Edwin (edwintorok) wrote :

systemd version 232-21ubuntu3: verified OK.

tags: added: verification-done
removed: verification-needed

systemd version 232-21ubuntu3: verified OK.

How do I correctly enable DNSSEC as default ?

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

Dimitri John Ledkov (xnox) wrote :

@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) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu Zesty):
status: Fix Committed → Fix Released

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) 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.

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) wrote :

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

Changed in systemd (Ubuntu):
status: Fix Committed → Fix Released
allfox_wy (allfoxwy) 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 ?

Dimitri John Ledkov (xnox) wrote :

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) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.