* Petr Menšík:
On 11/5/20 12:49 PM, Florian Weimer wrote:
> * Petr Menšík:
>
>
> nscd has more usage downstream, leading to bugs such as:
>
> <
https://bugzilla.redhat.com/show_bug.cgi?id=1551616>
I have very limited understanding of sssd principles. But I think it is
not comparable to nscd, which you just start or stop. No other
configuration is required.
sssd without LDAP integration should work out of the box, too, and
automatically cache /etc/passwd and other databases. It's even smarter
about that than nscd, I think, reading the files on startup and
monitoring them for changes.
>> Instead, I request again, split systemd-resolved into
subpackage. I want
>> it removed on my system and so do more people. Also, when I disable it,
>> I have to fix /etc/resolv.conf by hand. I would think NetworkManager
>> restart would refresh classic /etc/resolv.conf, like in F32.
>
> This proposal is about nscd, not systemd-resolved.
systemd-resolved is mentioned in the title and the body of proposal.
So
it seems it is about it.
Fedora made the decision to promote systemd-resolved as a local DNS
cache. To me, that means that we can gradually remove other DNS caches
from the distribution.
Even if systemd-resolved has issues, they still need to be fixed because
it's the Fedora default.
> If Fedora chooses to adopt another local DNS cache, glibc will
use that
> (probably using the built-in nss_dns service module) systemd-resolved is
> just what we have for now, so the proposal references it. But any other
> DNS cache will work as well.
I do not think there is another cache like nscd, which does not
require
/etc/resolv.conf change or special nss hosts module. While I admit there
are more caches, I don't think any provides drop-in replacement.
Especially resolve nss plugin introduces so many (unannounced) changes,
I don't think it is a good alternative. Caching via dns module might be
more predictable even with systemd-resolved.
What do you mean by “Caching via dns module”? nss_dns does not have any
cache whatsoever.
There seem to be a lot of misconceptions about what nscd does and which
benefits it brings (see the claim about increased privacy). So I think
it's important to be precise here.
From my point of view, nscd is not a very satisfactory solution for DNS
caching because it can't do DNSSEC, it can't do recursion, it can't do
prefetching, it doesn't have a good way to detect dead servers, it can't
inject local stub zones, and so on.
I also think that not changing /etc/resolv.conf isn't a feasible goal
because that's the file applications use to locate the system DNS
resolver if they can't use the glibc interfaces for some reason.
> The hosts cache in nscd is arguably the weakest part of it, so
> deprecating really shouldn't be controversial at all.
If you offer alternative, which improves caching without additional
regressions, sure. I am not sure dnsmasq, systemd-resolved or unbound
can be compared to no configuration of nscd. Unlike other resolvers,
nscd caches only getaddrinfo calls, without ever touching outgoing DNS
client queries or /etc/resolv.conf modification. Is there any other
service able to do it?
Are there bugs I can help fixing, especially in hosts or ahosts
databases?
Thanks for the offer.
The big one is the general cache instability:
nscd: Concurrency issues with cache.
<
https://sourceware.org/bugzilla/show_bug.cgi?id=25888>
(Internal bug #1172792.)
Related to DNS data, there are bunch of issues that need investigating
or fixing:
getaddrinfo drops ipv6 V4MAPPED addresses from ncsd results
<
https://sourceware.org/bugzilla/show_bug.cgi?id=26630>
Problems with nscd and systemd-resolved interactions on IPv6 network.
<
https://sourceware.org/bugzilla/show_bug.cgi?id=23546>
nscd doesn't cache record containing more than one IP address.
<
https://sourceware.org/bugzilla/show_bug.cgi?id=15862>
Reload nscd cache entry even if its timeout is equal to the current time
<
https://sourceware.org/bugzilla/show_bug.cgi?id=13931>
hosts caching does not respect TTL, and caches old IP's
<
https://sourceware.org/bugzilla/show_bug.cgi?id=4428>
Thanks,
Florian
--
Red Hat GmbH,
https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill