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. [Edit: Oh, I see that conclusion was already reached yesterday.]
Bug 1588230 and bug 1624071 are fixed now. I'm fairly sure I understand bug 1624317 (and it would be fixed in yakkety now), and bug 1449001 is not actually a malfunction but just some disagreement about a builtin fallback if no DNS servers are configured (and thus fairly irrelevant really).
This bug is relevant, of course, thanks for the report. There are still several known problems with DNSSEC, and thus the plan had been from the start to enable it during the development series and disable it shortly before the release (which has happened a few days ago). The point was to learn about bugs in practice. So 16.10 ships with disabled DNSSEC, which is no worse than the default "dns" nss plugin (i. e. libc itself).