Since VPN technology is used to connect sites and users, usually most it’s implementations provide an ability to change DNS servers to available on remote side. But not all of them are able to do this neatly and without breaking existing configuration. And if routing configuration works fine in most use cases, dealing with resolv.conf can dramatically slow down operating system performance or even break it, ‘cos uncountable regular operations rely on quick and correct domain resolving.
So, some of VPN clients, in my case it was FortiGate VPN client, deal with one of the most important system configuration files in most barbaric way: it changes file contents correspondingly FortiGate server instructions, flushing existing changes and (this really drives me crazy) don’t restore them after connection termination! And there are no any way (at least described in manuals) to change or disable this behavior. In my case it broke postal service (postfix) since it has no way to specify DNS server to use.
So we need to fix this this magical piece of software. Logic suggests three ways:
1. Somehow isolate the intruder from system it tries to break. This involves containerisation or running on separated machine. Not always possible way since not all infrastructure can use containerisation or change their routing policy just owing to idiotic decisions of software developers;
2. Setup a quasi watchdog which should watch for file changes and roll them back, forcing correct confuguration. Pros: better for complex installations. Cons: part of queries will use the wrong DNS server and, least for mail, can result it information loss or large delivery delay, which is unacceptable;
3. Forbid interfering with resolv.conf file for all users and processes, handling it manually.
I chose third way, since my DNS config is pretty static and used chattr +i to make resolv.conf readonly to ALL users and processes.