On Do, 16.04.20 19:53, Chris Adams (li...@cmadams.net) wrote: > Once upon a time, Lennart Poettering <mzerq...@0pointer.de> said: > > 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 useless. 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 -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
