digQuery DNS and read the full answer
dig asks a DNS server a question and prints exactly what came back: the status, flags, records and TTLs, plus which server answered and how long it took. It is the tool for debugging DNS, from a wrong IP after a cut-over to NXDOMAIN in a pod.
dig [@SERVER] NAME [TYPE] [+short] [+noall +answer] [+trace] [-x ADDRESS]You need the IP behind a name, and you want to understand every part of dig's output before you rely on it.
digDomain Information Groper, from the BIND tools (package bind9-dnsutils on Ubuntu).
dig builds a DNS query packet itself (it does not use the system's getaddrinfo, so /etc/hosts and nsswitch.conf are ignored) and sends it over UDP port 53 to the server given with @, or to the first nameserver in /etc/resolv.conf. On Ubuntu that is 127.0.0.53, the systemd-resolved stub, which forwards to the real resolver (in a cloud VPC, the provider's resolver). That recursive resolver answers from its cache or walks the tree: root servers refer it to the .com servers, which refer it to the domain's authoritative servers, which return the record. Every record carries a TTL telling resolvers how many seconds they may cache it. dig prints the header (status NOERROR, NXDOMAIN or SERVFAIL; flags such as aa for an authoritative answer, rd/ra for recursion), each section, the query time and the server used. Large answers switch to TCP. +trace skips the resolver and does the walk from the root itself.
dig asks the local stub, which asks a recursive resolver, which walks root, TLD and authoritative servers and caches the answer for its TTL.
dig builds the DNS packet itself and sends it to the nameserver in /etc/resolv.conf, 127.0.0.53 on Ubuntu. Unlike ping or curl, it never looks at /etc/hosts.
@SERVERAsk this server instead of the one in /etc/resolv.confTYPERecord type to ask for: A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, PTR, ANY+shortPrint only the answer values, one per line (script-friendly)+noall +answerPrint only the answer section, with names and TTLs-x ADDRReverse lookup: find the PTR name for an IP+traceResolve from the root servers down, showing each referral+tcpQuery over TCP instead of UDP+norecurseDon't ask for recursion: see only what that server knows+searchApply the search domains from /etc/resolv.conf+time=N +tries=NTimeout per try and number of tries-4 / -6Use only IPv4 or IPv6 transport to reach the serverTesting a new /etc/hosts entry with digdig talks to DNS servers directly and never reads /etc/hosts, so it shows the DNS answer, not what applications will use.
getent hosts api.devops-lab.io # uses nsswitch.conf like real programs"I changed the record but dig still shows the old IP, the change failed"Resolvers cache answers for the record's TTL. The change is probably live at the source.
dig @<authoritative-ns> name # then wait out the TTLTreating NXDOMAIN and SERVFAIL the sameNXDOMAIN means the name definitely doesn't exist (fix the name or the zone). SERVFAIL means the resolver couldn't get an answer (broken delegation, DNSSEC failure, upstream down).
Read the status field, then use +trace for SERVFAIL.Parsing the full dig output in scriptsThe header, comments and sections change with versions and options.
dig +short name # or +noall +answerTry these on a Linux machine of your own. Each task has a hint and a solution.
Look up the A record of localhost with dig. Why does it fail or differ in this offline sandbox, while ping localhost works?
Show which DNS server dig will use by default on this machine.
Write a dig command that prints only the IPv6 addresses of example.com, one per line.
Write the command to ask the server 10.0.0.2 for the MX records of devops-lab.io, showing only the answer section with TTLs.
digQuery DNS and read the full answer
dig asks a DNS server a question and prints exactly what came back: the status, flags, records and TTLs, plus which server answered and how long it took. It is the tool for debugging DNS, from a wrong IP after a cut-over to NXDOMAIN in a pod.
dig [@SERVER] NAME [TYPE] [+short] [+noall +answer] [+trace] [-x ADDRESS]You need the IP behind a name, and you want to understand every part of dig's output before you rely on it.
digDomain Information Groper, from the BIND tools (package bind9-dnsutils on Ubuntu).
dig builds a DNS query packet itself (it does not use the system's getaddrinfo, so /etc/hosts and nsswitch.conf are ignored) and sends it over UDP port 53 to the server given with @, or to the first nameserver in /etc/resolv.conf. On Ubuntu that is 127.0.0.53, the systemd-resolved stub, which forwards to the real resolver (in a cloud VPC, the provider's resolver). That recursive resolver answers from its cache or walks the tree: root servers refer it to the .com servers, which refer it to the domain's authoritative servers, which return the record. Every record carries a TTL telling resolvers how many seconds they may cache it. dig prints the header (status NOERROR, NXDOMAIN or SERVFAIL; flags such as aa for an authoritative answer, rd/ra for recursion), each section, the query time and the server used. Large answers switch to TCP. +trace skips the resolver and does the walk from the root itself.
dig asks the local stub, which asks a recursive resolver, which walks root, TLD and authoritative servers and caches the answer for its TTL.
dig builds the DNS packet itself and sends it to the nameserver in /etc/resolv.conf, 127.0.0.53 on Ubuntu. Unlike ping or curl, it never looks at /etc/hosts.
@SERVERAsk this server instead of the one in /etc/resolv.confTYPERecord type to ask for: A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, PTR, ANY+shortPrint only the answer values, one per line (script-friendly)+noall +answerPrint only the answer section, with names and TTLs-x ADDRReverse lookup: find the PTR name for an IP+traceResolve from the root servers down, showing each referral+tcpQuery over TCP instead of UDP+norecurseDon't ask for recursion: see only what that server knows+searchApply the search domains from /etc/resolv.conf+time=N +tries=NTimeout per try and number of tries-4 / -6Use only IPv4 or IPv6 transport to reach the serverTesting a new /etc/hosts entry with digdig talks to DNS servers directly and never reads /etc/hosts, so it shows the DNS answer, not what applications will use.
getent hosts api.devops-lab.io # uses nsswitch.conf like real programs"I changed the record but dig still shows the old IP, the change failed"Resolvers cache answers for the record's TTL. The change is probably live at the source.
dig @<authoritative-ns> name # then wait out the TTLTreating NXDOMAIN and SERVFAIL the sameNXDOMAIN means the name definitely doesn't exist (fix the name or the zone). SERVFAIL means the resolver couldn't get an answer (broken delegation, DNSSEC failure, upstream down).
Read the status field, then use +trace for SERVFAIL.Parsing the full dig output in scriptsThe header, comments and sections change with versions and options.
dig +short name # or +noall +answerTry these on a Linux machine of your own. Each task has a hint and a solution.
Look up the A record of localhost with dig. Why does it fail or differ in this offline sandbox, while ping localhost works?
Show which DNS server dig will use by default on this machine.
Write a dig command that prints only the IPv6 addresses of example.com, one per line.
Write the command to ask the server 10.0.0.2 for the MX records of devops-lab.io, showing only the answer section with TTLs.