On Do, 16.04.20 19:53, Chris Adams (linux(a)cmadams.net) wrote:
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de>
> Again, we do not support DNSSEC from client to the stub. If you set CD
> we'll return NOTIMP as rcode, indicating that. We do not implement a
> full DNS server, but just enough for local stub clients (such as the
> one implemented in glibc or Java) to work. If you want the full DNSSEC
> client stuff, talk directly to the upstream DNS server.
If you want to go in /etc/resolv.conf, you need to be a full resolver.
There's no telling what programs expect to be able to talk the full DNS
protocol to the "nameserver" lines from /etc/resolv.conf (for example,
the perl Net::DNS module gets its servers from there by default, so all
kinds of perl scripts could break). dnsmasq defaults to using resolvers
from /etc/resolv.conf too IIRC.
If you want to be a resolver, be an actual resolver, and in 2020, that
includes implementing EDNS0, DNSSEC, etc.
resolved implements edns0 just fine.
And then there's DNSSEC support and DNSSEC support.
There's DNSSEC support as in "AD bit". Which is a silly thing if you
ask me. It is a bit you can set in the DNS response which tells the
client the data was "authenticated". It has no value however, because
anyone can claim that, it's not signed or nothing. This is the DNSSEC
support glibc implementss. It's silly, fake security.
And then there's DNSSEC support as in "full validation". In this case
the client checks all the signatures, and the AD bit isn't
relevant. This one actually is useful, but isn't what glibc
implement. Few clients implement that, and even fewer are deployed
that do this regularly. (My guess is that most clients that do this
are probably tools like "dig", that are used to debug this.)
The DNS servers in edge routers are awful at supporting
either. i.e. the DNS servers you usually get informed about in DHCP
leases are typically too crap at supporting either kind of DNSSEC (and
that for a reason actually, these devices generally define their own
private, local DNS names (e.g. "fritz.box"), which couldn't possibly
be validated with DNSSEC, because they are made up and local.)
systemd-resolved implements the full validation when talking to its
upstream servers. Because edge routers are so awful, we have trouble
making this work reliably enough in the general case. In specific
cases with a nice DNS server upstream everything is fine, but in the
general case it's not fun. systemd-reslolved does not care for the
"AD" bit stuff when talking to its upstream servers, because it's
When clients talk to systemd-resolved's DNS stub they will get errors
back if they themselves try to do the full validation, because we
don't cache that information suitably. We return clean errors in this
case, so that the client understands it cannot talk DNSSEC to us. We
intend to implement the "AD" stuff however correctly for this, but
this isn't tested much since pretty much noone except for a few DNS
devs actually set this, hence there might be issues, which might be
what Florian found. At least in our history of having been enabled in
Ubuntu this came up only sporadingly.
I think it#s worth tweaking the "AD" support in the stub, but I also
don't think it's really as important as people might think, because
there are so few clients that actually want it, and conceptually it's
kinda silly anyway (OK, admittedly, it's a bit less silly if a you
trust the "AD" bit if it's only sent between a local client to a local
system stub via the loopback device, but still...).
Lennart Poettering, Berlin