* 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
