In simple terms what is the difference between the two and what takes precedence?
In my experience the /etc/resolve.conf file will win out but I have seen when we get network issues that the network interface will use its own configuration file.

Does the interface hold this information somewhere in its cache when it starts up?

that is the way you put your DNS SERVER on that file.

; generated by /sbin/dhclient-script
search localdomain
nameserver [DNS IP HERE]
nameserver [DNS IP HERE]

that is in my setup.

Network in Redhat is either user specific or system-wide. When it is user specific, the settings are stored in GConf database and GNOME keyring, and are only available during login session for those users who created it. On the other hand, system-wide settings are stored under /etc/sysconfig/network-scripts/ directory in ifcfg- configuration files.

User specific setting can be made through nm-applet and uses NetworkManager service/unit. On the other hand, system-wide settings can be made through ifcfg-xxx file and uses network service/unit. You can also make user specific settings system-wide by checking 'Available to all users' in nm-applet.

You are not supposed to edit /etc/resolv.conf file. It is automatically filled by the setting you have set in /etc/sysconfig/network-script/ifcfg-xxxx file. Make sure PEERDNS is set to YES.

DOMAIN=domain.name
DNS1=8.8.8.8
DNS2=8.8.4.4
PEERDNS=yes

1 members found this post helpful.

Thanks for the reply. Where does it say from Redhat that you are not supposed to edit the /etc/resolve.conf file in favour of /etc/sysconfig/network-scripts/ifcfg-ethX files with a DNS=x.x.x.x field specified. If one has both filled out with different DNS servers, which one will get called first and why?

It gets overwritten. The file itself should say "# Generated by NetworkManager" as the first line.

It is overwritten as the network devices are initialized.

I never stated that I have NetworkManager running. Our SOE builds for servers have NetworkManager disabled by default.

Further reading leads me to believe that resolv.conf is the only file that is being referenced for DNS lookups.
If you have DNS1 set in your interface config file then you have to also reference PEERDNS in how to hanndle it.

Having PEERDNS=NO to me is pointless, why have DNS set in the interface config file in this case?

If the PEERDNS is missing, by looking at the logic in /etc/sysconfig/network-scripts/ifup-post then these DNS servers set in the interface file WILL overwrite what is in /etc/resolv.conf.
So a missing PEERDNS is much like a PEERDNS='yes'. If I am right, be careful with this!

However, is there best practice here? People mention that you should not manually edit the resolv.conf file, but where are people getting this information from? Is there a whitepaper from Redhat that states this or are people assuming that everyone runs NetworkManager in their setup so by default think that only a 'process' should edit the /etc/resolv.conf file?

/etc/resolv.conf gets overwritten by several things - the scripts /etc/sysconfig/network-scripts/ifcfg-xxx files, /etc/sysconfig/network (sometimes), DHCP client (depending on its configuration), and NetworkManager. (BTW, not sure how this fits in, but /usr/lib/systemd/systemd-resolved also has a hand in it. It seems (according to the manpage) to replace the /etc/resolv.conf with a symbolic link to a /run/systemd/resolve/resolv.conf)

At one time there was a "# do not edit this file" warning put in the file. Instead, it has a reference to what modified the file.

It has been getting harder to trace the changes ever since systemd has been added to the system since much of the startup is being hidden, but /etc/resolv.conf has (within the RH world at least) become almost untouchable.

Found out how systemd-resolved gets into it: It is a caching only name server that modified resolv.conf to include it in the search. (I missed a sentence "It also generates /run/systemd/resolve/resolv.conf for compatibility which may be symlinked from /etc/resolv.conf")

1 members found this post helpful.

OK, thanks for the heads up.