dig (Domain Information Groper) je osnovno orodje za odpravljanje težav z DNS: strežnik DNS vpraša za kateri koli zapis domene in podrobno izpiše odgovor. Z njim lahko preveriš, ali domena kaže na pravi naslov IP, ali si pravilno nastavil zapis MX ali TXT in ali je sprememba DNS že prišla do določenega strežnika.

Primere smo oktobra 2026 zagnali v sistemu AlmaLinux 10.2, z različico dig 9.18.33, na naši domeni awh.hu. Izpisi kažejo stanje v času preizkusa; pri svoji domeni seveda vidiš kaj drugega. Pregled hitrega odpravljanja omrežnih težav (ping, traceroute, curl) daje članek Odpravljanje težav z omrežjem.

Namestitev

dig je v paketu bind-utils (v Ubuntuju in Debianu dnsutils). V cloud image AlmaLinux ga privzeto ni:

sudo dnf install bind-utils
dig -v

Prva poizvedba in izpis

dig @1.1.1.1 www.awh.hu

Deli izpisa:

• HEADER: status je rezultat odgovora. NOERROR = uspelo, NXDOMAIN = takšno ime ne obstaja, SERVFAIL = strežnik ni mogel odgovoriti (pogosto napačen DNSSEC ali nedosegljiv imenski strežnik).
• flags: qr pove, da je to odgovor, rd in ra pa, da smo zahtevali rekurzivno poizvedbo in da jo strežnik podpira. Če je v odgovoru tudi aa, ga je dal lastni (avtoritativni) imenski strežnik domene, če je ad, je odgovor prestal preverjanje DNSSEC.
• QUESTION SECTION: kaj smo vprašali.
• ANSWER SECTION: zapisi odgovora. Stolpci: ime, TTL (koliko sekund je odgovor lahko shranjen v predpomnilniku), razred (IN), vrsta, vrednost. V zgornjem primeru je www.awh.hu zapis CNAME, ki kaže na drugo ime, dig pa je izpisal tudi njegove zapise A.
• AUTHORITY in ADDITIONAL SECTION: imenski strežniki domene in njihovi naslovi, če jih je strežnik tudi poslal.
• Query time, SERVER: koliko časa je trajalo in kateri strežnik DNS je odgovoril.

Vrste zapisov

Vrsto lahko navedeš za domeno; privzeta je A:

dig awh.hu A        # naslov IPv4
dig awh.hu AAAA     # naslov IPv6
dig awh.hu MX       # poštni strežniki
dig awh.hu NS       # imenski strežniki
dig awh.hu TXT      # besedilni zapisi (SPF, kode za preverjanje)
dig awh.hu SOA      # podatki cone
dig awh.hu CAA      # kateri izdajatelji potrdil smejo izdati SSL
dig awh.hu HTTPS    # namigi za povezavo za brskalnike (HTTP/3, naslovi IP)
dig _dmarc.awh.hu TXT

Zapisi za overjanje e-pošte so pod lastnimi imeni, ne pod imenom domene: DMARC je zapis TXT _dmarc.domain.hu, DKIM pa <selektor>._domainkey.domain.hu. Selektor DKIM pokaže vrednost s= v glavi DKIM-Signature poslanega sporočila. dig domain.hu TXT zato vrne le SPF, DMARC in DKIM pa ne.

Čemu služi kateri zapis, povzema članek Vrste zapisov DNS.

Le odgovor: +short in +noall +answer

Namesto celotnega izpisa +short vrne le vrednosti:

dig +short awh.hu MX

40 route2.mx.cloudflare.net.
87 route1.mx.cloudflare.net.
55 route3.mx.cloudflare.net.

Pri zapisu MX je prvo število prioriteta: strežnik z manjšim številom sporočilo prejme prvi. Če želiš videti tudi ime in TTL, ostalega pa ne:

dig awh.hu MX +noall +answer

awh.hu.                 286     IN      MX      87 route1.mx.cloudflare.net.
awh.hu.                 286     IN      MX      55 route3.mx.cloudflare.net.
awh.hu.                 286     IN      MX      40 route2.mx.cloudflare.net.

+ttlunits izpiše TTL v berljivi obliki (na primer 5h58m46s). V enem klicu je mogoče navesti več poizvedb: dig +noall +answer awh.hu A www.awh.hu CNAME.

Če bi nastavitev uporabljal vedno, jo zapiši v datoteko .digrc v svojem imeniku (na primer +noall +answer); dig jo prebere ob vsakem zagonu. To lahko tudi preseneti: v preizkusu je ob datoteki .digrc z vsebino +short tudi navadni dig awh.hu izpisal le naslove IP. Stikalo -r datoteko .digrc prezre; dobro ga je uporabljati v skriptah in pri odpravljanju težav (dig -r awh.hu).

Poizvedba določenega strežnika DNS

dig namesto privzetega strežnika DNS računalnika vpraša strežnik, naveden za @:

dig @1.1.1.1 awh.hu +short          # Cloudflare
dig @8.8.8.8 awh.hu +short          # Google
dig @jakub.ns.cloudflare.com awh.hu +norecurse

Zadnji vpraša lastni imenski strežnik domene. V glavi odgovora je takrat aa (authoritative answer): to je vir, vsi drugi strežniki dajejo njegovo predpomnjeno kopijo. Če po spremembi DNS avtoritativni strežnik že vrača novo vrednost, @8.8.8.8 pa še staro, sprememba v predpomnilnikih še ni potekla; to se po izteku TTL uredi samo. Podrobno: Kaj je širjenje DNS?

Različni strežniki lahko za isto ime vrnejo različne, a enako pravilne odgovore. V preizkusu sta na primer za zapis A domene awh.hu za Cloudflarom lastni strežnik DNS računalnika in 1.1.1.1 vrnila različne naslove IP, ker Cloudflare naslov izbere glede na tistega, ki sprašuje.

Celotna pot: +trace

dig +trace www.awh.hu

+trace ne dela iz predpomnilnika, temveč prehodi verigo: od korenskih strežnikov (.) prek imenskih strežnikov .hu do lastnega imenskega strežnika domene. V preizkusu je poizvedba potekala takole:

;; Received 813 bytes from 10.0.2.3#53(10.0.2.3) in 10 ms
;; Received 794 bytes from 199.7.83.42#53(l.root-servers.net) in 20 ms
;; Received 465 bytes from 5.28.0.97#53(a.hu) in 20 ms
;; Received 176 bytes from 172.64.34.116#53(treasure.ns.cloudflare.com) in 20 ms

Če se veriga pri katerem koraku pretrga ali pripelje na napačen imenski strežnik, je tam napaka. Po nakupu domene ali zamenjavi imenskih strežnikov tako preveriš, ali register .hu (ali druge končnice) že vrača nove imenske strežnike.

Obratno iskanje: -x

Ime, ki pripada naslovu IP (zapis PTR):

dig -x 1.1.1.1 +short

one.one.one.one.

Pri poštnih strežnikih je pomembno, da zapis PTR odhodnega naslova IP kaže na ime, ki se nazaj razreši v isti IP; brez tega veliko prejemnih strežnikov sporočilo označi kot neželeno. Zapis PTR ni v coni DNS domene, temveč pri lastniku naslova IP, torej pri ponudniku strežnika; pri lastnem strežniku je treba nastavitev zahtevati tam.

Neobstoječe ime

dig nincsilyen-domain-12345.hu

V glavi je status: NXDOMAIN, razdelek z odgovorom je prazen. Če pri obstoječi domeni dobiš NXDOMAIN, je ime zapisa napačno ali domena ni (ali ni več) registrirana.

Če ime obstaja, zapisa zahtevane vrste pa ni (na primer domena nima zapisa AAAA), je odgovor status: NOERROR, razdelek z odgovorom pa je prazen. To ni napaka, manjka le ta zapis.

Stanja napak: SERVFAIL, REFUSED, prekoračitev časa

SERVFAIL

Strežnik na vprašanje ni mogel odgovoriti. Pogost vzrok je napačen DNSSEC. S stikalom +cdflag (checking disabled) strežnik odgovori brez preverjanja; če tako odgovor dobiš, je napačen DNSSEC. V preizkusu pri namenoma pokvarjeni testni domeni:

dig @1.1.1.1 dnssec-failed.org A            # status: SERVFAIL, EDE: 9 (DNSKEY Missing)
dig @1.1.1.1 dnssec-failed.org A +cdflag    # status: NOERROR, flags: qr rd ra cd

Vrstica EDE (Extended DNS Error) navede tudi vzrok napake. +cdflag je le za odpravljanje težav, ne popravek.

REFUSED

Strežnik je zavrnil odgovor. To se zgodi, če avtoritativni imenski strežnik vprašaš o domeni, ki je ne streže on (v preizkusu se je tako končal dig @jakub.ns.cloudflare.com google.com), ali zaprt strežnik DNS od zunaj.

Prekoračitev časa

Če strežnik ne odgovori, dig izpiše:

;; communications error to 192.0.2.1#53: timed out
;; no servers could be reached

Privzeto poskusi večkrat; +time=2 +tries=1 odneha po dveh sekundah in enem poskusu.

Izhodna koda v skriptah

V skriptah je pomembno, da je izhodna koda dig neodvisna od rezultata odgovora DNS: v preizkusu je bila tudi po odgovoru NXDOMAIN 0, pri nedosegljivem strežniku pa 9. Ali ime obstaja, je treba prebrati iz polja status.

dig ne gleda datoteke /etc/hosts

dig vedno neposredno vpraša strežnik DNS, datoteke /etc/hosts računalnika ne bere. V preizkusu je ime proba.awh.hu, dodano v /etc/hosts, getent hosts proba.awh.hu našel, dig +short proba.awh.hu pa je vrnil prazen odgovor. Če program ime razreši drugače kot dig, preveri tudi datoteko /etc/hosts (in izpis getent hosts, ki sledi celotnemu razreševanju imen v sistemu).

Poizvedba ANY

dig awh.hu ANY je nekoč vrnil vse zapise. Danes veliko imenskih strežnikov na to namenoma ne odgovori vsebinsko (RFC 8482). V preizkusu je avtoritativni imenski strežnik Cloudflare domene awh.hu vrnil to:

awh.hu.                 3600    IN      HINFO   "RFC8482" ""

Lastni predpomnilniški strežnik DNS računalnika je na isto vprašanje vrnil več zapisov, a ne nujno vseh. Če te zanimajo vsi zapisi domene, jih poizveduj po vrstah ali jih poglej v vmesniku za upravljanje DNS.

DNSSEC

dig @1.1.1.1 +dnssec awh.hu
dig awh.hu DS +short

+dnssec skupaj z odgovorom zahteva tudi podpis (zapis RRSIG). Če vprašani strežnik preverja podpise in je vse v redu, se v glavi prikaže zastavica ad:

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

Zapis DS v nadrejeni coni (tu v .hu) označuje, da je domena podpisana. Če zapis DS obstaja, podpisi pa so napačni, strežniki s preverjanjem vrnejo SERVFAIL. O DNSSEC preberi v člankih Kaj je DNSSEC? in Ali lahko DNSSEC povzroča težave?.

Druga uporabna stikala

Stikalo	Kaj naredi
+tcp	vpraša prek TCP namesto UDP (če požarni zid filtrira UDP)
-p 5353	pošlje vprašanje na druga vrata
-4, -6	komunicira le prek IPv4 oziroma le prek IPv6
+norecurse	ne zahteva rekurzije; za poizvedbo avtoritativnega strežnika
+time=2 +tries=1	krajše čakanje, en poskus
-r	ne prebere datoteke ~/.digrc
-f fajl.txt	iz datoteke zažene po eno poizvedbo na vrstico

Prenos cone (dig @szerver domain.hu AXFR) poskusi le pri svoji coni, ki jo upravljaš sam: na tujih strežnikih to lahko štejejo za nepooblaščen poskus, nastavljeni strežniki pa ga tako ali tako zavrnejo.

Preverjanje spremembe DNS

Če domena uporablja imenske strežnike spletnega gostovanja, zapise spremeniš v urejevalniku DNS KeyHelp: Urejanje zapisov DNS na spletnem gostovanju. Po spremembi dig +short NS domain.hu pokaže imenske strežnike domene, dig @<imenski strežnik> domain.hu pa to, kar imenski strežnik že vrača; to mora takoj kazati novo vrednost. Pri drugih strežnikih DNS se lahko do izteka starega TTL prikaže še stara vrednost. Novo domeno lahko poiščeš na strani registracija domen, o zapisih pa podrobno piše tudi naš blogovski zapis.