Azure VPN Client Linux: could not set DNS domains

The tunnel comes up, the certificate validates, and then a dialog says the DNS server or domains could not be set. On Linux that dialog is usually not about the gateway: the client hands name configuration to systemd-resolved over D-Bus, and a refused handoff leaves the interface up with resolution still pointing at the old link. The same laptop resolves names fine before the profile gains a suffix, which is the clue worth following. Nothing about the tunnel changed at the moment the dialog appeared.

Without a suffix the client only pushes name servers. Add a search domain and a second call joins it, SetLinkDomains, with an authorization check of its own, which is why the identical profile behaves on Windows and fails here. The gateway pushes the same settings either way, and the component refusing them is local.

Confirm systemd-resolved is the resolver in charge

This client speaks to systemd-resolved and to nothing else. Arch and several other distributions ship it disabled, and /etc/resolv.conf can belong to a different resolver entirely, so establish the owner before you look at permissions.

Three commands settle it:

systemctl status systemd-resolved
ls -l /etc/resolv.conf
resolvectl status

You are looking for an active service, a symlink aimed at /run/systemd/resolve/stub-resolv.conf, and per-link DNS in resolvectl. When NetworkManager holds the ownership instead, move it to resolved rather than fighting the client; the drop-in below sets both keys:

[main]
dns=systemd-resolved
systemd-resolved=true

Restart NetworkManager once that file exists. An inactive resolver paired with a client that keeps calling its D-Bus name produces an error that names neither of them.

Watch the D-Bus call that fails

This step turns the dialog into a specific answer. Watch the resolver interface in one terminal and the journal in another, then reconnect:

sudo dbus-monitor --system "interface='org.freedesktop.resolve1.Manager'"
journalctl -fu systemd-resolved

Three calls should appear: SetLinkDNS, SetLinkDomains and SetLinkDefaultRoute. The one that comes back as an error reply is the one to fix. That reply usually names its reason, for instance org.freedesktop.DBus.Error.AccessDenied against SetLinkDomains. Note which call it was, because the next section is about letting that call through.

Grant the polkit actions the client needs

Read the policy before writing a rule. A client running as a service cannot answer an interactive prompt, so an implicit auth_admin_keep is a dead end.

pkaction --verbose --action-id org.freedesktop.resolve1.set-domains
pkaction --action-id org.freedesktop.resolve1.set-dns-servers --verbose

If the answer is auth_admin_keep, the client needs an explicit rule. The snippet below allows the four resolve1 actions a VPN client uses during a connection and leaves everything else at polkit.Result.NOT_HANDLED:

polkit.addRule(function(action, subject) {
  var allowed = [
    "org.freedesktop.resolve1.set-dns-servers",
    "org.freedesktop.resolve1.set-domains",
    "org.freedesktop.resolve1.set-default-route",
    "org.freedesktop.resolve1.revert"
  ];
  if (allowed.indexOf(action.id) !== -1 &&
      subject.isInGroup("wheel")) {
    return polkit.Result.YES;
  }
  return polkit.Result.NOT_HANDLED;
});

Put it in /etc/polkit-1/rules.d/ as a file you will recognise later, such as 50-azurevpn.rules, and replace the group name in the snippet with your own before logging out and back in. Keep it narrow, because allowing every resolve1 action for every account is broader than this client needs and much harder to audit afterwards.

Check the profile XML before you edit polkit

A profile edited by hand can be ignored without a word. Microsoft documents a flat layout in which dnsserver entries sit directly inside dnsservers and suffixes inside dnssuffixes. An extra wrapper element around each address is not that shape, and the client quietly falls back to whatever the gateway pushes.

Run the removal test before touching polkit. Strip the suffix block, reconnect, and watch whether the dialog changes. If it does, the failing call was the domain handoff, and the fix is authorization rather than another XML edit.

Verify the domain on the tunnel link

Reconnect and read resolvectl status again, checking that the tunnel link carries the name server and the search domain together. Resolve a short private name rather than a public one. When the name resolves but the service behind it does not answer, the DNS handoff worked and the remaining problem is routing.

Write the resolver owner, the D-Bus call that failed, the rule file and the profile version into the ticket. Those four lines turn the next Linux laptop into a short fix instead of a repeat investigation.