On the MIT network (which runs some ancient version of BIND 9), systemd-resolved stops resolving anything that isn’t DNSSEC-signed after I disconnect and reconnect the network. Signed zones continue to resolve.
This happens with either DNSSEC=yes or the default DNSSEC=allow-downgrade.
-- Information acquired via protocol DNS in 15.6ms.
-- Data is authenticated: no
$ # (disconnect and reconnect wifi)
$ systemd-resolve github.com
github.com: resolve call failed: DNSSEC validation failed: no-signature
I’m refiling this here because I believe that this regression and others (bug 1588230, bug 1624071, bug 1624317, bug 1449001) indicate that systemd-resolved is not ready for production, and with final freeze just a week away, leaving systemd-resolved enabled for the yakkety release would be reckless.
On the MIT network (which runs some ancient version of BIND 9), systemd-resolved stops resolving anything that isn’t DNSSEC-signed after I disconnect and reconnect the network. Signed zones continue to resolve.
This happens with either DNSSEC=yes or the default DNSSEC= allow-downgrade .
$ systemd-resolve github.com
github.com: 192.30.253.113
-- Information acquired via protocol DNS in 15.6ms.
-- Data is authenticated: no
$ # (disconnect and reconnect wifi)
$ systemd-resolve github.com
github.com: resolve call failed: DNSSEC validation failed: no-signature
More debug information is available in my upstream report (https:/ /github. com/systemd/ systemd/ issues/ 4175), which has gotten no response in the last week and a half.
I’m refiling this here because I believe that this regression and others (bug 1588230, bug 1624071, bug 1624317, bug 1449001) indicate that systemd-resolved is not ready for production, and with final freeze just a week away, leaving systemd-resolved enabled for the yakkety release would be reckless.