dig ve nslookup ile DNS Sorgulama

Bir alan adının hangi sunucuya işaret ettiğini, e-postalarının nereye düştüğünü ya da yeni yaptığınız bir DNS değişikliğinin yayılıp yayılmadığını merak ettiğinizde, tarayıcıda siteyi açıp tahmin yürütmek yerine doğrudan kaynağa sormak çok daha hızlı ve kesindir. İşte dig ve nslookup tam olarak bunun için vardır: DNS sunucularına elle soru sorup ham cevabı görmenizi sağlayan iki komut satırı aracıdır. Bir sistem yöneticisinin günlük işinin belki de en sık tekrarlanan hareketi, bir terminal açıp dig ornek.com yazmaktır.

Bu rehberde dig ile A, MX, TXT, CNAME ve NS kayıtlarını nasıl sorgulayacağınızı, @sunucu söz dizimiyle belirli bir çözümleyiciye (resolver) nasıl doğrudan soru soracağınızı, +short ve +trace gibi hayat kurtaran seçenekleri ve tüm bunların nslookup karşılıklarını gerçek örneklerle göreceksiniz. Ardından işin en pratik kısmına geleceğiz: aynı kaydı farklı resolver'lardan sorgulayarak bir DNS değişikliğinin dünyaya ne kadar yayıldığını (propagasyonu) ölçmek ve TTL değerini bu yayılım süresi cinsinden doğru yorumlamak. Konunun teorik temeli için DNS nedir yazımızı, önbellek tarafı için de DNS önbelleği temizleme rehberimizi yanınızda tutabilirsiniz.

dig ve nslookup Arasındaki Fark#

İkisi de aynı işi yapar gibi görünse de kökenleri ve alışkanlıkları farklıdır. nslookup çok eski bir araçtır ve neredeyse her işletim sisteminde (Windows dâhil) hazır gelir; hızlı bir kontrol için elverişlidir ama çıktısı sınırlı ve zaman zaman kafa karıştırıcıdır. dig (Domain Information Groper) ise BIND ile birlikte gelen, çok daha ayrıntılı ve betiklemeye uygun bir araçtır. Linux ve macOS dünyasında sistem yöneticilerinin fiilî standardı dig'dir.

Aşağıdaki karşılaştırma, aynı işi iki araçta yaparken hangi komutu kullanacağınızı özetler:

Windows sunucularında dig varsayılan gelmez; BIND'in araç paketini kurmanız gerekir. Linux tarafında ise dig, dnsutils (Debian/Ubuntu) veya bind-utils (RHEL/AlmaLinux/Rocky) paketiyle gelir:

# Debian / Ubuntu
sudo apt update && sudo apt install -y dnsutils

# RHEL / AlmaLinux / Rocky
sudo dnf install -y bind-utils

# Kurulumu doğrula
dig -v

Pratikte tavsiyem şudur: elinizin altında Linux varsa dig kullanın; sadece bir Windows makinesinde hızlı bir bakış atıyorsanız nslookup yeterlidir. Bu yazının örneklerini ikisinde de göstereceğim, böylece hangi ortamda olursanız olun karşılığını bulabileceksiniz.

dig Çıktısını Okumak#

dig'e alışmanın ilk adımı, hiçbir ek seçenek vermeden çalıştırdığınızda dökülen "kalabalık" çıktıyı okumayı öğrenmektir. İlk bakışta fazla görünen bu bilgiler aslında sorunları teşhis ederken çok işinize yarar:

dig ornek.com A

; <<>> DiG 9.18.24 <<>> ornek.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41521
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
ornek.com.     3600    IN  A   203.0.113.10

;; Query time: 24 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Jul 10 11:42:03 UTC 2026
;; MSG SIZE  rcvd: 55

Bu çıktıda odaklanmanız gereken birkaç yer var. status: NOERROR sorgunun başarılı olduğunu söyler; burada NXDOMAIN görürseniz alan adı hiç yok demektir. ANSWER SECTION asıl cevaptır: ornek.com alan adının 203.0.113.10 IP'sine A kaydıyla bağlı olduğunu ve bu kaydın TTL'inin 3600 saniye (bir saat) olduğunu gösterir. Alt satırdaki SERVER: 1.1.1.1#53 cevabı hangi resolver'ın verdiğini, Query time ise cevabın kaç milisaniyede geldiğini belirtir.

Bu ayrıntı seli her seferinde gerekmez. Sadece sonuçla ilgileniyorsanız +short seçeneği çıktıyı tek satıra indirir; bu da betikler ve hızlı kontroller için idealdir:

dig ornek.com A +short
# 203.0.113.10

dig ornek.com MX +short
# 10 mail.ornek.com.
# 20 yedek.ornek.com.

Gürültüyü azaltmak için sıkça kullandığım bir başka seçenek +noall +answer'dır; bu kombinasyon çıktıdan yalnızca cevap bölümünü, TTL ve tip bilgisiyle birlikte bırakır:

dig ornek.com A +noall +answer
# ornek.com.   3600  IN  A  203.0.113.10

Kayıt Tiplerini Sorgulama (A, MX, TXT, CNAME, NS)#

dig'in gücü, tek bir söz dizimiyle her kayıt tipini sorgulayabilmenizden gelir: dig <alan-adı> <tip>. En sık kullanacaklarınızı örneklerle görelim.

A ve AAAA kayıtları alan adının IPv4 ve IPv6 adreslerini verir. Bir sitenin gerçekten hangi sunucuda barındığını anlamanın en doğrudan yoludur:

dig ornek.com A +short       # IPv4
dig ornek.com AAAA +short    # IPv6

MX kayıtları e-postanın hangi posta sunucusuna teslim edileceğini ve öncelik sırasını gösterir. Küçük öncelik değeri önce denenir; aşağıda 10 numaralı sunucu birincil, 20 numaralı ise yedektir:

dig ornek.com MX +short
# 10 mail.ornek.com.
# 20 yedek.ornek.com.

TXT kayıtları özellikle e-posta kimlik doğrulaması (SPF, DKIM, DMARC) ve alan adı sahiplik doğrulaması için hayati önemdedir. SPF kaydınızın gerçekten yayında olup olmadığını şöyle kontrol edersiniz:

dig ornek.com TXT +short
# "v=spf1 include:_spf.ornek.com ~all"

# DKIM gibi bir alt seçici (selector) için tam adı sorgulayın
dig sel1._domainkey.ornek.com TXT +short

# DMARC kaydı her zaman _dmarc alt alanında bulunur
dig _dmarc.ornek.com TXT +short
# "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

CNAME kayıtları bir adı başka bir alan adına takma ad yapar; bir CDN veya barındırma servisine yönlendirme yaparken sık kullanılır. dig bir alt alan adını sorguladığınızda önce CNAME'i, sonra onun çözümlendiği A kaydını gösterir:

dig www.ornek.com CNAME +short
# ornek.com.

dig blog.ornek.com +short
# cdn-sirketi.net.
# 198.51.100.42

NS kayıtları alan adının yetkili nameserver'larını verir. Bir alan adının hangi DNS sağlayıcısında yönetildiğini görmek ya da nameserver değişikliğinin oturup oturmadığını doğrulamak için kullanılır:

dig ornek.com NS +short
# ns1.clou.tr.
# ns2.clou.tr.

Bütün bunların nslookup karşılığı -type= (veya kısaca -q=) bayrağıyla verilir. Windows'ta bir posta sorununu incelerken en çok kullanacağınız komut muhtemelen budur:

nslookup -type=MX ornek.com
nslookup -type=TXT ornek.com
nslookup -type=NS ornek.com

Belirli Bir DNS Sunucusuna Soru Sormak (@sunucu)#

dig'in belki de en değerli yeteneği, hangi resolver'a soracağınızı sizin seçebilmenizdir. Varsayılan olarak sistemin /etc/resolv.conf dosyasındaki sunucuyu kullanır; ama sorgunun başına @ ile bir sunucu adresi eklerseniz soruyu doğrudan oraya yöneltirsiniz. Bu, "benim sağlayıcım ne görüyor, Google ne görüyor, Cloudflare ne görüyor" karşılaştırmasını yapmanın anahtarıdır.

# Cloudflare resolver'ına sor
dig @1.1.1.1 ornek.com A +short

# Google resolver'ına sor
dig @8.8.8.8 ornek.com A +short

# Doğrudan alan adının kendi yetkili sunucusuna sor
dig @ns1.clou.tr ornek.com A +short

Burada çok önemli bir ayrım var. Bir kaydı @8.8.8.8 gibi bir özyinelemeli (recursive) resolver'a sorduğunuzda, o resolver'ın önbelleğinde tuttuğu — yani belki eskimiş — değeri alırsınız. Oysa doğrudan alan adının yetkili (authoritative) sunucusuna (@ns1.clou.tr) sorduğunuzda, kaydın en güncel, kaynaktan gelen hâlini görürsünüz. Bir değişiklik yaptıysanız ve "yeni değer yansıdı mı" diye bakıyorsanız: yetkili sunucu değişikliği hemen gösterir; genel resolver'lar ise TTL dolana kadar eski değeri döndürmeye devam eder. Authoritative ve recursive sunucular arasındaki bu ayrım, propagasyonu anlamanın temelidir.

Yetkili sunucuların kim olduğunu bilmiyorsanız önce NS kaydını sorgulayıp ardından o sunuculardan birine doğrudan soru sorabilirsiniz:

# 1) Yetkili sunucuları bul
dig ornek.com NS +short

# 2) Bulduğun sunuculardan birine doğrudan A kaydını sor
dig @ns1.clou.tr ornek.com A +short

nslookup'ta aynı işi sorgunun sonuna sunucu adresini ekleyerek yaparsınız:

nslookup ornek.com 1.1.1.1
nslookup -type=MX ornek.com 8.8.8.8

+trace ile Çözüm Zincirini İzlemek#

Bazen "sorun nerede" sorusunun cevabı, çözüm zincirinin hangi adımında işlerin ters gittiğini görmekte gizlidir. dig +trace, resolver'ın önbelleğini atlayarak sorguyu kök sunuculardan başlatır ve TLD sunucularından yetkili sunuculara kadar her adımı tek tek gösterir. Bir alan adının yeni delegasyonunun (nameserver ataması) doğru yapılıp yapılmadığını görmenin en açık yoludur:

dig +trace ornek.com

Çıktı basamak basamak ilerler: önce kök sunucular .com TLD sunucularına yönlendirir, sonra .com sunucuları ornek.com'un yetkili sunucularını (NS kayıtlarını) verir, en sonda da o yetkili sunucu asıl A kaydını döndürür. Eğer TLD adımında beklediğiniz nameserver'ları göremiyorsanız, sorun sizin zone dosyanızda değil, alan adı kaydında (registrar tarafında) yaptığınız nameserver atamasındadır. Bu ayrımı görebilmek, "kayıtları doğru girdim ama site açılmıyor" tipi sorunları saatlerce boşa uğraşmadan çözmenizi sağlar.

Bir başka faydalı seçenek +nssearch'tür; alan adının tüm yetkili sunucularına aynı anda SOA kaydını sorar ve hepsinin aynı seri numarasını (serial) döndürüp döndürmediğini gösterir. Sunucular arasındaki senkronizasyon sorunlarını yakalamak için birebirdir:

dig +nssearch ornek.com

Propagasyonu Farklı Resolver'lardan Kontrol Etmek#

Gelelim en çok sorulan konuya: "DNS değişikliğimi yaptım, ne zaman herkese yansır?" DNS'te tek ve merkezi bir "canlı" değer yoktur; dünya üzerindeki binlerce resolver, her biri kendi önbelleğinde bir kopya tutar ve bu kopyalar TTL süresince güncellenmez. İşte bu yüzden bir değişikliğin "yayılması" (propagasyon) zaman alır ve herkeste aynı anda gerçekleşmez. Propagasyonu ölçmenin en dürüst yolu, aynı kaydı farklı resolver'lardan sorgulayıp cevapları yan yana koymaktır.

Diyelim ki ornek.com'un A kaydını 203.0.113.10'dan 203.0.113.99'a taşıdınız. Farklı resolver'ların ne gördüğünü tek seferde şöyle karşılaştırabilirsiniz:

for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
  echo -n "$r -> "
  dig @"$r" ornek.com A +short
done

Örnek bir ara çıktı şöyle görünebilir; bu tam olarak "yarısı geçti, yarısı geçmedi" durumudur:

1.1.1.1 -> 203.0.113.99      # yeni değer (güncellenmiş)
8.8.8.8 -> 203.0.113.99      # yeni değer
9.9.9.9 -> 203.0.113.10      # hâlâ eski değer (önbellek)
208.67.222.222 -> 203.0.113.10   # hâlâ eski değer

Buradaki asıl sorunuz "kaç saat sürer" değil, "TTL kaçtı" olmalı. Çünkü bir resolver eski değeri, ancak önbelleğe aldığı kaydın TTL'i dolana kadar tutar. TTL'i sorgulamak için dig'in cevabındaki ikinci sütuna bakın; +ttlid yerine en temiz yol tam çıktıyı kullanmaktır:

dig ornek.com A +noall +answer
# ornek.com.   287  IN  A  203.0.113.99

Buradaki 287, bu resolver'ın kaydı önbellekten silmesine 287 saniye kaldığını söyler. Aynı komutu birkaç saniye arayla tekrar çalıştırırsanız bu sayının geriye saydığını görürsünüz; sıfıra ulaştığında resolver kaydı yeniden yetkili sunucudan çeker. TTL yorumunun pratik özeti şudur:

Deneyimli yöneticilerin altın kuralı şudur: planlı bir DNS değişikliğinden en az bir TTL süresi önce TTL'i düşürün. Örneğin sunucu taşımadan bir gün önce TTL'i 3600'den 300'e indirirseniz, eski değeri önbelleğe almış resolver'lar bir gün içinde kısa TTL'li yeni kaydı öğrenir; asıl taşımayı yaptığınızda değişiklik dünyaya beş dakikada yayılır. Taşıma tamamlanıp her şey oturunca TTL'i tekrar yükseltip sorgu yükünü azaltabilirsiniz. Önbelleğin kendi tarafınızda nasıl temizlendiğini ise DNS önbelleği temizleme yazımızda ayrıntılı ele aldık.

Son bir uyarı: kendi bilgisayarınızdaki tarayıcı ya da işletim sistemi de kayıtları ayrıca önbelleğe alır. Bu yüzden dig propagasyonu doğru gösterirken tarayıcınız hâlâ eski siteyi açıyor olabilir; bu bir DNS sorunu değil, yerel önbellek meselesidir ve makinenizin DNS önbelleğini temizleyince düzelir.

Sıkça Sorulan Sorular#

dig ile nslookup arasında hangisini kullanmalıyım?#

Linux ya da macOS kullanıyorsanız neredeyse her durumda dig'i tercih edin; çıktısı daha ayrıntılı, TTL ve kayıt tipini net gösteriyor ve betiklemeye çok daha uygun. nslookup ise Windows'ta hazır geldiği için hızlı bir kontrolde işinizi görür. İkisi de aynı DNS sistemine soru sorar; fark ergonomi ve çıktının okunabilirliğindedir.

dig komutu "command not found" hatası veriyor, ne yapmalıyım?#

Bu, dig'in henüz kurulu olmadığı anlamına gelir. Debian veya Ubuntu'da sudo apt install dnsutils, AlmaLinux, Rocky veya RHEL'de sudo dnf install bind-utils komutuyla kurabilirsiniz. Windows'ta ise dig varsayılan gelmediğinden ya BIND araç paketini kurmanız ya da hızlı bir bakış için nslookup kullanmanız gerekir.

Yaptığım DNS değişikliği neden bende görünüyor ama arkadaşımda görünmüyor?#

Çünkü ikinizin kullandığı resolver'lar farklı ve her biri kaydı kendi önbelleğinde TTL süresince ayrı tutuyor. Sizin resolver'ınız kaydı zaten güncellemişken, arkadaşınızınki eski TTL'i dolana kadar eski değeri döndürebilir. dig @1.1.1.1 ve dig @8.8.8.8 ile farklı resolver'ları tek tek sorgularsanız bu farkı kendi gözünüzle görebilir, propagasyonun ne kadar ilerlediğini ölçebilirsiniz.

Bir kaydın güncel TTL süresini nasıl görürüm?#

dig ornek.com A +noall +answer komutunu çalıştırın; çıktıdaki alan adından sonraki ikinci sütun, o resolver'ın kaydı önbellekten silmesine kaç saniye kaldığını gösterir. Komutu birkaç saniye arayla tekrarlarsanız bu sayının geriye saydığını görürsünüz. En güncel (kaynak) TTL değerini görmek isterseniz doğrudan yetkili sunucuya sorun: dig @ns1.clou.tr ornek.com A +noall +answer.

E-posta gelmiyor, hangi dig komutlarıyla teşhis yaparım?#

Önce MX kaydının doğru sunucuyu ve öncelikleri gösterdiğini kontrol edin: dig ornek.com MX +short. Ardından SPF kaydını dig ornek.com TXT +short, DMARC'ı dig _dmarc.ornek.com TXT +short ile doğrulayın. Bu üç kayıttan biri eksik veya yanlışsa postalarınız spam'e düşebilir ya da hiç teslim edilmeyebilir. Sunucunuzun ters DNS (PTR) kaydını da dig -x sunucu-ip-adresi ile kontrol etmek teslim edilebilirlik açısından önemlidir.

dig +trace tam olarak ne işe yarar?#

dig +trace, resolver önbelleğini tamamen atlayıp sorguyu kök sunuculardan başlatır ve çözüm zincirinin her adımını (kök, TLD, yetkili sunucu) sırayla gösterir. Özellikle yeni bir alan adının nameserver atamasının doğru yapılıp yapılmadığını görmek için değerlidir. TLD adımında beklediğiniz nameserver'ları göremiyorsanız sorun registrar tarafındaki delegasyondadır; yetkili sunucu adımında kayıt yanlışsa sorun sizin zone dosyanızdadır.

Kapanış#

dig ve nslookup, bir alan adının gerçekte ne yaptığını tahmin etmek yerine doğrudan görmenizi sağlayan, öğrenmesi yarım saat ama ömür boyu iş gören iki araçtır. A, MX, TXT, CNAME ve NS kayıtlarını sorgulamayı, @sunucu ile belirli resolver'lara soru sormayı, +short ve +trace ile çıktıyı yönetmeyi ve en önemlisi farklı resolver'ları karşılaştırıp TTL'i doğru yorumlayarak propagasyonu ölçmeyi öğrendiğinizde, DNS artık sizin için bir kara kutu olmaktan çıkar. Bir sonraki taşıma ya da kayıt değişikliğinde "acaba yansıdı mı" diye beklemek yerine kesin cevabı birkaç saniyede alırsınız.

Sağlam bir DNS altyapısı, hızlı yansıyan kayıtlar ve yönetimi kolay bir panel istiyorsanız Clou.TR yanınızda. Hosting paketlerimiz yönetimi kolay bir DNS paneliyle gelir; alan adınızı domain hizmetimizden yönetebilir, daha büyük projeler için sanal ve fiziksel sunucularımıza geçebilir, tüm sistemin bakımını bize bırakmak isterseniz sunucu yönetimi hizmetimize göz atabilirsiniz. E-posta teslim edilebilirliğinden emin olmak isteyenler için e-posta çözümlerimiz ve site geçişlerinde kesintisiz taşıma için site taşıma hizmetimiz de hazır.