dig, nslookup or host: command not found — install DNS tools on Linux

dig: command not found — or the same error for nslookup or host — means the BIND DNS client tools are not installed. Minimal server images and containers leave them out. The three commands ship together, so one package fixes all of them: bind9-dnsutils on Debian and Ubuntu, bind-utils on Rocky, AlmaLinux and RHEL, and bind-tools on Alpine. macOS already has all three.

# Debian, Ubuntu
sudo apt update && sudo apt install -y bind9-dnsutils

# Rocky, AlmaLinux, RHEL, Fedora
sudo dnf install -y bind-utils

# Alpine
apk add --no-cache bind-tools

Then check it: dig +short example.com should print one or more IP addresses.

Which package contains dig?

Checked against each distribution’s own package index for its current releases:

• Debian 12 and 13, Ubuntu 22.04 and 24.04: bind9-dnsutils provides dig, nslookup, delv, mdig and nsupdate. host comes from bind9-host, which is installed along with it.
• Rocky, AlmaLinux, RHEL and Fedora: bind-utils provides dig, host, nslookup and nsupdate.
• Alpine: bind-tools provides dig, host, nslookup and delv.
• Arch: bind, which absorbed the old bind-tools package. openSUSE: bind-utils.
• macOS: nothing to install — dig, host and nslookup are in /usr/bin.
• Windows: nslookup is built in, PowerShell has Resolve-DnsName, and there is no dig.

How do I install dig on Debian and Ubuntu?

Install bind9-dnsutils. It depends on bind9-host, so the one command gives you dig, nslookup and host:

sudo apt update
sudo apt install -y bind9-dnsutils

dig -v                      # prints the BIND version
command -v dig nslookup host

Older guides say apt install dnsutils. That still works. On Debian 12, Ubuntu 22.04 and Ubuntu 24.04, dnsutils is a transitional package that pulls in bind9-dnsutils. On Debian 13 it is only a name that bind9-dnsutils provides, and apt picks the real package for you. In scripts and Dockerfiles, use the real name.

If apt answers E: Unable to locate package bind9-dnsutils, the package index is empty or stale, which is normal on a fresh image. Run sudo apt update first; Unable to locate package covers the other causes.

How do I install dig on Rocky, AlmaLinux and RHEL?

sudo dnf install -y bind-utils

# CentOS 7 and other systems that still use yum
sudo yum install -y bind-utils

On Rocky and AlmaLinux 9, bind-utils comes from the AppStream repository, which is enabled by default. If you ever need to find the package for a command yourself, dnf provides '*/bin/dig' answers it.

How do I install dig on Alpine?

Alpine’s base commands come from BusyBox, which includes a small nslookup. In Alpine’s build it takes a record type and a server and not much else, and there is no dig or host until you install bind-tools. If you only need lookups in a small image, drill from the ldns project is a lighter tool with dig-style output.

apk add --no-cache bind-tools

# the BusyBox applet that is already there
nslookup -type=aaaa example.com 1.1.1.1

# lighter alternative with dig-style output
apk add --no-cache drill
drill example.com MX

Does macOS or Windows have dig?

macOS ships dig, host and nslookup, so “command not found” there usually means a broken PATH: echo $PATH must contain /usr/bin. One difference is worth knowing. These tools query DNS servers directly and do not follow macOS’s per-domain resolver rules, such as a VPN’s split DNS, so they can disagree with your browser. dscacheutil -q host -a name example.com asks the system resolver instead.

Windows has nslookup built in, and PowerShell has Resolve-DnsName, which covers most of what people use dig for:

nslookup example.com
nslookup -type=mx example.com 1.1.1.1

Resolve-DnsName example.com -Type MX
Resolve-DnsName example.com -Server 1.1.1.1

ISC stopped supporting Windows after the BIND 9.16 branch, so there is no current native dig.exe from them. The simplest real dig on Windows is inside WSL: in an Ubuntu or Debian distribution, the Debian command above applies.

How do I get dig inside a Docker container?

Container images are built without DNS tools, and you are usually root inside them, so drop sudo. Install them in the Dockerfile; anything installed by hand in a running container is gone when it is recreated.

# Debian or Ubuntu base
RUN apt-get update \
 && apt-get install -y --no-install-recommends bind9-dnsutils \
 && rm -rf /var/lib/apt/lists/*

# Alpine base
RUN apk add --no-cache bind-tools

To debug name resolution between containers without touching your images, start a throwaway container on the same network. On a user-defined network it uses Docker’s embedded DNS server, exactly like your services:

docker run --rm --network mynet alpine \
  sh -c 'apk add --no-cache bind-tools >/dev/null && dig +short db'

Can I query DNS without installing anything?

Yes, for simple lookups. On Debian, Ubuntu and RHEL-family systems these work out of the box:

getent hosts example.com        # the system resolver, /etc/hosts included
getent ahosts example.com       # every address, IPv4 and IPv6 (glibc)
resolvectl query example.com    # systems running systemd-resolved, e.g. Ubuntu

For the record types getent cannot show — MX, TXT, NS, CAA — or a reverse lookup, the DNS lookup tool asks our resolver in Amsterdam for you and lists each record with its TTL — the public answer, not what your own resolver or /etc/hosts says.

Which dig commands will you actually use?

dig +short example.com          # just the address(es)
dig +short AAAA example.com     # IPv6
dig example.com MX              # mail servers
dig example.com NS              # the authoritative name servers
dig example.com TXT             # SPF and verification records
dig @1.1.1.1 example.com        # ask a specific resolver, bypassing your own
dig -x 203.0.113.10             # reverse lookup (PTR)
dig +trace example.com          # follow the delegation from the root down

dig example.com NS shows which servers are authoritative for a domain; what nameservers are explains what that answer means and how to change it.

Without +short, read two parts of the output. The status in the header tells you what happened, and the ANSWER SECTION holds the records, each with its TTL in seconds:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4242
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.        300     IN      A       203.0.113.10

• NOERROR — the name exists. An empty ANSWER section means it has no record of the type you asked for.
• NXDOMAIN — the name does not exist at all. Check the spelling and whether the record was created in the right zone.
• SERVFAIL — the resolver could not get an answer, often because the domain’s name servers are unreachable or its DNSSEC is broken. Compare with dig @1.1.1.1.
• REFUSED — that server will not answer you, typically an authoritative server asked about a zone it does not host.

Checking a record you just created? Our guide to pointing a domain at a VPS shows what to expect while it propagates. If dig @1.1.1.1 answers but your programs still fail with Temporary failure in name resolution, the tools are fine and the server’s resolver configuration is not — see Temporary failure in name resolution.

Why is dig still “not found” after installing it?

• The shell cached the old lookup. Run hash -r in bash or rehash in zsh, or open a new terminal.
• /usr/bin is not on your PATH. command -v dig prints the path if the shell can see it. If it prints nothing while ls -l /usr/bin/dig shows the file, something in your .bashrc or .zshrc overwrote PATH — the PATH section of the exit code 127 guide shows how to repair it.
• You installed it in a container that was recreated since. Put the install in the Dockerfile.

A fresh VPS image is often missing more than the DNS tools — curl and wget are the usual next two. And if you want a clean machine outside your own network to test DNS changes from, a Standard KVM VPS is ready in about a minute.

Another tool missing, or a directory to add to PATH for good in bash, zsh and fish? See command not found: the three causes and the fix for every tool.

Frequently asked