Debian resolvconf Record Order: Put the VPN Record First

The VPN's nameserver keeps landing below the LAN one, and editing /etc/resolv.conf fixes it for a few minutes. That file is generated, so the fix never survives. On Debian's resolvconf the ordering input is /etc/resolvconf/interface-order, and it sorts record names rather than DNS addresses. Confirm which resolver stack is actually in charge before you touch either file.

Confirm resolvconf owns the output

Start by asking what wrote the current file and what will write it again. The resolvconf package describes itself as a framework for dynamic resolver configuration, and a host running systemd-resolved or a NetworkManager-managed resolver can look similar from the outside while using a completely different policy.

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

If the resolved path does not lead into resolvconf's runtime directory, stop here: this runbook belongs to a different stack.

Only after that check is worth listing the records resolvconf currently holds.

Read the records before writing patterns

interface-order matches the names of supplier records, not addresses and not kernel interface names. List what is registered so your patterns refer to entries that exist.

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

A record name usually carries a suffix identifying its supplier, so a tunnel record and a DHCP record can share an interface prefix and still sort differently. Copy the exact names from the directory listing. Do not infer a name from the interface name, because the client integration decides what it registers. A name you invent will never match, and the record will fall to the catch-all pattern without any error message.

Write the order as first-match patterns

The file is a list of shell glob patterns, one per line. A record takes the position of the first pattern it matches, so a broad pattern above a specific one makes the specific line unreachable.

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

Put the specific tunnel pattern above the catch-all and above the physical interface pattern.

Keep the other lines the file already had. Replacing the whole policy with an example is how unrelated suppliers silently move; change one line, regenerate, and compare. Patterns cannot contain whitespace, slashes, or a leading dot or tilde, and blank lines and hash comments are ignored.

Regenerate and verify the result

The order applies when the update scripts rebuild the file. Trigger the supported update path instead of editing the generated output, then read what the resolver actually received.

resolvconf -u
cat /etc/resolv.conf

Verify two lookups, not one: a private name that should resolve through the tunnel, and a public control name. If the private name still fails while the order looks correct, the problem is namespace routing rather than record priority, and no amount of reordering will fix it. Compare each answer against the server that returned it, not just against success. A private name answered by the wrong resolver is still a failure, and to the user it looks like a DNS outage.

Retire the stale record instead of demoting it

An obsolete VPN record that keeps reappearing after disconnect is a lifecycle bug in the client integration. Moving it to the bottom hides the symptom and leaves a dead resolver in the list.

Retire it through the component that registers it, then confirm the record directory no longer lists it.

Record the supplier name, the pattern you changed and the two lookups you ran. The next person needs those names more than the story.