Removing a Stale VPN Record From the resolvconf Database

An internal name still resolves to the VPN server a day after the tunnel closed, and the resolver file keeps coming back with that entry. Where Debian's resolvconf owns the state, that file is assembled from supplier records, and one of them is the leftover. Deleting the record takes a minute; proving it is safe to delete is the real work. These gates run in order, and a failed gate ends the procedure instead of sending you to the next step.

Confirm resolvconf Owns the State

Identify the owner first, because the same symptom under systemd-resolved needs different commands and a different repair. The resolvconf package keeps a database under /run/resolvconf and points /etc/resolv.conf at the file it builds from that database. Two readings settle the question: the symlink target, and whether the package is installed and active. A target under /run/systemd/resolve means the other design, where nothing below applies.

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

If the link points elsewhere or the package is missing, stop here. A compatibility wrapper that borrowed the name, shipped by another resolver manager, does not own this database.

The Database Holds Inputs, Not the Answer

The database holds inputs and the file is an output, so listing inputs is the only way to see which program installed the entry you want gone. The records are short, and their keys are the handles you need later. Read them before deciding which one is stale, because a name that looks like a VPN interface can belong to a different client. Keep private addresses and internal search domains out of shared diagnostics; the key alone usually identifies the record.

sudo resolvconf --list
sudo resolvconf -i

The first command prints supplied records without processing them, and the second lists the interfaces that currently provide DNS configuration. Keys are conventionally built from an interface name plus the supplying program. The resolvconf manual describes the database those keys address.

Copy the key out of the output instead of rebuilding it. An entry is not called tun0 merely because an old script used that name.

Prove the Record Has No Owner

A record is safe to delete when no live connection installed it. Correlate the key with the connection that created it, then confirm that connection is gone. That correlation is the whole gate, and it is the step most often skipped on the way to the delete command. If the evidence is ambiguous, treat the record as live and stop.

Process names are weak evidence. OpenConnect calls vpnc-script, so a check for a vpnc process says nothing about which record is current. A fresh connection can also reuse an interface name that an old one left behind, which makes the key look older than it is. Compare the server address inside the record with the addresses of tunnels that are still up, and stop if they match.

A normal disconnect through the owning manager is the first remedy. It withdraws what that connection installed and leaves other suppliers untouched.

Check the Removal and the Rewrite

With the record confirmed stale, delete it by exact key and then read the result rather than assuming it. The command changes resolver state for every application on the host, so run it in a window you control. Quote the key, because it contains characters the shell would otherwise expand. The placeholder in the block stands for the key you copied out of the list, not for a literal string.

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

Deletion runs the update scripts when updating is enabled; with updates disabled it defers the update, so a removed record and a rewritten file are separate events. Re-read the list and confirm the key is gone before looking at the file. Then query one name that should still resolve through the remaining suppliers and one public name, and compare both with what you saw before the change. If a private name stops resolving entirely, that record was still carrying it.

resolvconf -u only runs those update scripts. It never identifies or deletes an obsolete record, and rebuilding from stale inputs reproduces the same unwanted file.

A Killed Disconnect Hook Leaves the Record Behind

A one-off cleanup restores today's state, and the next interrupted shutdown puts the record back. Walk the teardown path: the client's disconnect hook, the helper that hook calls, and what happens when either is killed. An interrupted shutdown is the usual origin, because the hook never ran at all. Log the hook's exit status once and you will know whether it is failing quietly.

Keep setup and cleanup under one owner. A second script that guesses interface names will eventually delete another connection's record, which is worse than the stale entry you started with. The owner should also decide when a record is stale, because it knows which connection installed it.

Then exercise the lifecycle: connect, disconnect, list the records again. The entry disappearing on its own is the only proof that the repair holds.