DNS Commands in Linux: a Cheat Sheet for Checking and Configuring DNS

When a website stops opening, mail starts bouncing, or a new domain does not resolve after migration, experienced administrators check DNS first. Not the server, not the firewall, not the load balancer. DNS, because most network problems originate there: an incorrect record, an outdated cache, an unavailable resolver.

In Linux, there are several powerful utilities for DNS diagnostics and configuration, and they are easier to use than they seem. This article is a detailed breakdown of the main tools: what each command does, when to use it, and which mistakes are better to avoid. At the end, there is a summary cheat-sheet table you can keep handy.

What DNS is and why work with it from the terminal

DNS (Domain Name System) is a distributed system that translates domain names into IP addresses. When you enter a website address, your computer first asks the DNS resolver: “Which IP corresponds to this name?” — and only after receiving the answer does it establish the connection. This entire chain works invisibly until something breaks.

Command-line tools are needed by different people for different reasons. A system administrator checks whether the domain is delegated correctly. A developer wants to make sure the DNS record has updated after deployment. A DevOps engineer tests the configuration before migrating a service. Even without a deep IT background, knowing how to use commands to check and flush DNS saves a lot of time.

In practice, working with DNS in the terminal comes down to several common tasks: query a record, compare answers from different servers, clear the local cache, check whether changes have propagated. Linux has a suitable utility for each of these tasks.

Main tools for working with DNS in Linux

There is no single universal DNS command in Linux for every case. Instead, there is a set of specialized utilities, each good in its own scenario. Let’s go through the main ones.

dig — the main diagnostic utility

dig (Domain Information Groper) is the most powerful Linux command for working with DNS. It is included in the dnsutils package (Debian/Ubuntu) or bind-utils (CentOS/RHEL/Fedora). If the utility is not installed on the system, it is easy to add:

A basic query looks like this:

The response has several sections. The ANSWER SECTION contains the requested records — IP address, type, TTL. The AUTHORITY SECTION shows which NS servers are authoritative for the domain. The ADDITIONAL SECTION adds supporting data, most often the IP addresses of NS servers.

To query a specific record type, add it to the command:

It is also worth noting the ability to specify a particular DNS server for the query. This is useful when comparing responses from different resolvers or when you need to confirm that the authoritative server is already returning the new value:

The +short option reduces output to the essentials — only the IP or record value, without extra details. Convenient for scripts and quick checks:

For reverse DNS lookups (IP → domain), use the -x option — this is the DNS lookup command in the terminal:

Tracing and additional dig options

The +trace option makes dig follow the entire delegation chain — from the root servers to the authoritative NS. Indispensable when diagnosing delegation problems or migrating a domain to another registrar:

The output is long, but you can immediately see at which step something goes wrong. To verify that DNSSEC is configured correctly:

The response should include a record of type RRSIG — a digital signature. Its absence means DNSSEC is not enabled for the domain. Batch checking multiple domains at once:

Where domains.txt is a text file with domains, one per line.

nslookup — a familiar tool on two platforms

nslookup exists in both Linux and Windows. This is the utility most often mentioned when talking about DNS cmd commands in the Windows environment. The simplest query:

The utility will display the resolver in use and the domain’s IP address. To use a specific DNS server:

Querying a specific record type in one line:

In practice, nslookup is somewhat less informative than dig: it does not show the full TTL explicitly and does not support tracing. It is good for quick checks, but for deep diagnostics it is better to use dig.

host — fast and minimal

The host command outputs only what is needed, without sections or flags. Handy when you want a short visual answer:

It works well in scripts and for quick checks, when the detailed dig output is excessive.

resolvectl and systemd-resolve

On modern Linux distributions — Ubuntu 18.04+, Fedora, Arch, and others — DNS resolution is handled by systemd-resolved. To work with it, use resolvectl (the newer option) or systemd-resolve.

To see which DNS server the system is actually using right now:

This command lets you view DNS by network interface, which is especially useful on machines with multiple connections. Run a DNS query through systemd-resolved:

Statistics and current cache status:

The /etc/resolv.conf file

This is not a command, but you need to know its contents. It stores resolver configuration: the DNS server address, search domain, parameters. View it with:

Typical output:

Important: on systems with systemd-resolved, this file is most often a symbolic link. It is not recommended to edit it directly — changes will disappear after a network restart.

Clearing the DNS cache in Linux

The DNS cache stores the results of completed queries so the server does not need to be contacted again. This speeds things up, but sometimes it causes problems: outdated records stay in the cache longer than they should. That is when you need the DNS flush command.

The exact command depends on which service manages DNS on your system.

Via systemd-resolved (Ubuntu, Debian, Fedora)

This is the most common option on modern distributions. DNS cache flush command:

An older syntax that also works:

To check that the cache was actually cleared:

The Current Cache Size line should be 0. This is the DNS refresh command from the perspective of the local system: everything cached is forcibly cleared, and subsequent queries will go directly to the resolver.

Via nscd

If nscd (Name Service Cache Daemon) is installed on the system, you can clear the DNS record cache like this:

Or by fully restarting the service:

Via dnsmasq

dnsmasq is often found in server configurations and on routers with OpenWRT. You can clear its cache by restarting it:

Or send a SIGHUP signal — this will flush the cache without fully stopping the process:

It is worth noting: the DNS cache flush command is a local operation. You are not changing records on the server; you are simply forcing your system to request current data again from the upstream resolver. If the DNS record has not yet updated at the provider, after flushing the cache you will still receive the old answer, but now it will be “fresh” from the perspective of public servers.

DNS commands in Windows: a brief comparison

If you work in a mixed infrastructure or are used to Windows, it is useful to know the Linux equivalents. The ipconfig /displaydns command shows the contents of the local cache — this is analogous to resolvectl statistics. The ipconfig /flushdns command is the Windows version of the flush DNS command, that is, the DNS cache clearing command. It is sometimes searched for as “flash dns command” — it is the same operation, just with a typo in the query.

The ipconfig dns command in Windows is part of the broader ipconfig /all command, which prints the full network configuration, including DNS servers for each adapter. Its Linux equivalent is resolvectl status.

nslookup works the same on both platforms. But Resolve-DnsName in PowerShell is a more powerful tool: it allows you to query specific record types and specify a DNS server.

Table: DNS commands cheat sheet

Configuring a DNS server in Linux

Checking is one side of working with DNS. The other is configuration: telling the system which resolver to use. The method depends on the distribution and the network configuration.

Via Network Manager (nmcli)

This is the standard approach on desktop and server Ubuntu systems where NetworkManager manages the network:

Changes apply immediately and persist after reboot.

Via systemd-resolved

Edit the configuration file:

Specify the desired DNS server command:

Restart the service:

After that, run the DNS cache flush command so the system starts using the new servers instead of serving cached answers based on the old settings:

Permanent changes to /etc/resolv.conf

On servers without Network Manager and systemd-resolved, the file can be edited directly. To prevent it from being overwritten when the network restarts, use the immutable attribute:

The +i flag forbids changing the file even for root. To remove it: sudo chattr -i /etc/resolv.conf. The method works, but it is rough — package updates may cause conflicts.

Practical scenarios for using DNS commands

Scenario 1. The website does not open after changing hosting

The first step is to check which IP the DNS returns for the domain right now:

If the IP is old, you need to understand: have the records not yet updated on the authoritative server, or is the problem in the local cache? Check via a public resolver:

If Google DNS already returns the new IP, but locally you still get the old one, the problem is the cache. Run the DNS flush command and repeat the check. If the public resolver also returns the old IP, the record has not yet propagated; you need to wait for the TTL to expire.

Scenario 2. Mail is not being delivered

Mail issues are most often related to MX records or SPF. Check both:

In the TXT records, look for the line starting with v=spf1. If it is missing, emails will go to spam or be rejected. To check the DKIM record:

If the selector differs from default, you need to get it from the mail service.

Scenario 3. Setting up a VPS with its own DNS resolver

When renting a VPS on Serverspace, full control over the network configuration is available, including DNS. You can run your own recursive resolver — for example, for traffic isolation, lower latency, or bypassing provider restrictions. To do this, install bind9 or unbound, then specify the server address in /etc/systemd/resolved.conf.

Check that the local resolver is responding correctly:

Scenario 4. Diagnosing slow resolution

If DNS works but is slow, measure response time:

A good result is up to 50 ms. If the response time is consistently above 200 ms, it is worth trying a DNS server that is geographically closer or setting up a local caching resolver.

Scenario 5. Checking domain delegation before migration

Before changing NS servers, it is important to make sure delegation works correctly. Tracing will show the full chain from the root servers:

If an error or an unexpected response appears at any step, it will be visible immediately. This check saves a lot of time when migrating a domain: it is better to find the problem before changing NS, not after.

Common mistakes and how to avoid them

Expecting DNS to update instantly

DNS records are cached for the duration specified in the TTL (Time to Live) field. If the TTL is set to 86400 seconds (24 hours), then after the record is changed, providers and resolvers around the world will continue to return the old value until that time expires. Before changing hosting or IP addresses, it is worth lowering the TTL in advance to 300–600 seconds — then the update will spread across the internet much faster.

Editing /etc/resolv.conf directly on modern systems

In Ubuntu 20.04+ and other systems with systemd-resolved, the /etc/resolv.conf file is a symbolic link. Direct edits will be overwritten on the next network restart or NetworkManager restart. The correct approach is to edit /etc/systemd/resolved.conf or use nmcli.

Forgetting about the cache during diagnostics

It often happens that people run DNS commands in Linux, get an old answer, and cannot understand why the changes are not visible. You should either check via a public resolver (dig @8.8.8.8 example.com) or first run the DNS cache flush command and then diagnose. Without this step, the result may be misleading.

Confusing A and CNAME records

An A record points directly to an IP address. A CNAME is an alias that points to another domain name. If you configure a CNAME for the root domain (example.com, without www), many services will start behaving incorrectly: the DNS standard forbids CNAME at the apex zone, where SOA and NS records must exist.

Using only nslookup for serious diagnostics

At first glance, nslookup is more convenient — it exists in both Windows and Linux, and the interface is familiar. But its output is less precise: it does not always show TTL, does not support tracing, and sometimes returns unexpected answers when working with non-standard configurations. For serious DNS diagnostics, it is better to switch to dig.

Ignoring DNSSEC when troubleshooting availability issues

If a domain is configured with DNSSEC, an incorrect signature can cause resolvers with validation enabled to refuse to answer. Some users see the site normally, while others get an error — depending on which resolver they use. Check DNSSEC:

Conclusion

Working with DNS from the command line is not a niche skill, but a basic part of any network or server administration. A few utilities in your toolkit let you quickly find the cause of a problem: dig for detailed diagnostics and tracing, nslookup and host for quick checks, resolvectl for managing the system resolver and the DNS cache flush command.

Getting started is easier than it seems: install dnsutils, run dig +short example.com, and look at the result. From there, add tracing, checking specific record types, and comparing answers from different servers to your routine. Over time, these DNS commands will become as familiar a part of the job as ping or curl.

If you work on your own VPS — for example, rented from Serverspace — you have full control over the DNS configuration from the very first minute. You can configure any resolver, spin up a caching or recursive server, and avoid depending on the provider’s settings.

Frequently Asked Questions