DNS-lekérdezés a dig paranccsal: példák

A dig (Domain Information Groper) a DNS-hibakeresés alapeszköze: megkérdez egy DNS-szervert egy domain valamelyik rekordjáról, és részletesen kiírja a választ. Vele ellenőrizheti, hogy a domain a jó IP-címre mutat-e, beállította-e helyesen az MX vagy a TXT rekordot, és hogy egy DNS-változás eljutott-e már egy adott szerverre.

A példákat 2026 októberében egy AlmaLinux 10.2 rendszeren, a dig 9.18.33-as verziójával futtattuk, a saját awh.hu domainünkön. A kimenetek a teszt idejének állapotát mutatják; az Ön domainjénél értelemszerűen mást lát. A gyors hálózati hibakereséshez (ping, traceroute, curl) a Hálózati hibakeresés cikk ad áttekintést.

Telepítés

A dig a bind-utils csomagban van (Ubuntun és Debianon dnsutils). Az AlmaLinux cloud image-ében alapból nincs benne:

sudo dnf install bind-utils
dig -v

Az első lekérdezés és a kimenet

dig @1.1.1.1 www.awh.hu

A kimenet részei:

HEADER: a status a válasz eredménye. NOERROR = sikerült, NXDOMAIN = ilyen név nem létezik, SERVFAIL = a szerver nem tudott válaszolni (gyakran hibás DNSSEC vagy elérhetetlen névszerver).
flags: a qr jelzi, hogy ez válasz, az rd és ra, hogy rekurzív lekérdezést kértünk és a szerver ezt támogatja. Ha a válaszban aa is szerepel, azt a domain saját (autoritatív) névszervere adta, ha ad, a válasz DNSSEC-ellenőrzésen ment át.
QUESTION SECTION: mit kérdeztünk.
ANSWER SECTION: a válasz rekordjai. Az oszlopok: név, TTL (hány másodpercig tárolható a válasz gyorsítótárban), osztály (IN), típus, érték. A fenti példában a www.awh.hu egy CNAME, amely egy másik névre mutat, és a dig annak A rekordjait is kiírta.
AUTHORITY és ADDITIONAL SECTION: a domain névszerverei és azok címei, ha a szerver ezeket is elküldte.
Query time, SERVER: mennyi ideig tartott, és melyik DNS-szerver válaszolt.

Rekordtípusok

A típus a domain után adható meg; alapértelmezés az A:

dig awh.hu A        # IPv4-cím
dig awh.hu AAAA     # IPv6-cím
dig awh.hu MX       # levelezőszerverek
dig awh.hu NS       # névszerverek
dig awh.hu TXT      # szöveges rekordok (SPF, ellenőrző kódok)
dig awh.hu SOA      # a zóna adatai
dig awh.hu CAA      # mely tanúsítványkiadók adhatnak SSL-t
dig awh.hu HTTPS    # kapcsolódási tippek a böngészőknek (HTTP/3, IP-címek)
dig _dmarc.awh.hu TXT

A levelezés hitelesítési rekordjai saját neveken vannak, nem a domain nevén: a DMARC a _dmarc.domain.hu, a DKIM a <szelektor>._domainkey.domain.hu TXT rekordja. A DKIM szelektort egy elküldött levél DKIM-Signature fejlécének s= értéke mutatja. A dig domain.hu TXT ezért csak az SPF-et adja vissza, a DMARC-ot és a DKIM-et nem.

Hogy melyik rekord mire való, azt a DNS-rekordok típusai cikk foglalja össze.

Csak a válasz: +short és +noall +answer

A teljes kimenet helyett a +short csak az értékeket adja:

dig +short awh.hu MX

route2.mx.cloudflare.net.
route1.mx.cloudflare.net.
route3.mx.cloudflare.net.

Az MX rekordnál az első szám a prioritás: a kisebb számú szerver kapja először a levelet. Ha a nevet és a TTL-t is látni szeretné, de a többit nem:

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.

A +ttlunits a TTL-t olvasható formában írja ki (például 5h58m46s). Egy hívásban több lekérdezés is megadható: dig +noall +answer awh.hu A www.awh.hu CNAME.

Ha egy beállítást mindig használna, írja a saját könyvtárában lévő .digrc fájlba (például +noall +answer); a dig minden futáskor beolvassa. Ez meglepetést is okozhat: a teszten egy +short tartalmú .digrc mellett a sima dig awh.hu is csak az IP-címeket írta ki. A -r kapcsoló figyelmen kívül hagyja a .digrc-t; szkriptekben és hibakeresésnél érdemes használni (dig -r awh.hu).

Adott DNS-szerver kérdezése

A @ után megadott szervert kérdezi a dig a gép alapértelmezett DNS-szervere helyett:

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

Az utolsó a domain saját névszerverét kérdezi meg. A válasz fejlécében ilyenkor aa (authoritative answer) áll: ez a forrás, minden más szerver ennek a gyorsítótárazott másolatát adja. Ha egy DNS-módosítás után az autoritatív szerver már az új értéket adja, de a @8.8.8.8 még a régit, a változás még nem járt le a gyorsítótárakban; ez a TTL leteltével magától rendeződik. Részletesen: Mi az a DNS propagáció?

Ugyanarra a névre különböző szerverek más, de egyaránt helyes választ is adhatnak. A teszten például a Cloudflare mögötti awh.hu A rekordjára a gép saját DNS-szervere és az 1.1.1.1 más IP-címeket adott vissza, mert a Cloudflare kérdezőtől függően választ címet.

A teljes út: +trace

dig +trace www.awh.hu

A +trace nem gyorsítótárból dolgozik, hanem végigjárja a láncot: a gyökérszerverektől (.) a .hu névszerverein át a domain saját névszerveréig. A teszten így haladt a lekérdezés:

;; 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

Ha egy lépésnél a lánc megszakad vagy rossz névszerverre visz, ott a hiba. Domainvásárlás vagy névszerver-váltás után így ellenőrizheti, hogy a .hu (vagy más végződés) nyilvántartása már az új névszervereket adja-e.

Fordított keresés: -x

IP-címből a hozzá tartozó név (PTR rekord):

dig -x 1.1.1.1 +short

one.one.one.one.

Levelezőszervereknél fontos, hogy a kimenő IP-cím PTR rekordja egy olyan névre mutasson, amely visszafelé ugyanerre az IP-re oldódik fel; ennek hiányában sok fogadó szerver spamnek minősíti a levelet. A PTR rekord nem a domain DNS-zónájában van, hanem az IP-cím gazdájánál, vagyis a szerver szolgáltatójánál; saját szerver esetén ott kell kérni a beállítását.

Nem létező név

dig nincsilyen-domain-12345.hu

A fejlécben status: NXDOMAIN áll, a válasz szakasz üres. Ha egy létező domainnél kap NXDOMAIN-t, a rekord neve hibás, vagy a domain nincs (vagy már nincs) regisztrálva.

Ha a név létezik, de a kért típusú rekord nincs (például egy domainnek nincs AAAA rekordja), a válasz status: NOERROR, de a válasz szakasz üres. Ez nem hiba, csak az adott rekord hiányzik.

Hibaállapotok: SERVFAIL, REFUSED, időtúllépés

SERVFAIL

A szerver nem tudta megválaszolni a kérdést. Gyakori oka a hibás DNSSEC. A +cdflag kapcsolóval (checking disabled) a szerver az ellenőrzés nélkül válaszol; ha így van válasz, a DNSSEC a hibás. A teszten egy szándékosan elrontott tesztdomainnél:

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

Az EDE (Extended DNS Error) sor a hiba okát is megnevezi. A +cdflag csak hibakeresésre való, nem javítás.

REFUSED

A szerver megtagadta a választ. Akkor fordul elő, ha egy autoritatív névszervert olyan domainről kérdez, amelyet nem ő szolgál ki (a teszten a dig @jakub.ns.cloudflare.com google.com így végződött), vagy egy zárt DNS-szervert kívülről.

Időtúllépés

Ha a szerver nem válaszol, a dig ezt írja ki:

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

Alapból többször próbálkozik; a +time=2 +tries=1 két másodperc után, egy próba után feladja.

Kilépési kód szkriptekben

Szkriptekben fontos, hogy a dig kilépési kódja a DNS-válasz eredményétől független: a teszten az NXDOMAIN válasz után is 0 volt, az elérhetetlen szervernél 9. Hogy a név létezik-e, azt a status mezőből kell kiolvasni.

A dig nem nézi a /etc/hosts fájlt

A dig mindig közvetlenül egy DNS-szervert kérdez, a gép /etc/hosts fájlját nem olvassa. A teszten a /etc/hosts-ba felvett proba.awh.hu nevet a getent hosts proba.awh.hu megtalálta, a dig +short proba.awh.hu üres választ adott. Ha egy program másképp oldja fel a nevet, mint a dig, nézze meg a /etc/hosts fájlt is (és a getent hosts kimenetét, amely a rendszer teljes névfeloldását követi).

ANY lekérdezés

A dig awh.hu ANY régen az összes rekordot visszaadta. Ma sok névszerver erre szándékosan nem válaszol érdemben (RFC 8482). A teszten az awh.hu autoritatív Cloudflare-névszervere ezt adta:

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

A gép saját, gyorsítótárazó DNS-szervere ugyanerre a kérdésre több rekordot is visszaadott, de nem feltétlenül az összeset. Ha egy domain minden rekordjára kíváncsi, típusonként kérdezze le őket, vagy nézze meg a DNS-kezelő felületén.

DNSSEC

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

A +dnssec a válasszal együtt az aláírást (RRSIG rekord) is kéri. Ha a kérdezett szerver ellenőrzi az aláírásokat, és minden rendben van, a fejlécben megjelenik az ad jelző:

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

A DS rekord a szülőzónában (itt a .hu-ban) jelzi, hogy a domain alá van írva. Ha a DS rekord megvan, de az aláírások hibásak, a validáló szerverek SERVFAIL-t adnak. A DNSSEC-ről a Mi az a DNSSEC? és az A DNSSEC okozhat problémákat? cikkekben olvashat.

Egyéb hasznos kapcsolók

Kapcsoló	Mit csinál
`+tcp`	UDP helyett TCP-n kérdez (ha a tűzfal a UDP-t szűri)
`-p 5353`	más portra küldi a kérdést
`-4`, `-6`	csak IPv4-en, illetve csak IPv6-on kommunikál
`+norecurse`	nem kér rekurziót; autoritatív szerver kérdezésére
`+time=2 +tries=1`	rövidebb várakozás, egy próbálkozás
`-r`	nem olvassa be a `~/.digrc` fájlt
`-f fajl.txt`	soronként egy lekérdezést futtat egy fájlból

Zónaátvitelt (dig @szerver domain.hu AXFR) csak a saját, általa kezelt zónájánál próbáljon: idegen szervereken ezt jogosulatlan próbálkozásnak tekinthetik, és a beállított szerverek úgyis elutasítják.

DNS-módosítás ellenőrzése

Ha a domain a webtárhely névszervereit használja, a rekordokat a KeyHelp DNS-szerkesztőjében módosíthatja: DNS-rekordok szerkesztése a webtárhelyen. Módosítás után a dig +short NS domain.hu megmutatja a domain névszervereit, a dig @<névszerver> domain.hu pedig azt, amit a névszerver már kiad; ennek azonnal az új értéket kell mutatnia. A többi DNS-szervernél a régi TTL lejártáig még a régi érték is megjelenhet. Új domaint a domainregisztráció oldalon kereshet, a rekordokról pedig blogcikkünk is részletesen ír.