12

CentOS will wipe out any manual changes made to /etc/resolv.conf periodically. The defaults in Linux are poor in terms of failing over in a reasonable time (query name servers in same order every time, 5 second timeout, 2 retries).

Hence, the first DNS in your resolv.conf is essentially critical path. If it fails you can be looking at 10 seconds before you fail over.

These defaults are tweakable (see resolv.conf man page), but how can any changes be made permanent in CentOS and persist through reboots etc.?

Adam C
  • 5,222
  • 2
  • 30
  • 52

7 Answers7

16

The answer can be found in the /sbin/dhclient-script:

if [ -n "${RES_OPTIONS}" ]; then
    echo "options ${RES_OPTIONS}" >> ${rscf}
fi

But, it's not terribly obvious where you can set RES_OPTIONS to make the script pick it up - some things like the search domain can be set in the ifcfg-ethX file, but resolver options are set elsewhere. The file you want is in fact /etc/sysconfig/network. To set the relevant options, add something like this line to that file:

RES_OPTIONS="rotate timeout:1 retries:1"

That will set the timeout to 1 second, use a single retry and tell the client to rotate its resolvers per request instead of sequentially going through the list each time.

If you would like to have the changes take effect immediately, then issue a service network restart command and check out your new /etc/resolv.conf in all its glory. Here's what mine looked like when testing this out:

# cat /etc/resolv.conf 
; generated by /sbin/dhclient-script
search example.com
options rotate timeout:1 retries:1
nameserver 10.1.1.2
nameserver 10.1.1.1
Adam C
  • 5,222
  • 2
  • 30
  • 52
  • You mention search domain is configurable via the interface file, what option do you set in /etc/sysconfig/network-scripts/ifcfg-X to set the search domain? Is it SEARCH, DOMAIN, RES_OPTIONS? Thanks – Brian Peterson Apr 07 '21 at 17:22
  • 1
    be aware that this may have changed in newer versions and that I am answering from memory because I do not run CentOS anywhere currently. `SEARCH` is usually how you set the options in `resolv.conf`, with `DOMAIN=` being the setting in the `ifcfg` files. There is a decent bunch of answers here: https://superuser.com/q/110808/113572 – Adam C Apr 08 '21 at 09:48
6

The accepted answer is when using legacy networking scripts. If you use NetworkManager you might not even have /etc/sysconfig/network, and if you do it will still not be used for connections managed by NetworkManager.

If you use NetworkManager:

To add options, ex adding rotate to bond0:

nmcli con mod bond0 +ipv4.dns-options rotate

To remove that option:

nmcli con mod bond0 -ipv4.dns-options rotate

The + is good to change options too; NetworkManager is smart enough to detect existing options and update them. For example, changing the timeout value:

root@debian:~# nmcli con show bond0 |grep ipv4.dns-options
ipv4.dns-options:                       "rotate,timeout:5"
root@debian:~# nmcli con mod bond0 +ipv4.dns-options timeout:3
root@debian:~# nmcli con show bond0 |grep ipv4.dns-options
ipv4.dns-options:                       "rotate,timeout:3"

This means the value is ignored for remove and not even needed. To remove timeout:

nmcli con mod bond0 -ipv4.dns-options timeout

It will work with a timeout value too but that value will be ignored, so removing timeout:5 will also remove any other timeout value.

NB: While looking into this I came across a related bug that was fixed in network-manager v1.14.6, v1.15.2-dev and v1.16. If you encounter any issue check your network-manager version first.

Thomas Guyot-Sionnest
  • 449
  • 4
  • 6
  • 1
    When adding a new answer to an old accepted answer it's a good idea to note how old a question and answer is. What is considered legacy now was not necessarily so 4+ years ago when the question was asked. Rather than tagging as legacy, if you noted when the defaults changed (what CentOS version - 8 perhaps?) and then proceeded to add your information it would be a far more helpful answer. Alternatively re-ask and answer your own version (for newer CentOS versions or when using Network Manager for example) and link back to this older one for reference. – Adam C Apr 16 '20 at 11:10
  • The old way may still be valid though... NetworkManager has been around for a long time yet you can still configure the old way in both Debian and CentOS. – Thomas Guyot-Sionnest Apr 16 '20 at 14:39
  • Thanks a lot for this, very convenient solution for adding `+ipv4.dns-options single-request` to avoid waiting for ipv6 dns answer that cause slowness. – HugoPoi Mar 16 '22 at 08:32
  • @HugoPoi what you describe is not entirely true. `single-request` perform request for IPv6 and IPv4 *sequentially* instead of doing it in parallel. Some appliances cannot handle parallel requests for the same domain properly and by turning this on you are actually *slowing down* the lookups so your dns server won't fail to respond or hang on one of the requests. If you are paying for support for your DNS appliance you should raise an issue with them. – Thomas Guyot-Sionnest Mar 17 '22 at 19:52
1

As this answer appeared in my searches for how to do it on my machine (MX Linux, Debian derivative) and it did not had the answer for that distribution, I want to add how to do it for that distribution:

Edit this file:

 /etc/resolvconf/resolv.conf.d/head
Hielke Walinga
  • 111
  • 4
  • 1
    Hi Hielke - it would be a better idea to create your own Q&A for your distribution and answer that - refer back here if you like of course, and by all means drop a comment in the question or the accepted answer linking to your new question/answer. That way people can find it from here, but it should also end up in Google and similar for the more specific search and be easier for people to find/use. – Adam C Jun 30 '20 at 09:21
  • 1
    This worked for me. – jeremyjjbrown Mar 16 '21 at 22:10
0

If you need to do this with flat files rather than nmcli commands (such as with a configuration management tool) Red Hat provides another solution.

Create a script /etc/NetworkManager/dispatcher.d/15-resolv, which copies a custom /etc/resolv.conf into place.

#!/bin/bash
#
# Description : script to override default resolv.conf file
# with customized file.
cp -f /etc/resolv.conf.custom /etc/resolv.conf

After restarting NetworkManager, this script will be executed, replacing the file with your own.

https://access.redhat.com/solutions/61921

Aaron Copley
  • 12,525
  • 5
  • 47
  • 68
0

You can tell NetworkManager not to manage the /etc/resolv.conf file all together.

  1. Create the /etc/NetworkManager/conf.d/90-dns-none.conf file with the following content:

    [main]
dns=none

  2. Reload the NetworkManager service:

    systemctl reload NetworkManager

The documentation this came from has a second solution which involves replacing /etc/resolv.conf with a symlink to your file.

Give this a read: 22. Manually configuring the /etc/resolv.conf file

Aaron Copley
  • 12,525
  • 5
  • 47
  • 68
0

just add 

resolv_conf_options=rotate\ timeout:1\ retries:1

in your resolvconf.conf

Evgeny F
  • 11
  • 1
  • You sure that's an option in CentOS (got a link to docs/something to show it)? I see it as a FreeBSD option and Ubuntu but not finding it in CentOS – Adam C Feb 11 '17 at 22:36
  • It's a part of _openresolv_ package – Evgeny F Feb 12 '17 at 13:34
  • 1
    that doesn't appear to be a standard package, so not really an option for CentOS, especially in controlled environments, not a bad option elsewhere though – Adam C Feb 12 '17 at 20:53
  • this worked, but I also had to run `resolvconf -u` – slf Mar 01 '21 at 21:27
-4

I faced the same problem last time with my new subscribed linux VPS. How i solved it was to use the chattr +i command to make the file immutable. Just go to the /etc folder and run this after you had made necessary changes to the resolv.conf file :

chattr +i resolv.conf

If you wanna revert the setting, just do this:

chattr -i resolv.conf

Full guideline for your reference: http://boxtutor.com/fix-etcresolv-conf-is-not-saving-after-server-reboot/

Chuichi
  • 1
  • 1
    That would be a potential problem here because it would then be unable to pick up changes to name servers from DHCP - it wouldn't change often but I would still want it to work – Adam C Oct 29 '15 at 08:59