How to Query DNS Records and Diagnose Resolvers in Linux Using resolvectl query

Modern Linux distributions utilizing systemd rely on the systemd-resolved daemon to manage domain name resolution, local caching, DNSSEC validation, and split-DNS configurations for VPN connections. While traditional diagnostic tools like dig and nslookup bypass the local systemd resolver bus to send raw UDP/TCP queries directly to remote upstream servers, they do not reflect the exact resolution path experienced by native Linux applications. The resolvectl query command provides an authoritative diagnostic method to query DNS records directly through the active systemd-resolved stack.

Why resolvectl query Is Essential for Modern Linux Networking

In standard desktop and server deployments running Ubuntu, Debian, Fedora, or openSUSE, applications call standard glibc resolver functions (such as getaddrinfo), which communicate with systemd-resolved via D-Bus or the local loopback stub listener at 127.0.0.53. Testing name resolution with external utilities often produces misleading results when split-DNS VPN routing or per-link domain search lists are active. Running resolvectl query tests the real-world resolution pipeline, confirming whether local cache hits occur, which network interface handled the transaction, and whether DNSSEC verification succeeded.

Executing a Basic Domain Name Query

To perform an address lookup for any domain hostname, invoke resolvectl query followed by the target domain:

resolvectl query example.com

The resulting output lists both IPv4 (A) and IPv6 (AAAA) addresses alongside low-level resolver telemetry:

example.com: 93.184.215.14                      -- link: eth0
             2606:2800:21f:cb07:6820:80da:af6b:8b2c -- link: eth0

-- Information acquired via protocol DNS in 14.2ms.
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: no
-- Data from: network

This diagnostic reveals critical performance details: the exact network interface that processed the request (eth0), the overall lookup duration (14.2ms), whether the response passed DNSSEC authentication (Data is authenticated: yes), and whether the answer originated from a remote server or local cache.

Querying Specific DNS Resource Record Types

By default, resolvectl query retrieves standard IP address mappings. You can query specific DNS resource records by supplying the -t (type) parameter:

• Mail Exchanger (MX) Records:
  resolvectl query -t MX example.com
• Text (TXT) Verification Records:
  resolvectl query -t TXT example.com
• Canonical Name (CNAME) Aliases:
  resolvectl query -t CNAME www.example.com
• Name Server (NS) Delegations:
  resolvectl query -t NS example.com

Auditing Reverse DNS Lookups (PTR Records)

To diagnose reverse DNS configurations and verify pointer records for an IP address, pass the IPv4 or IPv6 address directly to the query command without manual in-addr.arpa formatting:

resolvectl query 1.1.1.1

The resolver automatically reverses the octets, formats the PTR query, and returns the fully qualified domain name:

1.1.1.1: one.one.one.one                        -- link: eth0

Targeting Specific Network Interfaces for Split-DNS Auditing

When connected to corporate VPN tunnels (such as WireGuard or OpenVPN), DNS servers are often segmented so that internal corporate hostnames resolve through the VPN tunnel while public traffic routes over physical Wi-Fi or Ethernet. To audit resolution on a specific network interface, supply the -i (interface) flag:

resolvectl query -i wg0 internal.corp.local

If the corporate domain fails to resolve over your default interface but succeeds when directed to wg0, this immediately flags a split-DNS routing configuration error within your NetworkManager or Netplan profiles.

Testing Local Resolver Cache Performance

To verify that systemd-resolved caches responses correctly, repeat a query immediately after initial execution:

resolvectl query example.com

Notice the updated footer metrics:

-- Information acquired via protocol DNS in 0.3ms.
-- Data from: cache

Sub-millisecond latency and the Data from: cache flag prove that local caching operates as designed, eliminating redundant upstream network traffic across your Linux workstation.