OpalSpan

Ubuntu DNS server priority: check the resolver and route before changing the list

By Ready IT ApS

Published

Putting a company DNS server first and a public resolver second does not make the public resolver a safe backup for company names. With systemd-resolved, servers serving the same lookup scope should provide equivalent answers. The service keeps using a selected server until an error causes it to switch; it is not a strict first-server-first policy on every lookup.

And if a website returns HTTP 403, DNS has already done enough for that request to reach an HTTP responder. Changing the resolver list is not a correction for an access refusal. The responder may still be the wrong destination, a proxy or a gateway, so compare the returned address with the expected service before moving to application access checks.

These distinctions matter when an IT provider inherits an Ubuntu machine that can reach public websites but intermittently loses internal names. Here is an evidence-first way to separate DNS selection, IP routing and application failures without resetting the network.

Scope: Ubuntu hosts using systemd-resolved

This workflow targets Ubuntu 22.04 LTS and 24.04 LTS hosts with systemd-resolved active. The persistent correction below is specifically for Netplan with the networkd renderer. Ubuntu desktop installations using NetworkManager, containers with their own resolver, and applications using encrypted DNS or a proxy need their own configuration owner checked instead.

Use the installed manual and help for the actual machine. Current upstream documentation can describe newer features than a distribution package; the commands here avoid relying on new resolver features.

The question that prompted this guide is a real Server Fault discussion about DNS server priority on Ubuntu, posted in May 2025. This is an independently written diagnostic workflow, not a reproduction of its answers.

1. Collect state without changing it

Start with the affected host, not a different computer on the same site. Record the failing fully qualified hostname, approximate failure time and whether the problem affects every application. Do not send private names or logs to a public resolver or paste them into a public forum.

cat /etc/os-release
resolvectl --version
systemctl is-active systemd-resolved
ip -brief address
ip route show
ip -6 route show
ip rule show
resolvectl status
readlink -f /etc/resolv.conf

These are inspection commands. If resolved is inactive or resolvectl is unavailable, stop following this recipe and identify the host’s actual resolver. Do not enable a second service merely to make the commands work.

In resolvectl status, look for the DNS servers, current DNS server, domains and DNS DefaultRoute setting for each relevant link. A DNS routing domain such as ~corp.example selects a resolver scope for matching names; it is not an IP route. The kernel still needs a usable path to that scope’s DNS server.

A nameserver entry of 127.0.0.53 can be normal: it is the local resolved stub, not the upstream company DNS server. If /etc/resolv.conf points to the generated stub file, edit the owning configuration rather than that generated file. A different target may explain why applications and resolvectl disagree. Do not replace the symlink blindly.

2. Test resolution, then the route to the actual destination

The following names and addresses are fictional. Replace them with an authorized service hostname and the DNS server address from the collected state. Do not run the examples unchanged or substitute a public DNS server to investigate private names.

resolvectl query service.corp.example
resolvectl --cache=no query service.corp.example
getent ahosts service.corp.example
ip route get 10.20.0.53

The second query bypasses resolved’s local cache; it is not a cache flush or a security bypass. The getent lookup follows the host’s name-service configuration, which is useful for comparing the application-side lookup path with resolved. Applications may still use a different resolver or their own cache.

The route lookup asks the kernel which path it would choose to the fictional DNS server. It does not send a reachability probe. Inspect the selected interface, source address and gateway against the site’s intended path. For IPv6 destinations, use ip -6 route get with the actual IPv6 address. Policy rules or a different network namespace may require further scoped inspection.

Now repeat the route lookup with the real address returned for the affected service. A route to the DNS server is not necessarily the route to the application. A route existing also does not prove that packets, DNS replies or HTTPS traffic pass a firewall.

Classify the result before changing anything:

  • Resolution times out: check the selected scope, DNS server path and resolver logs. A route that points to the wrong interface is a routing problem to correct at its owner, not evidence that resolved needs removing.
  • The resolver returns NXDOMAIN: the selected DNS service says the name does not exist. Confirm the fully qualified name and whether that server serves the required zone. Do not assume a negative answer triggers a search through unrelated public servers.
  • resolved succeeds but getent fails or differs: inspect the host’s name-service configuration, hosts entries and resolv.conf ownership before altering DNS servers.
  • Resolution returns the expected address but the application fails: continue with the actual service port, TLS, proxy and application response. DNS success does not establish application access.

For an authorized resolver-log check, use journalctl -u systemd-resolved --since "15 minutes ago" --no-pager. Logs may require elevated read access and may contain private identifiers; retain them in the site’s approved case record.

3. Why rearranging DNS addresses can fail

There are two separate choices. First, resolved selects the lookup scope using routing and search domains, preferring the longest matching domain. Multiple links with the same best match can be queried in parallel. Second, it selects a DNS server within a scope and maintains state across queries.

That differs from treating the addresses as a fresh ordered fallback chain for each request. A switch after an error need not immediately return to the first server after one successful query. It is not application-level load balancing, and an HTTP failure is not feedback that tells the DNS service to try another server.

An internal resolver and a public resolver often do not serve equivalent zones. Either arrange for the approved internal resolvers to handle the required public and private lookups, or implement explicit split-DNS routing through the site’s network configuration owner. Do not mix unrelated zones in one list and hope list order protects private-name resolution.

DHCP is another source of effective DNS settings. In Netplan’s networkd backend, DNS supplied by DHCP is used by default and takes precedence over static settings. Inspect the live state instead of assuming the YAML nameserver list is the complete input.

4. Make one persistent correction at the owner

Suppose the evidence establishes a specific defect: this networkd-managed host must use two approved internal resolvers, but DHCP is also supplying an unwanted DNS server. The narrow correction is to retain address assignment and routes while changing only DNS inputs in the existing Netplan definition.

This fictional configuration illustrates those keys. It is not a whole-file replacement. Replace the interface ID, addresses and domain with the site’s approved values, and preserve every unrelated setting.

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: true
      dhcp4-overrides:
        use-dns: false
      nameservers:
        addresses: [10.20.0.53, 10.20.0.54]
        search: [corp.example]

The search domain is optional: include it only if the site’s short-name lookup policy requires it. This example is not a split-DNS configuration. Both resolvers must answer the required zones consistently, and public-name resolution must remain available if the workload needs it.

Review the effective configuration and its source files before editing. Netplan merges files; adding a later file can append DNS-address sequences rather than remove an earlier list. If cloud-init or configuration management owns the definition, correct that source instead of introducing a competing local override.

If DHCPv6 is also enabled with networkd, its override keys and values must match the DHCPv4 overrides. IPv6 router advertisements can supply additional DNS information too; inspect those inputs separately. Do not disable IPv6 to avoid understanding them. A NetworkManager-managed host needs a correction in its active connection configuration, not this networkd-only override.

Before changing a remote host, save the original owning configuration in its approved protected location and ensure a working console or other recovery route. Generate the backend configuration on the running host with sudo netplan generate and resolve validation errors before applying it. Generation is not proof of connectivity.

With a usable recovery route, sudo netplan try offers interactive confirmation and a rollback timeout. It can interrupt remote access. Netplan documents rollback caveats: verify both runtime and on-disk state if it times out or is cancelled. Do not confirm merely because the current SSH session has survived.

5. Verify the correction against the original failure

Read resolvectl status again. Confirm the effective DNS addresses and domains on the intended link, including any unexpected DHCP or IPv6 inputs. Repeat the uncached lookup for the original failing hostname and check the returned address against the approved service.

Then verify one required public hostname, the real application request and a fresh support connection. Recheck the routes to the DNS and service addresses. After the next authorized reconnect or DHCP renewal, confirm the resolver settings remain correct; a successful immediate lookup alone does not prove persistence. Schedule any restart separately if persistence across boot still needs checking.

The handback should say which DNS input changed, which exact lookup and service checks passed, how to restore the original configuration, and what remains unresolved. If the evidence points to a routing or application problem instead, record that finding rather than presenting a DNS change as a repair.

Delegate the investigation, not an unrestricted reset

In OpalSpan, ask Mech to collect the resolver and route evidence from an authorized Linux device, distinguish findings from hypotheses, and propose the smallest correction for review. Request a handback with the verification results and recovery information. Start with read-only scope; a request to inspect is not permission to modify networking.

Your external assistant can instead operate OpalSpan Agent CLI under the same user permissions; the assistant operates the CLI, not the technician. Windows and Linux are supported; macOS is a technical preview, in active development. Neither route guarantees this repair or bypasses device consent. If networking fails, the remote agent may lose access too: recovery cannot depend solely on that connection.

Explore OpalSpan for remote IT support.

Technical references

Checked 13 October 2026. These official project references substantiate the workflow; they do not establish that a particular customer’s machine has been tested.