On Mon, Sep 28, 2020 at 10:05 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote:
> On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote: > > After reading https://github.com/systemd/systemd/issues/8967, I really > > don't think that systemd-resolved's benefits outweigh its harms as a > > default resolver for Fedora. If someone wants to write a > > libfriendlydnsresolver and encourage/patch programs to use it instead of > > using glibc's resolver or reading resolv.conf, then that could be debated > > on its merits. But the actual contents of /etc/resolv.conf should follow > > the relevant standards, and systemd-resolved does not. > > > > Perhaps systemd-resolved could change its mind and decide to comply with > > all relevant standards. But until then, it seems inappropriate to me for > > it to be the default in Fedora. > > Pfff, now I'm confused. Here is a case where systemd-resolved implements > the > standard, and some people were unhappy because they were relying on sloppy > implementations which don't follow the RFC. Nevertheless, we added an > opt-in > switch to make this work. (Since this feature mostly matters in "special" > setups like k8s, where you need to do a lot of local setup anyway, > requiring > a one-line option seems to be reasonable). > I agree that the "tld." case is probably unusual, and I didn't personally know that anyone had an actual website set up like this until today, but as someone who has configured DNS zones, I did know that it was valid to attach records to a TLD. And, indeed, loading https://dk./ on Firefox on Fedora 32 works! I'm reminded of https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver. That change, as I recall, didn't end up accepted because it ran into a bunch of corner cases and (at least at the time) didn't solve them all adequately. I don't recall its proponents ever arguing that the corner cases were *wrong*, though. In contrast, for some reason, the proponents of systemd-resolved are telling us that the corner cases aren't bugs, are arguing that the plainly written text in the standards are somehow not the standards, and are kindly offering to add non-default options to make systemd-resolved do what it should do by default. Sorry, but it really seems that systemd-resolved is not ready for prime time. To be clear, I personally do not like the model of having each client application manage its own communication with the network's resolver (i.e. what happens today when /etc/resolve.conf mentions whatever nameserver was provided by DHCP), but I think that a better solution needs to be very well thought through and to honor the expectation that whatever is in /etc/resolv.conf actually follows the standards. Programs that use the glibc name resolution APIs or that use UDP via their favorite library are not human beings who can be retrained to do things better -- they are programs that were written to various manpages, standards, etc, and when one of them asks getaddrinfo(3) to resolve "dk.", they don't mean "do whatever the systemd-resolved authors thought this should do"; they meant "resolve dk. as per POSIX and the RFCs. Similarly, if a program submits a perfectly valid EDNS query asking for DNSSEC data (note: I mean DO -- I'm not referring to the AD bit or to any sort of server-side validation), then, if the network supports DNSSEC, the result should include the requested data. If Fedora 33 is going to violate these assumptions, along with whatever else might be broken that various people on this thread have alluded to, IMO it should have an extremely good reason to do so. I haven't seen one yet.
_______________________________________________ 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
