Linux Command #60 introduces resolvectl, a command-line tool for querying and inspecting the systemd-resolved name-resolution service on supported Linux systems. When an IP address responds but a website name does not, resolvectl can help reveal which DNS servers are configured, how DNS is routed on each interface, and whether the resolver can answer a query.

This nonduplicate command lesson follows Linux Command #59 — tcpdump (packet capture), #58 — nstat (kernel network counters), and #57 — nmcli (NetworkManager configuration). These tools complement rather than replace each other.

Elementary Overview

DNS, or the Domain Name System, translates domain names such as example.com into IP addresses and supports other record lookups. Many distributions use systemd-resolved to provide local name-resolution services and choose upstream DNS servers. resolvectl asks that local service about its current state and can make test lookups through it. It does not work as expected on every Linux installation: the host needs a compatible, running systemd-resolved service.

Learning Objectives

• Check whether systemd-resolved is available before troubleshooting.
• Read global and per-interface resolver settings with resolvectl status.
• Query a hostname and inspect DNS record types without changing configuration.
• Understand the difference between the local stub address and an upstream DNS server.
• Compare configured per-link domains and DNS servers when troubleshooting split-DNS or VPN behavior.
• Recognize why clearing a cache is not a substitute for finding a root cause.

1. Verify the Resolver Service

systemctl status systemd-resolved
resolvectl --help

The first command checks whether the service exists and is active. The second displays available resolvectl options. On some distributions, the service is absent or disabled and a different resolver is used; in that case, do not assume these commands control the host’s actual DNS configuration. The upstream systemd documentation is the authoritative reference for the exact installed version.

Adrien Linuxtricks (2024), a practical systemd-resolved walkthrough with resolvectl status at approximately 03:22 and lookup demonstrations at approximately 12:15. Commentary is in French; on-screen commands are useful across languages.

2. Display Global and Per-Link DNS Settings

resolvectl status

The result separates Global resolver settings from Link sections for individual network interfaces. Look for the active DNS servers, DNS domains, current DNS scope, and whether the system reports a stub or another resolv.conf handling mode. An interface’s DNS server may differ from the global fallback server, especially when NetworkManager, DHCP, VPN software, or multiple interfaces are in use.

resolvectl dns
resolvectl domain

resolvectl dns lists DNS servers known to the resolver. resolvectl domain lists per-link and global domains, including possible routing-only domains prefixed with ~. A route-only DNS domain such as ~corp.example instructs systemd-resolved to prefer associated DNS servers for matching names; it does not create public DNS records.

3. Query a Hostname

resolvectl query example.com

The command requests name resolution and prints the results available to systemd-resolved, which may include IPv4 and IPv6 addresses, status information, interface details, and resolution time. If it succeeds while an application fails, investigate the application’s resolver path, proxy or VPN settings, and name-resolution stack rather than immediately changing DNS servers.

resolvectl query --type=A example.com
resolvectl query --type=AAAA example.com
resolvectl query --type=MX example.com

These queries request specific DNS record types: IPv4 address, IPv6 address, and mail exchanger. A domain does not need to publish every record type. Returned values will vary over time, and a successful response to one type does not prove another type exists.

4. What Does 127.0.0.53 Mean?

On systems configured for systemd-resolved‘s traditional DNS stub listener, /etc/resolv.conf may list 127.0.0.53. This loopback address identifies a local service on the host, not the upstream public resolver that ultimately answers a query. Do not misinterpret it as evidence that all DNS traffic stays on the machine.

ls -l /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status

The first command reveals whether /etc/resolv.conf is a symbolic link; the second displays its contents. Managed hosts may use a symlink generated by systemd-resolved, NetworkManager, or another network manager. Manually overwriting the file is often temporary or actively harmful. Preserve configuration ownership and use the site’s supported management method.

5. A Troubleshooting Example

Scenario: a server can reach its default gateway but fails to resolve a private internal hostname after connecting to a VPN. First confirm that systemd-resolved is active, then inspect link-specific DNS servers and the routing domains assigned to the VPN. A public resolver can legitimately return no record for a private-only hostname; the correct private DNS server must be selected for that domain.

resolvectl status
resolvectl dns
resolvectl domain
resolvectl query files.corp.example

files.corp.example is an illustrative hostname, not a real service. Record the resolver’s reported routing domain and active DNS servers, compare them with the VPN’s approved settings, and test whether the internal DNS service is reachable. Avoid replacing internal DNS settings with public resolvers merely to obtain an answer to a public name.

A March 2026 Linux community discussion illustrates a common distinction: global DNS settings and link-specific DNS settings need not be identical. Community questions are troubleshooting examples, not technical specifications.

6. Read Resolver Statistics

resolvectl statistics

The statistics view reports resolver counters and DNSSEC-related information where supported. It can help characterize caching and validation behavior, but statistics are not a substitute for checking the specific response to a failed lookup or examining the underlying network. The systemd-resolved status and DNS configuration remain the first checks.

7. Cache Clearing — A Controlled Last Step

sudo resolvectl flush-caches

This clears the locally maintained DNS resource-record caches within systemd-resolved. It may be useful after an approved DNS change when stale cached results are suspected, but it does not repair an incorrect upstream DNS server, unreachable VPN, malformed zone, or absent name. Avoid running it during an incident without noting the before-and-after state, because cache clearing destroys useful diagnostic evidence and may temporarily increase DNS traffic.

A second real-world example examines differing DNS servers received through DHCP and shown by resolvectl status. The discussion shows why per-link configuration should be reviewed before making changes.

Troubleshooting Checklist

• Command not found: confirm the distribution installs the resolvectl tool and supports systemd-resolved.
• Service not running: inspect system services and the actual resolver configuration; do not blindly start competing resolver services.
• DNS server differs by link: inspect DHCP, NetworkManager, VPN settings, and routing-only DNS domains.
• Public names work, internal names fail: verify the internal DNS namespace and VPN domain routing.
• Some applications fail while resolvectl query succeeds: compare NSS, DNS stub, application DNS-over-HTTPS, and proxy paths.
• One query returns no records: check the record type and domain existence before assuming an outage.

Hey Insights (2025), an English-language overview of troubleshooting DNS with systemd-resolved, including status, test queries, and cache handling. Use the vendor manual for authoritative syntax.

Practice Exercise

On an authorized Linux lab machine using systemd-resolved, run the read-only commands resolvectl status, resolvectl dns, resolvectl domain, and resolvectl query example.com. Write down the active DNS server for one interface, whether a split-DNS domain is configured, and the returned record type. Compare what /etc/resolv.conf reports with what resolvectl status reports. Do not change server configuration as part of this exercise.

Knowledge Check

• What does resolvectl status reveal that a simple ping test may not?
• Why might 127.0.0.53 appear in /etc/resolv.conf?
• What is the difference between a global fallback DNS server and a DNS server assigned to a network link?
• Does flush-caches fix an incorrect VPN DNS routing configuration?
• Which command would you run first to query example.com through the local resolver?

Answers: (1) Resolver state, per-link DNS servers, and DNS domains. (2) It can be the local systemd-resolved stub listener. (3) The link’s DNS settings may be selected for traffic routed over that interface or domain, while global fallback serves a different role. (4) No. (5) resolvectl query example.com.

Additional References

• systemd — resolvectl manual (primary technical reference).
• systemd-resolved service and /etc/resolv.conf behavior.
• OSNTC.026 — DNS troubleshooting with nslookup, dig, and packet capture.
• Aaron Filbert — DNS Architecture (CC BY-SA 4.0).

Safety note: DNS changes can disrupt software updates, authentication, monitoring, VPN access and service discovery. Perform write operations only under approved change control, with the current configuration recorded and rollback available.

BitcoinVersus.Tech Editor’s Note: We volunteer daily to ensure the credibility of the information on this platform is Verifiably True. If you would like to support to help further secure the integrity of our research initiatives, please donate using the QR code provided

For best QR-code scanning results, please scan this donation code from a desktop or larger screen. Mobile screens may prevent camera recognition.