Bug 2188986

Summary: dchp-client does not recognize a local named server
Product: [Fedora] Fedora Reporter: Todd <ToddAndMargo>
Component: dhcpAssignee: Martin Osvald 🛹 <mosvald>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 37CC: jorton, mosvald, pavel, pemensik
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Todd 2023-04-24 00:07:51 UTC
Fedora 37
dhcp-client-12:4.4.3-4.P1.fc37.x86_64
bind-chroot-9.18.13-1.fc37.x86_64

I am running a local caching name server.  The last update to dchp-client hosed my networking.  The new script does not pick up that I am running a local caching name server and decides to alter /etc/named.conf to something else.

/etc/named.conf    which is not a link

   Altered file:
      search netgear.com acme.local   # netgear.com ??????
      nameserver 192.168.250.1        # address of my gateway

   Should have left alone at:
      search acme.local
      nameserver 127.0.0.1

And it keeps changing it back !!!!!
    ; generated by /usr/sbin/dhclient-script
    search netgear.com acme.local
    nameserver 192.168.250.1

/etc/sysconfig/network-scripts/ifcfg-eno2 contains the following:
       BOOTPROTO=dhcp
       DNS1=127.0.0.1

Those are not picked up on either.

Please fix this behavior.

Many thanks,
-T

Comment 1 Todd 2023-04-24 10:27:05 UTC
Oops!

bad:  /etc/named.conf    which is not a link
good: /etc/resolv.conf    which is not a link

Comment 2 Martin Osvald 🛹 2023-04-24 13:46:03 UTC
This is kind of expected behavior in connection with your current setup, but there are a few ways to prevent /etc/resolv.conf to be overwritten though.

The quickest solution is to modify /etc/resolv.conf as desired and then set 'i' attribute to it (this will prevent any modification to the file):

~~~
# chattr +i /etc/resolv.conf
~~~

One problem could arise if more people administrate your machine and they are not aware of this change (they could remove this attribute: chattr -i /etc/resolv.conf).

Another possibility is to set 'PEERDNS=no' in /etc/sysconfig/network-scripts/ifcfg-eno2 if the resolv.conf should not be overwritten with the DNS servers obtained via DHCP:

~~~
PEERDNS=no
~~~

Besides /usr/sbin/dhclient-script the /etc/resolv.conf can be rewritten by NetworkManager itself and in that case, also the below should be set in /etc/NetworkManager/NetworkManager.conf and NetworkManager restarted afterward:

~~~
[main]
dns=none
~~~

Otherwise, I can see you are still using the old way of configuring the network. I would recommend you to read this article:

https://fedoramagazine.org/converting-networkmanager-from-ifcfg-to-keyfiles/

Comment 3 Todd 2023-04-24 15:19:33 UTC
Hi Martin,

Thank you for the tips.

My network setup is complicated and it took me years to get everything working correctly.  I am loath to try to redo everything over again.  It also drives me a bit nuts with the troubleshooting when you guys change the behavior of things.  My system was down most of the day fixing multiple things.

My networking enables VPN's, fake adapters, internal and external networks, connect to a serial of virtual machines simulating a small business network (Samba, DHCP Server with fixed IP to MAC addresses, caching DNS which talks to DHCP server, etc.), including a very strong firewall.  So far what I have seen with Network Manager is that is nice if you only have one network adapter, but it really does not help with my complicated setup.

To work around the changes in behavior, I had to do the following:

    # nmcli device modify eno2 ipv4.dns "127.0.0.1"
    # nmcli connection modify "Wired connection 2" ipv4.ignore-auto-dns yes

And then, I found out that `dhclient -r; dhclient` did not honor the above and updated my /etc/resolv.conf DNS to the DHCP Server's response for DNS anyway.  Please fix that too.

Fortunately both

    /usr/bin/nmcli connection up "Wired connection 2"
    /usr/bin/nmcli device up eno2 

fixes dhclient's goof up.

It took me three hours to trying figure out who was changing my resolv.conf back to DHCP's DNS and figure out that it was their call to calling dhclient.  (It was my iptables script making sure I had the latest dhcp IP information before calling the tables.)

My `PEERDNS=no` was commented out.  I updated it.

Many thanks,
-T