;-)
Response to earlier email:
Thanks for the informative response Michael.
I plan to read the content at those links in some depth. What I see so far does
describe how name resolution now works and hints at why this is being done. Even
had I read that it would not have prepared me for the possibility that the
resolver would fail so completely in my relatively simple environment. Nor does
it
suggest how to return to a working resolver, either by returning to either nss
option or correcting the systemd-resolved configuration -- and I still do not
know how to approach that. I will continue to read.
I guess that there are more places to get the information than I have previously
been aware, but that still doesn't mean that most users will find it or
understand it. I read stuff like this all the time but totally missed that. I
can't imagine how most regular users and busy-to-their-eyeballs sysadmins will
run
across this and then know how to connect the dots between change and symptom.
It took me a good bit of experimenting to figure out that /etc/resolv.conf is
now just a link and the specific link used defines how name resolution actually
works. My usual procedure with resolver problems is to cat /etc/resolv.conf but
that does not tell me it is a link. I only realized that a major change had been
made by doing a long listing while looking for old or conflicting files. Then I
was on track to figure it out.
I think your statement about name resolution being bad would only be true if I
were part of one of the edge cases for which the old way failed. This is from a
user standpoint where "all is good until it fails" rather than a developer
standpoint where "it suck behind the scenes so it needs fixed even if it breaks
things for a while."
I do like most of what systemd does. I do think that perhaps better testing of
possible failure modes and circumstances as well as communication of possible
problems, their symptoms, known fixes, and circumventions would help. And it
needs to be obvious to anyone looking for that information.
Response to this email:
Ok, so I manage my network using DHCP on an internal server for all except that
server and my Linux firewall/router which both use a complete static
configuration for networking.
My DHCP server does provide DNS resolver information which, in order, is my
internal BIND server (same physical server host), 8.8.8.8, and 8.8.4.4. But my
hosts were not getting that information. I think the difference between the
working and failing hosts is possibly (experiments required) left-over ifcfg
files some of which specified DHCP but also name servers while others specified
DHCP but did not specify name servers, as well as some newer hosts that do not
have any ifcfg files. I have also noticed that ifcfg files are no longer created
automatically but work when created. I missed that information also.
I am willing to help with this.
Thanks!
--
*********************************************************
David P. Both, RHCE
He/Him/His
*********************************************************
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*********************************************************
The value of any software lies in its usefulness
not in its price.
— Linus Torvalds
*********************************************************
On Thu, 18 Feb 2021, Michael Catanzaro wrote:
Date: Thu, 18 Feb 2021 09:34:52
From: Michael Catanzaro <mcatanzaro@xxxxxxxxx>
Reply-To: Development discussions related to Fedora
<devel@xxxxxxxxxxxxxxxxxxxxxxx>
To: David Both <david@xxxxxxxx>,
Development discussions related to Fedora <devel@xxxxxxxxxxxxxxxxxxxxxxx>
Cc: Steve Dickson <SteveD@xxxxxxxxxx>
Subject: Re: Don't update to the latest f33!
On Thu, Feb 18, 2021 at 8:30 am, Michael Catanzaro <mcatanzaro@xxxxxxxxx>
wrote:
We don't set DNS there intentionally because it eliminates any benefit of
using split DNS. Your static global DNS= configuration in resolved.conf is
used for *every* request, *in addition* to per-link DNS configuration. So
if you have per-link DNS configuration from DHCP -- which almost everybody
will except in cloud environments like this -- then you would wind up with
two parallel DNS queries going out for every lookup, where whichever
finishes first wins. That's not a good default.
Well I should clarify: it *is* a good default for cloud or server
environments where it is guaranteed that DHCP will not provide any DNS
configuration and you just need a simple, static DNS config. So if the cloud
provider inserted its DNS config here, that was probably the right thing to
do. It just needs to not use commas. :P
_______________________________________________
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
