How to persist resolv.conf options such as rotate, timeout in CentOS?

Question

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.?

Solution 1

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

Solution 2

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.

Solution 3

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

Comments

[Adam C]

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]

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

[Evgeny F]

It's a part of openresolv package

[Adam C]

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]

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.

[Thomas Guyot-Sionnest]

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.

[Adam C]

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.

[slf]

this worked, but I also had to run resolvconf -u

[jeremyjjbrown]

This worked for me.

[Brian Peterson]

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

[Adam C]

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: superuser.com/q/110808/113572

[HugoPoi]

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.

[Thomas Guyot-Sionnest]

@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.