23 September 2026 · One command a day

How do I query a specific DNS server with dig?

The dig command asks a DNS server a question and prints the raw answer. Adding @1.1.1.1 tells it to ask that one resolver instead of whatever your server normally uses. You reach for it when you have just changed a DNS record and want to know whether a particular resolver has picked up the change yet.

The command

dig example.com @1.1.1.1

dig is the query tool from the BIND suite. On Ubuntu 24.04 it lives in the bind9-dnsutils package, so if it is missing run sudo apt install bind9-dnsutils. The first argument, example.com, is the name you want to look up. With no record type given, dig asks for the A record, which is the IPv4 address. The part after @ is the resolver to ask, and 1.1.1.1 is a widely used public resolver. You can swap in any other resolver address, or the address of your domain's own authoritative nameserver, to compare what each one is handing out.

What you will see

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> example.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41287
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                   IN      A

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

;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Sep 23 10:14:02 UTC 2026
;; MSG SIZE  rcvd: 56

The line under ANSWER SECTION is the part that matters. It shows the name, the time to live in seconds, the record type and the address that resolver currently holds. status: NOERROR means the resolver found the record. If you see NXDOMAIN instead, that resolver does not know the name at all. The SERVER line confirms which resolver actually answered, which is worth a glance if you have typed the address by hand.

When to use it

• You have moved a site to a new server, changed the A record, and some visitors still land on the old box. Ask two or three resolvers in turn and see which ones are still serving the old address.
• You are about to point traffic at a fresh site and want proof the record exists before anyone hits it. Query the authoritative nameserver directly with dig example.com @ns1.example.com.
• You are issuing a Let's Encrypt certificate with a DNS challenge and need to confirm the TXT record is visible before the check runs. Use dig _acme-challenge.example.com TXT @1.1.1.1.

Watch out for

A resolver keeps an answer for as long as the TTL says it may. If the record had a TTL of a day before you changed it, that resolver can carry on serving the old address for up to a day, and dig will faithfully show you the stale value. The TTL number in the answer counts down, so it also tells you how long that resolver will hold what it has. Lower the TTL well before a planned change. Also remember that running dig without @ asks your server's local stub resolver, which has its own cache, so a clean answer there proves nothing about what the rest of the internet sees. For a simpler local check, see how to check what a domain resolves to.

Questions people ask

How do I get just the address without the rest of the output?

Add +short to the end, as in dig example.com @1.1.1.1 +short. You get one line per answer and nothing else.

How do I check a different record type such as MX or TXT?

Put the type after the name, for example dig example.com MX @1.1.1.1. Once the record looks right, check the site's status code with curl to confirm the new server is answering.

Opening a shell on the same machine that serves the site and asking any resolver in the world directly is the kind of check you can only do on a server you control. You can get the same VPS with 20% off at https://asksteves.co.uk/vps. Affiliate link.