`dig` Komutu ile DNS Sorgulama: Gerçek Senaryolar ve Çıktı Yorumlama

DNS sorunlarını komut satırından çözmek için en güvenilir araçlardan biri dig'dir (Domain Information Groper). Bir alan adına erişilemiyor, e-posta iletilmiyor ya da yeni eklenen bir kayıt beklenen davranışı göstermiyorsa, dig size DNS altyapısının tam olarak ne döndürdüğünü gösterir. İşletim sistemi önbelleğini ve yerel resolver'ı atlayarak doğrudan nameserver'a gidebilir, ham sonucu kendi gözlerinizle okuyabilirsiniz; Windows tarafında aynı iş nslookup ile dig ayrımına düşer.

Komutu çalıştırmak ile çıktıyı yorumlamak ayrı becerilerdir; coğrafi tutarsızlık şüphesinde web tabanlı sorgu aynı kaydı birden fazla noktadan gösterir. Hangi sunucu yanıt verdi, TTL değeri ne kadar kaldı, AUTHORITY bölümünde ne gözüküyor; bunlar her biri farklı bir şeyi anlatır. Hangisine bakmanız gerektiğini bilmeden çıktı anlamsız bir metin yığınına dönüşür. Gerçek sorun giderme sahnesinde doğru soruyu sormak, doğru parametreyi seçmek kadar önemlidir.

Aşağıdaki bölümler dig'i yalnızca sözdizimi düzeyinde değil, gerçek senaryolar üzerinden ele alıyor. Çıktı yapısını, sunucu seçimini, iz sürme özelliğini ve pratik hataları sırasıyla inceliyoruz.

dig Çıktısını Anlamak: ANSWER, AUTHORITY, ADDITIONAL Bölümleri

Bir dig example.com A komutu çalıştırdığınızda ekrana gelen çıktı birkaç bölümden oluşur. ; <<>> DiG ile başlayan üst kısım kullanılan sürümü ve sorgu parametrelerini gösterir. ;; ->>HEADER<<- satırı ise sorgunun durumunu ve flags değerlerini içerir.

Status değerleri kısaca şunlardır: NOERROR sorgu başarıyla işlendi ancak kayıt olmayabilir; NXDOMAIN alan adı hiç mevcut değil; SERVFAIL nameserver sorguyu işleyemedi; bu kodlar DNS hata sınıflarının komut satırı karşılığıdır; REFUSED ise sunucu bu sorgu tipine yanıt vermeyi reddetti demektir. NXDOMAIN ile boş ANSWER bölümünü birbirine karıştırmamak önemlidir. Status NOERROR olup ANSWER boşsa kayıt tipi mevcut değildir ama domain vardır; iki farklı durum, iki farklı müdahale.

Asıl verinin bulunduğu üç bölüm şunlardır:

• ANSWER SECTION: Sorduğunuz kaydın doğrudan yanıtını içerir. Bu bölüm boşsa kayıt ya mevcut değildir ya da sorgulanan sunucu yetkili değildir ve sonucu önbellekten de bulamadı.
• AUTHORITY SECTION: Hangi nameserver'ın bu zone için yetkili olduğunu gösterir. NS kayıtları burada listelenir. Boş ANSWER ile birlikte dolu bir AUTHORITY bölümü, kayıt tipinin o domain'de tanımlanmadığını ancak zone'un var olduğunu gösterir.
• ADDITIONAL SECTION: Authority bölümünde adı geçen nameserver'ların A ya da AAAA kayıtlarını içerir; sorgulama sürecini hızlandırmak için önceden gönderilen diğer kayıtlar da burada yer alabilir.

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

;; AUTHORITY SECTION:
example.com.    3600   IN    NS   a.iana-servers.net.

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; MSG SIZE  rcvd: 56

Her satırdaki sütunlar sırasıyla şunlardır: alan adı, TTL (saniye cinsinden), sınıf (hemen her zaman IN, yani Internet), kayıt tipi, değer. flags alanındaki aa (Authoritative Answer) işareti, yanıtı veren sunucunun o zone için yetkili olduğunu gösterir. aa yoksa yanıt bir resolver'ın önbelleğinden geliyordur ve TTL yetkili değerden daha düşük olabilir. Bu iki durum farklı yorumları zorunlu kılar; önbelleklenmiş bir yanıt, zone'da ne olduğunu değil, resolver'ın bir süre önce ne gördüğünü anlatır.

Belirli Bir DNS Sunucusunu Hedeflemek: dig @8.8.8.8

Varsayılan olarak dig, sistemin /etc/resolv.conf dosyasında tanımlı resolver'ı kullanır. Sorun gidermede çoğu zaman farklı sunucuların ne döndürdüğünü karşılaştırmanız gerekir. @ parametresi tam da bunun için tasarlanmıştır; sorgunun hangi DNS sunucusuna gönderileceğini açıkça belirtir.

Yeni bir A kaydı eklediniz ancak sitenize ulaşılamıyor. Şu üç sorguyu çalıştırın:

dig @8.8.8.8 siteniz.com A
dig @1.1.1.1 siteniz.com A
dig @ns1.hosting-saglayiciniz.com siteniz.com A

İlk ikisi global public resolver'lara gider. Üçüncüsü doğrudan yetkili nameserver'a sorar. Yetkili sunucu yeni IP'yi döndürüyor ancak public resolver'lar hâlâ eskiyi gösteriyorsa propagation henüz tamamlanmamıştır; TTL süresi beklemeniz gerekir. Üçüncü sorgu da eski IP'yi döndürüyorsa kayıt ya yanlış girilmiştir ya da yanlış zone'a eklenmiştir. Sorun yerini buldunuz.

Çıktıyı sadeleştirmek istediğinizde +short parametresi gereksiz satırları temizler:

dig @8.8.8.8 siteniz.com A +short

Birden fazla IP döndüğünde, yük dengeleme ya da anycast yapılandırmalarında yaygın olduğu üzere, her satır ayrı bir adres olarak listelenir. Birden fazla sunucuyu hızla karşılaştırırken +short çok işe yarar. Ama flag değerlerini ve TTL'yi görmek istiyorsanız tam çıktıya dönmeniz gerekir; +short bu bilgileri gizler.

Çıktının alt kısmındaki ;; SERVER: satırı, yanıtın tam olarak hangi sunucu IP'sinden geldiğini gösterir. Beklenmedik bir IP görürseniz yapılandırmanızda yönlendirme kayması olabilir. Özel nameserver kurulumu yapıldıktan sonra delegasyonun düzgün çalışıp çalışmadığını bu satıra bakarak birkaç saniyede doğrulamak mümkündür.

DNS Zincirini Takip Etmek: dig +trace ile Adım Adım Sorgulama

Sorun derinleştiğinde resolver önbelleğini tamamen atlayıp sorgulama zincirinin her halkasını görmek istersiniz. Kesin yanıt yok. dig +trace bunun için tasarlanmıştır; root nameserver'lardan başlayarak her delegasyon adımını ayrı ayrı gösterir ve sorunun zincirin neresinde koptuğunu netleştirir.

dig +trace siteniz.com A

Çıktı root zone'dan başlar. Önce . için yetkili sunuculardan TLD delegasyonu alınır, ardından .com nameserver'larına sorgu gider, en son yetkili nameserver'a ulaşılır ve kayıt değeri döner. Her adımda hangi sunucuya sorgu gittiği ve ne döndürdüğü satır satır görünür.

Ne zaman kullanılmalı? Bir domain çoğu resolver'da çözülüyor ancak belirli ağlardan ya da coğrafi konumlardan ulaşılamıyordur. Yetkili nameserver'ın kendi zone'unu doğru sunup sunmadığını doğrulamak istersiniz. +trace burada net yanıt verir: sorun zincirin neresinde?

+trace root sunuculara doğrudan sorgu gönderdiğinden zaman zaman rate limiting'e takılabilir ve bazı adımlar yavaş ya da başarısız döner. Ağ koşullarına bağlı değişkenlik gösterebileceğini bilmek sonuçları yorumlarken önemlidir.

Çıktıda bir adımda SERVFAIL ya da yanıtsız satır görürseniz sorun o katmandadır. Nameserver IP'si yanlış, DNSSEC imzası bozuk ya da sunucu gerçekten cevap vermiyordur. Her ihtimal ayrı bir sonraki adıma işaret eder. Sorunu katmanlamak, hedefsiz denemelerden çok daha hızlı çözüme götürür. Vercel ve Netlify gibi platformlarda custom domain sorunları yaşandığında +trace ile delegasyon zincirinin nerede koptuğunu görmek, platform kontrol paneline güvenmekten çok daha kesin sonuç verir.

dig ANY ile Toplu Kayıt Sorgulama ve Sınırları

Teoride ANY tipi, nameserver'dan tüm kayıt tiplerini tek sorguda döndürmesini ister. A, AAAA, MX, TXT, NS; hepsi tek çıktıda görünür gibi görünür.

dig @ns1.yetkili-sunucu.com siteniz.com ANY

Pratikte tablo farklıdır. RFC 8482 ile birlikte pek çok resolver, ANY sorgularına ya HINFO kaydı ya da boş yanıt döndürmeye başladı. Amaç DNS amplification saldırılarını sınırlamaktır; küçük bir sorguya büyük yanıt döndürülmesin diye. Bu nedenle public resolver'lardan ANY ile kullanışlı bir çıktı almak neredeyse imkânsızdır.

Yetkili sunucuya doğrudan gittiğinizde durum farklı olabilir, ama bu da garanti değildir. Güvenilir yol, kayıt tiplerini ayrı ayrı sorgulamaktır:

dig siteniz.com MX
dig siteniz.com TXT
dig siteniz.com NS
dig siteniz.com AAAA

dig ANY'nin hâlâ işe yaradığı bir alan vardır: kendi kontrolünüzdeki nameserver'lar ya da geliştirme ortamları. Açık bir test resolver'ı üzerinde zone kontrolü yaparken tüm kayıtları tek seferde görmek pratiktir. Genel sorun giderme için ise tip bazlı sorgular her zaman daha güvenilir ve tutarlı yanıt verir. Çıktı gelmedi diye kayıt yok sonucuna varmak, ANY'nin en sık düşülen tuzağıdır.

Pratik Sorun Giderme Senaryoları

E-posta iletilmiyor. Gelen iletiler sunucuya ulaşmıyor. İlk adım MX kaydını sorgulamaktır:

dig siteniz.com MX

ANSWER boşsa MX kaydı yoktur. AUTHORITY'de SOA kaydı varsa zone var ama MX girilmemiş demektir. Yanlış bir öncelik değeri ya da nokta eksikliği de sorun çıkarır; mail.siteniz.com ile mail.siteniz.com. aynı şey değildir. Sondaki nokta FQDN'i temsil eder ve bazı paneller bunu otomatik eklemezken bazıları ekler. E-posta deliverability sorunlarının DNS kökenlerine bakmak, MX dışındaki kayıtların nasıl rol oynadığını anlamayı kolaylaştırır.

Subdomain NXDOMAIN döndürüyor.

dig api.siteniz.com A

NXDOMAIN, kayıt hiç yok demektir. NOERROR ile boş ANSWER ise kayıt tipi yanlış seçilmiş olabilir; belki CNAME var ama siz A sorguladınız. Bu durumda şunu deneyin:

dig api.siteniz.com CNAME

Farklı platformlar üzerinden subdomain yönetiyorsanız nameserver delegasyonlarını karıştırmak kolaydır. Subdomain yönetimindeki platform farkları zaman zaman beklenmedik davranışlara yol açar ve aynı kayıt farklı arayüzlerde farklı görünebilir.

TXT kaydı kesilmiş görünüyor. SPF ya da DKIM kaydı doğru girildiği hâlde validator araçları hata veriyor. Uzun TXT kayıtları UDP üzerinden iletilirken kesilebilir; 512 baytlık UDP sınırı aşıldığında yanıt budanır. TCP üzerinden sorgulayın:

dig siteniz.com TXT +tcp

Google Workspace DNS kayıtları ya da Microsoft 365 SPF yapılandırması üzerinde çalışırken TXT kayıtlarının tam uzunluğunu görmek bu nedenle önemlidir. Kısaltılmış çıktıya bakarak kaydın doğru olduğu sonucuna varmak, sessiz bir hatayı uzun süre gizleyebilir.

TTL Takibi ve Propagation Süreçlerinde dig

TTL, bir kaydın resolver önbelleklerinde ne kadar tutulacağını belirler. Kaydı değiştirdiğinizde eski değer TTL süresi dolana kadar önbelleklerde kalmaya devam eder. Propagation'ı izlemek için dig en pratik araçtır; terminal açık kaldığı sürece süreci adım adım takip etmenizi sağlar.

Değişiklik öncesinde mevcut TTL'yi not edin:

dig siteniz.com A

ANSWER SECTION'daki ikinci sütun mevcut TTL'yi gösterir. 86400 (24 saat) görüyorsanız değişikliği en az 24 saat öncesinde yapmak, önce TTL'yi 300'e çekmek ve o süre geçtikten sonra asıl değişikliğe geçmek propagation penceresini önemli ölçüde daraltır. Acil geçişlerde bu adımı atlamak sorun yaratır.

Değişiklik sonrasında şu döngüyü birkaç dakikada bir çalıştırabilirsiniz:

dig @8.8.8.8 siteniz.com A +short
dig @1.1.1.1 siteniz.com A +short
dig @ns1.saglayici.com siteniz.com A +short

Yetkili sunucu dahil üç sunucu da yeni değeri döndürdüğünde propagation büyük ölçüde tamamlanmıştır. Kritik bir geçiş yapıyorsanız farklı coğrafi konumlardan sorgu atmak, bölgesel resolver farklarını erken görmenizi sağlar. Domain portföyü yönetiminde her değişikliği dig ile yetkili sunucudan doğruladıktan sonra canlıya almak, geri dönüş maliyetini ciddi ölçüde düşürür.

Propagation beklediğinizden uzun sürüyorsa iki olasılık vardır. Birincisi, eski TTL değeri yüksektir ve resolver'lar henüz sona ermemiş önbelleği tutuyor olabilir. İkincisi, kayıt yetkili sunucuda hâlâ güncellenmemiştir. dig ile yetkili nameserver'a doğrudan sorgu atarak ikinci olasılığı saniyeler içinde eleyebilirsiniz; beklemeniz gerekip gerekmediğini ya da panel tarafında bir sorun olup olmadığını netleştirmiş olursunuz.

dig komutunu etkili kullanmak, DNS sorunlarını tahmin yürütmek yerine doğrudan veriye bakarak çözmeyi sağlar. @ ile sunucu seçimi, +trace ile zincir takibi ve kayıt tipine özgü sorgular bir arada kullanıldığında neredeyse her DNS sorununu katmanlara ayırabilirsiniz. Sorunun resolver önbelleğinde mi, yetkili sunucuda mı yoksa kaydın kendisinde mi olduğunu birkaç komutla netleştirebilirsiniz.

Bazı sorgular beklediğinizden farklı sonuç verdiğinde aracı değil, soruyu değiştirin. Hangi nameserver'a gidildiği, yanıtın yetkili mi önbelleklenmiş mi olduğu, TTL'nin kaç saniye kaldığı; bunların her biri bir sonraki adımı belirler. dig'i pasif bir sorgulama aracı olarak değil, aktif bir teşhis protokolü olarak kullanmak bu farklılığı yaratır.