Unexpected /etc/resolv.conf Updates On CentOS 7

Home » CentOS » Unexpected /etc/resolv.conf Updates On CentOS 7
CentOS 6 Comments

Hi

Does here anyone know exactly when NetworkManager creates or is supposed to create /etc/resolv.conf for a network connection? Is there a way I
can control it, or alternatively, is there a good way to debug the functionality?

I thought that there would simply be an update whenever a connection was established, and an addresses/network info was received (if using DHCP), and that the information would pretty much be left alone after that. However, I’ve lately found that a new file gets written every few hours even though there is no connection change (that I can detect), i.e. the same link is up all along. Does anyone have any ideas why that might happen? I thought at first that the updates could be linked to DHCP
lease renewal, but on closer inspection, that does not seem to be the case. I don’t see anything in the system log related to networking at the points where a new file gets written.

I get the above behaviour for my home Wifi net. It seemed to start after I switched to a new router, but that might be coincidental. It’s a problem for me because I’m also using “commercial” VPN software (not integrated with NetworkManager) that will create it’s own resolv.conf file; it replaces data e.g. from Network Manager when VPN is enabled, and restores it on disable. If NetworkManager “refreshes” the information in the mean time, the DNS config for VPN is lost, and the link doesn’t work as expected…

This is on a CentOS 7 system with all the latest updates.

– Toralf

6 thoughts on - Unexpected /etc/resolv.conf Updates On CentOS 7

  • If you just want to tell NM to clear off and leave your resolv.conf alone do the following:

    If you don’t want it to touch the contents of the file then remove all DNSx= parameters from all ifcfg files and add PEERDNS=“no” instead. Now you are solely responsible for setting the content of /etc/resolv.conf yourself.

    You may also have to edit /etc/NetworkManager/NetworkManager.conf and add dns=none to the [main] section.

    —
    J Martin Rushton MBCS

  • Take a look at change_resolve_conf in
    /etc/sysconfig/network-scripts/network-functions. This is invoked in a few places in that directory, like in ifup-post.

    I’m curious to hear what you find.

  • I might possibly be able to set up a workaround based on that, but it’s not what I really want. Ideally I want NetworkManager to update resolv.conf, but only if it actually set up a new connection and/or got new information. Which is what it seemed to do in the past, but then something changed…

    – Toralf

  • I’m not running CentOS 7 with NetworkManager so I could be wrong but, isn’t it possible to run DHCP internally in NM or use dhclient? If so, did you really check that nothing has happened there like renewing of the lease? And did you also check on the ethernet link level that it never went down for a short period of time? Such things can happen in certain configurations.

    Or, could it be that you have some software which interacts with NetworkManager via dbus and therefore the problem happens?

    Regards, Simon

  • I’m not exactly sure what you mean by running DHCP internally in NM, but dhclient is being used. It’s started automatically with a config generated by NetworManager, and also a NM/connection specific lease file.

    The resolv.conf update time does not match renew, rebind or expire time stored in the lease file, and the file itself is generally not updated when resolv.conf gets rewritten.

    It’s hard to be sure, but I didn’t find anything in the system log to indicate disconnect from the network.

    It may also look like (based on other “scenarios”)
    disconnects/reconnects are actually handled gracefully, as in the VPN
    software detects or is notified about an update, and writes its own resolve.conf

    I’m not quite sure how I can tell.

    But I think I’m onto something now: It may actually look like the problem is caused by IP6 address updates, which I guess are not controlled by dhclient or the traditional leases mechanism. Maybe I’ll post some more details later…

    – Toralf