I have a CentOS stream 8 system (C8) which runs its own internal name server (BIND 9). In the past, it used an external name server on another machine but that server has been stopped. The resolv.conf file on C8 has been modified to remove the reference to the old server and NetworkManager has been restarted. However, CUPS and other programs on C8 continue to send queries to the old server, all of which eventually time out (of course). The bogus queries to the old server are answered with ICMP destination/port unreachable, confirming that the old name server is not running. But these bogus queries take time and the delays are very annoying.
I've also restarted CUPS without effect. There are no references to the old server in /etc/named.conf, but there are references to the subnet it was on as there are other machines there that need to use the new name server. I haven't yet rebooted C8 but I'm prepared if necessary.
Is there something else I should do before rebooting C8? Is that even likely to solve the problem?
I have a CentOS stream 8 system (C8) which runs its own internal name server (BIND 9). In the past, it used an external name server on another machine but that server has been stopped. The resolv.conf file on C8 has been modified to remove the reference to the old server and NetworkManager has been restarted. However, CUPS and other programs on C8 continue to send queries to the old server, all of which eventually time out (of course). The bogus queries to the old server are answered with ICMP destination/port unreachable, confirming that the old name server is not running. But these bogus queries take time and the delays are very annoying.
I've also restarted CUPS without effect. There are no references to the old server in /etc/named.conf, but there are references to the subnet it was on as there are other machines there that need to use the new name server. I haven't yet rebooted C8 but I'm prepared if necessary.
Is there something else I should do before rebooting C8? Is that even likely to solve the problem?
Doesn't systemd do some kind of its own name resolution thing these days?
Maybe someone else can say more about this.
Regards, Simon
Hi,
Do you have nscd running? Try restarting that.
Sent from my iPhone
On 24. May 2024, at 08:51, Simon Matter simon.matter@invoca.ch wrote:
I have a CentOS stream 8 system (C8) which runs its own internal name server (BIND 9). In the past, it used an external name server on another machine but that server has been stopped. The resolv.conf file on C8 has been modified to remove the reference to the old server and NetworkManager has been restarted. However, CUPS and other programs on C8 continue to send queries to the old server, all of which eventually time out (of course). The bogus queries to the old server are answered with ICMP destination/port unreachable, confirming that the old name server is not running. But these bogus queries take time and the delays are very annoying.
I've also restarted CUPS without effect. There are no references to the old server in /etc/named.conf, but there are references to the subnet it was on as there are other machines there that need to use the new name server. I haven't yet rebooted C8 but I'm prepared if necessary.
Is there something else I should do before rebooting C8? Is that even likely to solve the problem?
Doesn't systemd do some kind of its own name resolution thing these days?
Maybe someone else can say more about this.
Regards, Simon
Discuss mailing list -- discuss@lists.centos.org To unsubscribe send an email to discuss-leave@lists.centos.org
I asked:
I have a CentOS stream 8 system (C8) which runs its own internal name server (BIND 9). In the past, it used an external name server on another machine but that server has been stopped. The resolv.conf file on C8 has been modified to remove the reference to the old server and NetworkManager has been restarted. However, CUPS and other programs on C8 continue to send queries to the old server, all of which eventually time out (of course). The bogus queries to the old server are answered with ICMP destination/port unreachable, confirming that the old name server is not running. But these bogus queries take time and the delays are very annoying.
I've also restarted CUPS without effect. There are no references to the old server in /etc/named.conf, but there are references to the subnet it was on as there are other machines there that need to use the new name server. I haven't yet rebooted C8 but I'm prepared if necessary.
Is there something else I should do before rebooting C8? Is that even likely to solve the problem?
Aleksandar Ivanisevic wrote:
Do you have nscd running? Try restarting that.
Simon Matter wrote:
Doesn't systemd do some kind of its own name resolution thing these days?
Maybe someone else can say more about this.
Thanks. But nscd is not running. Perusing all the active systemd services, I restarted systemd-resolved and systemd-networkd but that doesn't seem to have had any effect.
At Fri, 24 May 2024 09:20:44 -0700 CentOS mailing list discuss@lists.centos.org wrote:
I asked:
I have a CentOS stream 8 system (C8) which runs its own internal name server (BIND 9). In the past, it used an external name server on another machine but that server has been stopped. The resolv.conf file on C8 has been modified to remove the reference to the old server and NetworkManager has been restarted. However, CUPS and other programs on C8 continue to send queries to the old server, all of which eventually time out (of course). The bogus queries to the old server are answered with ICMP destination/port unreachable, confirming that the old name server is not running. But these bogus queries take time and the delays are very annoying.
I've also restarted CUPS without effect. There are no references to the old server in /etc/named.conf, but there are references to the subnet it was on as there are other machines there that need to use the new name server. I haven't yet rebooted C8 but I'm prepared if necessary.
Is there something else I should do before rebooting C8? Is that even likely to solve the problem?
Aleksandar Ivanisevic wrote:
Do you have nscd running? Try restarting that.
Simon Matter wrote:
Doesn't systemd do some kind of its own name resolution thing these days?
Maybe someone else can say more about this.
Thanks. But nscd is not running. Perusing all the active systemd services, I restarted systemd-resolved and systemd-networkd but that doesn't seem to have had any effect.
I have found that systemd-resolved is sometimes "fishy" if you are trying to use a local Bind9 name server. systemd-resolved is way too "clever" for its own good. Maybe that is a good thing in some cases, but I have found it problematical for a LAN with a "real" (eg bind9) name server providing names for local machines.
Normally, with systemd-resolved running /etc/resolv.conf is NOT an editable file, but a symlink to a file under systemd-resolved control, and usually systemd-resolved is running its own caching only name server (dmasq?) that is caching 8.8.8.8 -- eg none of the local network machines are DNS resolved (which is fine on an ad-hoc LAN). At least that is what happens by default under Ubuntu. I found it easier to just stop and disable systemd-resolved and then manually edit /etc/resolv.conf to reference the local Bind9 name server when I set up a LAN with a local Bind9 name server.
On 5/24/2024 10:49 AM, Robert Heller wrote:
Normally, with systemd-resolved running /etc/resolv.conf is NOT an editable file, but a symlink to a file under systemd-resolved control, and usually systemd-resolved is running its own caching only name server (dmasq?) that is caching 8.8.8.8 -- eg none of the local network machines are DNS resolved (which is fine on an ad-hoc LAN). At least that is what happens by default under Ubuntu. I found it easier to just stop and disable systemd-resolved and then manually edit /etc/resolv.conf to reference the local Bind9 name server when I set up a LAN with a local Bind9 name server.
Whether it's managed or not, CUPS is going to consult it when it uses the resolver APIs in glibc. So you should be able to cat it to see what the resolver APIs will use.
I haven't yet used systemd-resolved so I haven't studied its config in detail. It looks like the config is in /etc/systemd/resolved.conf*:
https://wiki.archlinux.org/title/systemd-resolved
[Sorry about the typo on /etc/resolv.conf. Thunderbird insisted on spellchecking and I didn't notice it.]
Robert Heller wrote:
Normally, with systemd-resolved running /etc/resolv.conf is NOT an editable file, but a symlink to a file under systemd-resolved control, and usually systemd-resolved is running its own caching only name server (dmasq?) ...
Kenneth Porter wrote:
Whether it's managed or not, CUPS is going to consult it when it uses the resolver APIs in glibc. So you should be able to cat it to see what the resolver APIs will use.
Running "systemctl stop systemd-resolved" did not change the problem. On this system, /etc/resolv.conf is NOT a symlink. It contains only a single reference to the local BIND9 and a search statement with one argument.
Does dig consult the proper server?
You could run CUPS or another failing program under strace to log the system calls and that might help identify where it's getting the wrong server from.
At Fri, 24 May 2024 12:24:02 -0700 CentOS mailing list discuss@lists.centos.org wrote:
Does dig consult the proper server?
You could run CUPS or another failing program under strace to log the system calls and that might help identify where it's getting the wrong server from.
Another thing to check is whether there is an /etc/hosts file and what it contains. And what is in /etc/nsswitch.conf as well.
Discuss mailing list -- discuss@lists.centos.org To unsubscribe send an email to discuss-leave@lists.centos.org
Robert Heller wrote:
Question: is dmasq running somewhere? Maybe "orphaned"?
Another thing to check is whether there is an /etc/hosts file and what it contains. And what is in /etc/nsswitch.conf as well.
nsswitch.conf contains: hosts: files mdns4_minimal [NOTFOUND=return] resolve dns myhostname
/etc/hosts contains only the usual localhost stuff and one entry for a related company with no public name available.
"ps -ef" does not reveal any process name containing "dmasq".
On 5/24/2024 1:41 PM, Dave Close wrote:
nsswitch.conf contains: hosts: files mdns4_minimal [NOTFOUND=return] resolve dns myhostname
Using .local for your LAN and putting mdns4_minimal before resolve and dns is probably part of the issue. mdns4_minimal is probably intercepting the query. What it does with it is anyone's guess.
https://superuser.com/questions/1417190/why-do-i-need-to-change-the-order-of...
You could try changing the order in nsswitch.conf but long-term, try using a different TLD for your LAN. IANA recently proposed using .internal for that. (I've been using .lan after my company name.)
https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain...
Kenneth Porter wrote:
nsswitch.conf contains: hosts: files mdns4_minimal [NOTFOUND=return] resolve dns myhostname
Using .local for your LAN and putting mdns4_minimal before resolve and dns is probably part of the issue. mdns4_minimal is probably intercepting the query. What it does with it is anyone's guess.
You could try changing the order in nsswitch.conf but long-term, try using a different TLD for your LAN. IANA recently proposed using .internal for that. (I've been using .lan after my company name.)
Thanks. I simplified nsswitch.conf to just "host: files dns" and the problem seems to be resolved. (Time will tell.)
Changing the TLD will take some time and care but that seems like a good idea. Thanks!
Kenneth Porter wrote:
Does dig consult the proper server?
dig responds instantly but with the query REFUSED when asking for a simple host name, for example "pfa". When asking for the qualified host name, "pfa.local", the output contains the suspicious lines, "WARNING: .local is reserved for Multicast DNS You are currently testing what happens when an mDNS query is leaked to DNS".
So, is it possible that this issue is a result of using ".local" as a pseudo-TLD for the local network?
At Fri, 24 May 2024 13:41:12 -0700 CentOS mailing list discuss@lists.centos.org wrote:
Kenneth Porter wrote:
Does dig consult the proper server?
dig responds instantly but with the query REFUSED when asking for a simple host name, for example "pfa". When asking for the qualified host name, "pfa.local", the output contains the suspicious lines, "WARNING: .local is reserved for Multicast DNS You are currently testing what happens when an mDNS query is leaked to DNS".
So, is it possible that this issue is a result of using ".local" as a pseudo-TLD for the local network?
You really should not be using ".local" as a pseudo-TLD for the local network.
At Fri, 24 May 2024 11:59:23 -0700 CentOS mailing list discuss@lists.centos.org wrote:
Robert Heller wrote:
Normally, with systemd-resolved running /etc/resolv.conf is NOT an editable file, but a symlink to a file under systemd-resolved control, and usually systemd-resolved is running its own caching only name server (dmasq?) ...
Kenneth Porter wrote:
Whether it's managed or not, CUPS is going to consult it when it uses the resolver APIs in glibc. So you should be able to cat it to see what the resolver APIs will use.
Running "systemctl stop systemd-resolved" did not change the problem. On this system, /etc/resolv.conf is NOT a symlink. It contains only a single reference to the local BIND9 and a search statement with one argument.
Question: is dmasq running somewhere? Maybe "orphaned"?
At Fri, 24 May 2024 10:21:16 -0700 CentOS mailing list discuss@lists.centos.org wrote:
What's in /etc/resolve.conf?
That should be /etc/resolv.conf -- the 'e' in resolve is left out. With systemd-resolved running it would be a symlink to something under systemd-resolved control (there is a config file somewhere for systemd-resolved that controls what that is).
Discuss mailing list -- discuss@lists.centos.org To unsubscribe send an email to discuss-leave@lists.centos.org
-
Aleksandar Ivanisevic -
Dave Close -
Kenneth Porter -
Robert Heller -
Simon Matter