Hi Florian, more below...
On 11/11/20 11:39 AM, Florian Weimer wrote: > * Petr Menšík: >>> 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. I maintain also dnsmasq and I doubt there is reason to remove it from the distribution. I would oppose if anyone intented to do it. > > Even if systemd-resolved has issues, they still need to be fixed because > it's the Fedora default. systemd-resolved brings more changes than were announced. Not all of them have fixes and some were refused. I think systemd people close too many bugs with WORKSFORME reason personally. But sure, bugs should be fixed. On the other hand, there are a lot of use cases, where it works better without systemd-resolved. I think we want alternatives supported regardless what is the default. Need to say I am not happy it became default and I would prefer it would first fix (already) known issues. > >>> 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. What I mean is omitting resolve module. So hosts db either reads /etc/hosts, or uses /etc/resolv.conf via /lib64/libnss_dns.so.2. > > 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. I expect it would only cache simple name:ip pairs, nothing more. No, I doubt nscd can bring any additional privacy. > > 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. We can argue whether people need DNSSEC. Systemd-resolved cannot work with it correctly and it actively BREAKS its usage. Just like dnsmasq, nscd just caches and no more. It usually does not break anything. I think it preserves most features of libnss_dns.so behaviour. No recursion, dead servers detection or injecting local zones is required. It is not done without the cache anyway. Dead servers detection could be improved I think. > > 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. Sure. If they can't use glibc interface, they would not use nscd. That clearly its advantage! It does not have to implement dnssec or edns0, because getaddrinfo api does not include such flags. If clients needs advanced usage, unlike systemd-resolved, it does not stand in the way. I think this is the greatest advantage. Advanced uses can work around only a simple service without problem. They don't collide. > >>> 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.) This bug reminds me bug #1740511 [1], which was very hard for me. Later, mlichvar discovered real reason for it. Atomic operations required different flags to atomic operations. ppc64le platform has different memory ordering than x86_64, where it worked flawlessly. It crashed often just on ppc64le. Our fix was to switch to memory_order_acquire, where integrity was enforced properly. I have seen relaxed in bug attached patches, would recommend checking it out. https://bugzilla.redhat.com/show_bug.cgi?id=1740511 https://en.cppreference.com/w/c/atomic/memory_order > > 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 > Is there any design document about nscd? How are interfaces to cache implemented from glibc? Is connection to nscd hardocoded in gethostbyname and getaddrinfo functions? -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB_and_old_rev.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
