DNSSEC is dead and useless unless every application is written to understand the error messages and every device runs its own DNS resolver (not forwarding, because it's not really validating then and the responses could be spoofed).
We don't need DNSSEC because it doesn't solve any existing problems. The validation is done at the application protocol level with TLS, and apps that aren't running TLS need to fix this gap.
So as it turns out DNSCrypt is winning the internet even though the standards bodies blocked it. Additionally, OpenDNS has massive deployment of DNSCrypt users and this is being furthered by Cisco Umbrella. Cisco is adding this capability to iPhones now as announced earlier this week.
tl;dr DNSSEC has always been DOA, but DNSCrypt is just getting started.
The one and only application I knew of that added DNSSEC for DANE removed it because it was worthless (irssi, irc client).
dnsmasq doesn't require dbus though: that's an optional dependency that has to be enabled at compile time.
To make it work with Network Manager, it needs DBus support. So distributions compile it with DBus support.
So eliminate Network Mangler, two problems with one stone...
Sure, but the key there is NetworkManager. dnsmasq itself doesn't require DBus.
How does systemd-resolved work with NM? If the goal in general is to have a non-dbus version when NM isn't used, then provide both versions as packages.
Do not require dbus?!
Re:Ubuntu Systemd Vulnerability
by icebraining on Wednesday June 28, 2017 @08:49AM
(#14653589)
Are you confusing "can use" with "requires"?
I suspect any alternative is a fall back that cause as much troubles as it "solves". After all, the principle devs of systemd are all very much in love with dbus (bloody thing require a copy to be started by initramfs even).
You are missing the part where the user manual and the systemd new features announcement state that the Desktop Bus API is systemd-resolved's "native, fully-featured API"; and describe the GNU C library NSS API and the DNS APIs as limited functionality APIs, whose avoidance by applications is "strongly recommended" in the case of the latter.
we picked "resolved" as that is small and lightweight, already present (part of the systemd package), does not require D-Bus (unlike dnsmasq), supports DNSSEC, provides transparent fallback to contacting the real DNS servers directly (in case anything goes wrong with the local resolver), and avoids the first issue above that /etc/resolv.conf always shows 127.0.0.1.