`nslookup` ve `dig` Farkları: Hangi Araç Ne Zaman Kullanılır?

DNS sorunlarını araştırırken iki araç adıyla sürekli karşılaşırsınız: nslookup ve dig. Her ikisi de DNS sorgularını doğrudan yapmanıza olanak tanır, ancak farklı platformlarda doğmuş, farklı çıktı biçimleri sunan ve farklı durumlarda öne çıkan araçlardır. Hangisine uzanacağınız çoğu zaman işletim sisteminize göre belirlenir; Windows'ta nslookup varsayılandır, ayrıntılı ANSWER bölümü ise dig'dedir, ama bu zorunluluk her zaman en iyi tercih anlamına gelmez.

Windows kullanıcıları nslookup'a herhangi bir ek kurulum gerekmeksizin ulaşır; araç işletim sistemiyle birlikte gelir. Linux ve macOS dünyasında ise dig standart araç olarak kabul görür, çıktısı daha ayrıntılıdır ve otomasyon betiklerine kolayca entegre edilebilir. İki araç arasındaki farkı anlamak, bir sorunun hangi noktada olduğunu tespit etme süresini önemli ölçüde kısaltır.

Bir domain kaydının neden beklendiği gibi çalışmadığını, bir MX kaydının doğru sunucuya işaret edip etmediğini ya da bir DNS değişikliğinin propagasyonunun nereye kadar ilerlediğini araştırırken bu iki araçtan birine ihtiyaç duyarsınız. Hangi sorun için hangisine başvurmak gerektiğini bilmek, araç öğrenmekten daha değerlidir.

nslookup Nedir ve Windows'ta Nasıl Kullanılır?

nslookup, "name server lookup" kısaltmasıdır ve Windows XP'den bu yana tüm Windows sürümlerinde varsayılan olarak bulunur. Komut istemcisinden (cmd) ya da PowerShell'den doğrudan çalıştırılabilir; ek kurulum gerekmez. İki farklı modda çalışır: tek satırlık sorgu modu ve etkileşimli mod.

Tek satırlık kullanımda domain adı ya da IP adresi doğrudan argüman olarak verilir:

nslookup ornek.com
nslookup ornek.com 8.8.8.8

İkinci örnekte 8.8.8.8, kullanılacak DNS sunucusunu belirtir. Varsayılan olarak sistem ayarlarındaki DNS sunucusu kullanılır; farklı bir sunucu üzerinden test yapmak istediğinizde bunu açıkça belirtmeniz gerekir; public resolver olarak 1.1.1.1 veya 8.8.8.8 kullanılabilir. Bu yöntem, bir kaydın yerel önbellekten mi yoksa gerçek DNS yanıtından mı geldiğini ayırt etmek için başvurulacak ilk adımdır; yerel sapmayı temizlemek için önbellek temizliği gerekir.

Etkileşimli modda nslookup yazıp Enter'a basarsınız. Açılan oturumda birden fazla sorguyu sırayla çalıştırabilirsiniz. Sorgu türünü değiştirmek için set type= komutu kullanılır:

nslookup
> set type=MX
> ornek.com
> set type=TXT
> ornek.com
> exit

Etkileşimli mod, özellikle aynı domain üzerinde birden fazla kayıt türünü art arda kontrol ederken zaman kazandırır. Sunucu değiştirmek için server 1.1.1.1 gibi bir komut yeterlidir. Windows'ta TTL bilgisi varsayılan görünümde yer almaz; görmek istiyorsanız set debug komutuyla ayrıntılı modu etkinleştirmeniz gerekir; bu modda çıktı daha uzun ve teknik bir hal alır.

dig: Linux ve macOS'ta Standart DNS Aracı

dig, "Domain Information Groper" kısaltmasıdır ve BIND (Berkeley Internet Name Domain) projesi kapsamında geliştirilmiştir. macOS'ta varsayılan olarak yüklüdür; Ubuntu ve Debian tabanlı Linux dağıtımlarında dnsutils paketiyle, Red Hat tabanlı sistemlerde ise bind-utils paketiyle kurulabilir. Windows'ta da çalıştırılabilir, ancak kullanımı o platformda yaygın değildir.

Temel sorgu sözdizimi şu şekildedir:

dig ornek.com
dig ornek.com MX
dig ornek.com TXT
dig ornek.com NS

dig'in en belirgin özelliği yapılandırılmış ve çok katmanlı çıktısıdır. Her sorgu sonucunda birkaç bölüm görürsünüz: QUESTION SECTION sorgulananı gösterir, ANSWER SECTION kayıt değerini, AUTHORITY SECTION yetkili ad sunucularını, ADDITIONAL SECTION ise ek adres bilgilerini içerir. Sorgu süresi ve yanıt veren sunucu adresiyle portu da her sorguda raporlanır; propagasyon sürecini farklı sunucular üzerinden izlerken bu bilgi hangi sunucudan yanıt geldiğini net biçimde ortaya koyar.

Yanıtı hızlıca almak istediğinizde +short seçeneği yalnızca değeri döndürür. Kısadır. Ardından bunu bir değişkene atayabilir, başka bir komutla zincirleyebilir ya da ekrandaki uzun çıktıyı okumak zorunda kalmadan ihtiyacınız olan bilgiyi alabilirsiniz:

dig ornek.com A +short
dig ornek.com MX +short

Çıktı Formatının Pratik Önemi: TTL ve Yetki Bilgisi

nslookup sonuçları daha sade bir biçimde sunar:

Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    ornek.com
Address: 93.184.216.34

dig çıktısı başlangıçta daha karmaşık görünse de her satır belirli bir anlam taşır:

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

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

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

ANSWER SECTION'da kayıt değerinden önce gelen 3600 sayısı TTL'dir (Time to Live), saniye cinsindendir. Bu değer, kaydın önbelleklerde ne kadar süre tutulacağını gösterir. Bir DNS değişikliğinden önce TTL'yi düşürmek propagasyon süresini kısaltır; ancak önceki TTL süresi dolmadan yapılan değişiklikler, eski değerin bazı önbelleklerde kalmaya devam etmesine neden olabilir. dig bu değeri her sorguda gösterdiği için propagasyonu adım adım izlemek çok daha nettir.

"Non-authoritative answer" uyarısı her iki araçta da görünebilir. Bu bir hata değil, yanıtın yetkili sunucudan değil özyinelemeli (recursive) bir çözümleyiciden geldiğini bildiren bir bilgidir. Yetkili sunucuya doğrudan ulaşmak istiyorsanız farklı bir yöntem gerekir.

Yetkili Ad Sunucusunu Hedeflemek ve +trace

Bir kaydın internette gerçekte nasıl göründüğünü anlamak için yerel önbellekten ya da özyinelemeli bir çözümleyiciden yanıt almak yeterli değildir; yetkili (authoritative) ad sunucusuna doğrudan gitmek gerekir. Her iki araç da bunu destekler, ama dig bu süreçte çok daha güçlü bir seçenek sunar.

dig'in +trace seçeneği sorguyu köküden (root nameserver) başlatarak tüm delegasyon zincirini adım adım takip eder:

dig ornek.com +trace

Bu çıktıda root sunucularından TLD'ye (.com, .net vb.), oradan domain için yetkili sunucuya kadar her delegasyon adımı görülür. Bir kaydın neden güncellenmiyor gibi durduğunu ya da hangi noktada farklı bir yanıt döndüğünü tespit etmek için +trace çıktısı en doğrudan kaynaktır. Özellikle bir nameserver değişikliği sonrasında delegasyonun tüm zincirde yerleşip yerleşmediğini kontrol ederken bu seçenek başka hiçbir araçla kolayca elde edilemeyen bir görünürlük sağlar.

nslookup'ta önce NS kayıtlarını alır, ardından dönen nameserver adresini hedef olarak belirlersiniz:

nslookup -type=NS ornek.com
nslookup ornek.com ns1.registrar.com

Bu yöntem işe yarar, ancak her adımı elle yürütmek gerekir. dig +trace bu süreci otomatik olarak yönetir ve tek komutla tüm zinciri gösterir.

Kayıt Türleri ve E-posta DNS Kontrolleri

Her iki araç da standart DNS kayıt türlerini sorgulayabilir: A, AAAA, CNAME, MX, TXT, NS, SOA, PTR. Sözdizimi farklıdır ancak sonuçlar büyük ölçüde örtüşür.

nslookup'ta kayıt türü -type= parametresiyle belirlenir:

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

dig'de kayıt türü doğrudan argüman olarak yazılır:

dig ornek.com MX
dig ornek.com TXT
dig ornek.com AAAA
dig ornek.com NS

E-posta yapılandırmalarında TXT kayıtları kritik öneme sahiptir. SPF kaydının doğru yazılıp yazılmadığını, DKIM selector'ının varlığını ya da DMARC politikasını kontrol etmek için TXT sorgusundan başlanır. Google Workspace kurulumunda MX ve birden fazla TXT kaydını aynı anda doğrulamak gerekir; bu süreci ayrıntılı biçimde aktaran adımlar Google Workspace DNS kayıtları rehberinde yer almaktadır.

Microsoft 365 ortamında ise SPF kaydının sözdizimi ve MX öncelik değerleri belirli kurallara bağlıdır. Microsoft 365 MX ve SPF yapılandırmasında bu değerlerin nasıl sorgulanacağı ve hangi sonuçların bekleneceği ele alınmıştır. Bir e-postanın spam klasörüne düşmesinin DNS kaynaklı olup olmadığını araştırırken sırasıyla MX, SPF, DKIM ve DMARC kayıtlarını kontrol etmeniz gerekir; DNS kaynaklı e-posta deliverability sorunları içeriği bu sorgulama sırasını daha geniş bir çerçevede aktarır.

dig'in Betiklerde Kullanım Avantajı

dig'in Unix ekosisteminde neredeyse her zaman tercih edilmesinin temel nedeni, çıktısının tutarlı ve ayrıştırılabilir (parseable) olmasıdır. +short seçeneğiyle yalnızca değeri döndürmek, bir bash betiğine entegre etmek ya da başka araçlarla zincirlemek oldukça kolaydır:

CURRENT_IP=$(dig ornek.com A +short)
echo "Mevcut A kaydı: $CURRENT_IP"

+noall +answer kombinasyonu yalnızca yanıt bölümünü verir, başındaki yorum satırlarını dışarıda bırakır. Sadece veri lazım; yorumlara gerek yok:

dig ornek.com A +noall +answer

nslookup çıktısını betiklerde kullanmak daha zordur. Format daha az düzenlidir, satır sayısı ve içeriği sorgulanan kayda göre değişir; bazı platform veya sürüm farklılıkları çıktıyı beklenmedik biçimde etkileyebilir. Bir DNS değişikliğini izleyen ya da belirli aralıklarla kayıt değerini kontrol eden bir betik yazıyorsanız dig ile başlamak daha az hata üretir.

Bulut sağlayıcılarında subdomain yönetimi yaparken DNS değişikliklerini programatik olarak doğrulamak da bu farkın önem kazandığı bir senaryodur. DigitalOcean DNS subdomain yönetiminde bu tür doğrulama adımlarına yer verilmiştir.

Hangi Araç Ne Zaman Tercih Edilmeli?

nslookup şu durumlarda yeterlidir: Windows ortamında çalışıyorsunuzdur ve ek kurulum istemiyorsunuzdur; hızlı tek seferlik bir kayıt kontrolü yapacaksınızdır; etkileşimli modda birkaç farklı kayıt türünü sırayla denemek istiyorsunuzdur; ya da komut satırına daha az aşina birine süreci anlatmanız gerekiyordur ve daha sade çıktı amacı karşılar.

dig şu durumlarda öne çıkar: Linux veya macOS üzerinde çalışıyorsunuzdur; TTL değerini, yetkili sunucu bilgisini ya da delegasyon zincirini doğrudan görmek istiyorsunuzdur; bir betiğe DNS sorgusu entegre edeceksinizdir; propagasyon sürecinde farklı DNS sunucularından alınan yanıtları karşılaştırmanız gerekiyordur; ya da +trace ile delegasyonun kökten itibaren doğru ilerlediğini doğrulamak istiyorsunuzdur.

Aynı soruyu farklı DNS sunucularına yönlendirmek her iki araçta da mümkündür. Google'ın 8.8.8.8'i, Cloudflare'in 1.1.1.1'i ve yerel bir sunucunun aynı sorguya farklı yanıt verip vermediğini karşılaştırmak, bölgesel önbellekleme sorunlarını tespit etmenin en pratik yoludur. Vercel ya da Netlify üzerindeki bir custom domain yapılandırmasında CNAME veya A kaydının doğru yayıldığını test ederken iki araç arasında geçiş yapmak bu nedenle normaldir; Vercel ve Netlify custom domain sorunları içeriği hangi kayıtları hangi sırayla kontrol etmeniz gerektiğini aktarır.

Her iki araç da gerçekte aynı DNS altyapısına ulaşır. Fark, ulaştığınız bilgiyi ne kadar rahat görebileceğinizde ve o bilgiyle sonraki adımı ne kadar hızlı atabileceğinizdedir. Windows'ta hızlı bir kontrol için nslookup açmak, ardından Linux sunucusunda dig +trace ile delegasyon zincirini izlemek aynı sorun üzerinde paralel çalışmanın olağan bir parçasıdır.

Araç seçimi, sorunun çözüldüğü yeri değil sorunun görüldüğü noktayı belirler. Hangisini kullandığınızdan bağımsız olarak, neyi sorduğunuzu bilmek; sorgu türünü, hedef sunucuyu ve beklenen yanıtı önceden belirlemiş olmak, komutun kendisinden çok daha belirleyicidir.