DNS Çözümleme Sorunları: dig Aracıyla Hata Tespiti ve Giderme

Bykomut

Bir sabah işe geliyorsun, monitoring ekranları kırmızıya dönmüş, uygulamalar birbirini bulamıyor ve herkes sana bakıyor. “DNS mi?” diye soruyorsun kendi kendine. Çoğu zaman cevap evet. DNS sorunları, ağ problemlerinin en sinsi ve en sık karşılaşılan türlerinden biri. Neyse ki elimizde dig gibi güçlü bir araç var ve bu aracı doğru kullanmayı öğrendiğinde, çoğu DNS sorununun kaynağını dakikalar içinde tespit edebiliyorsun.

dig Nedir ve Neden Kullanmalısın?

dig (Domain Information Groper), DNS sorgularını test etmek ve hata ayıklamak için kullanılan komut satırı aracıdır. nslookup‘a kıyasla çok daha ayrıntılı çıktı verir, script yazımına uygundur ve DNS sorunlarını teşhis ederken ihtiyaç duyduğun hemen her bilgiyi sana sunar.

Çoğu Linux dağıtımında bind-utils veya dnsutils paketi içinde gelir:

# RHEL/CentOS/Rocky Linux için
sudo dnf install bind-utils

# Debian/Ubuntu için
sudo apt install dnsutils

Windows tarafında da dig kullanmak mümkün. BIND’ın Windows sürümünü kurabilir ya da WSL üzerinden doğrudan kullanabilirsin. Ama dürüst olmak gerekirse, DNS hata ayıklaması için Linux tarafında kalmak hayatını kolaylaştırır.

Temel dig Kullanımı

Başlamadan önce dig‘in çıktısını anlamak gerekiyor. Çünkü yanlış yere bakıyorsan, doğru aracı bile yanlış kullanmış olursun.

dig google.com

Bu komutun çıktısı birkaç bölümden oluşur:

  • HEADER: Sorgu ID’si, bayraklar, kaç kayıt döndüğü
  • QUESTION SECTION: Ne sorduğun
  • ANSWER SECTION: Alınan cevap
  • AUTHORITY SECTION: Yetkili DNS sunucusu
  • ADDITIONAL SECTION: Ek bilgiler
  • Statistics: Sorgu süresi, hangi sunucuya gittiği, zaman damgası

Gerçek hayatta en çok baktığın yer ANSWER SECTION ve en alttaki istatistik satırıdır. Özellikle Query time değeri, DNS sunucusunun ne kadar hızlı yanıt verdiğini gösterir.

Farklı Kayıt Türlerini Sorgulamak

DNS sadece A kaydından ibaret değil. Farklı sorunlar farklı kayıt türlerinde saklıyor olabilir.

# A kaydı (IPv4)
dig google.com A

# AAAA kaydı (IPv6)
dig google.com AAAA

# MX kaydı (mail sunucusu)
dig google.com MX

# NS kaydı (name server)
dig google.com NS

# TXT kaydı (SPF, DKIM, doğrulama kayıtları)
dig google.com TXT

# CNAME kaydı
dig www.google.com CNAME

# SOA kaydı (zone bilgisi)
dig google.com SOA

# Tüm kayıtları getir
dig google.com ANY

Gerçek Senaryo: Bir gün mail teslim sorunları yaşandığını bildirdiler. dig google.com MX yerine müşterinin kendi domain’ini sorguladım ve MX kaydının tamamen silinmiş olduğunu gördüm. DNS paneline girip bakan kişi yanlışlıkla MX kaydını silmişti. İki dakikada tespit, beş dakikada çözüm.

Belirli Bir DNS Sunucusuna Sorgu Göndermek

Varsayılan olarak dig, sistemin /etc/resolv.conf dosyasındaki DNS sunucusunu kullanır. Ama bazen farklı bir sunucuya doğrudan sorgu göndermen gerekir.

# Google DNS'e sor
dig @8.8.8.8 example.com

# Cloudflare DNS'e sor
dig @1.1.1.1 example.com

# Kendi internal DNS sunucuna sor
dig @192.168.1.10 internalapp.company.local

# Domain'in yetkili name server'ına sor
dig @ns1.example.com example.com

Bu özellik altın değerinde. “Kayıtları güncelledim ama hala eski IP görüyorum” şikayetlerini aldığında şunu yaparsın:

# Önce yetkili sunucuya sor
dig @ns1.example.com example.com A

# Sonra public DNS'e sor
dig @8.8.8.8 example.com A

# Son olarak local resolver'a sor
dig example.com A

Eğer yetkili sunucu doğru cevabı veriyorsa ama public DNS hala eskiyi söylüyorsa, propagasyon bekleniyordur. Eğer yetkili sunucu da yanlış cevap veriyorsa, DNS panelinde güncelleme yapılmamış demektir.

TTL ve Propagasyon Analizi

DNS sorunlarının büyük kısmı TTL’in yanlış anlaşılmasından kaynaklanır.

# TTL değerini görmek için
dig example.com A +ttl

# Kısa ve öz çıktı için
dig example.com A +short

# TTL'i ve tüm detayları görmek için
dig example.com A +noall +answer
# Örnek çıktı:
# example.com.    3600    IN    A    93.184.216.34
# Burada 3600 saniye = 1 saat TTL

Bir kaydın TTL değeri 86400 (24 saat) ise ve yeni değeri 30 dakika önce girdiysen, dünyanın dört bir yanındaki resolver’ların hala eski değeri cache’te tuttuğunu anlamalısın. Acil bir geçiş öncesinde TTL’i düşürmeyi ihmal etmek, sonradan saatler süren problemlere yol açar.

Trace Modunda Sorgu Takibi

DNS sorgusunun root sunuculardan başlayarak nasıl ilerlediğini görmek istediğinde +trace parametresi kullanılır. Bu, sorunun tam olarak nerede olduğunu bulmak için en değerli araçlardan biridir.

dig example.com +trace

Bu komut önce root DNS sunucularına gider, oradan TLD sunucularına yönlenir, sonunda yetkili sunucuya ulaşır. Eğer bir noktada takılıyorsa, tam olarak nerede takıldığını görürsün.

# Daha ayrıntılı trace için
dig example.com +trace +additional

Gerçek Senaryo: Bir müşterinin subdomain’i sadece bazı bölgelerden çözümlenemiyordu. +trace ile baktığımda, yetkili name server’lardan birinin NS kaydında yazıyor ama aslında o IP’de dinlemediği ortaya çıktı. Yani glue record güncel değildi. Bu tür sorunları +trace olmadan bulmak gerçekten zor olurdu.

Ters DNS Sorgulama (PTR Kaydı)

Bir IP adresinin hangi hostname’e karşılık geldiğini bulmak için ters sorgu kullanılır. Bu özellikle mail sunucusu kurulumlarında ve güvenlik analizlerinde kritiktir.

# Ters sorgu
dig -x 8.8.8.8

# Alternatif yöntem
dig 8.8.8.8.in-addr.arpa PTR

# Kısa çıktı ile
dig -x 93.184.216.34 +short

Mail sunucularında PTR kaydı olmazsa ne olur? Gönderdiğin mailler spam klasörüne düşer ya da direkt reddedilir. “Maillerimiz gitmiyor” şikayetinin ardında çoğu zaman eksik PTR kaydı yatar.

DNSSEC Doğrulaması

Modern altyapılarda DNSSEC giderek yaygınlaşıyor. DNSSEC sorunları çok garip hatalara yol açabilir: bazı resolver’lar cevap verir, bazıları vermez.

# DNSSEC ile doğrulama yapılmış sorgu
dig example.com +dnssec

# AD (Authenticated Data) bayrağını kontrol et
dig example.com +dnssec | grep "ad"

# DNSKEY kaydını sorgula
dig example.com DNSKEY

# DS kaydını sorgula
dig example.com DS

Eğer +dnssec ile sorgulama yaptığında SERVFAIL alıyorsun ama +dnssec olmadan normal cevap geliyorsa, DNSSEC imzaları bozulmuş ya da süresi dolmuş demektir. Bu durum genellikle otomatik key rotation’ın başarısız olduğunda yaşanır.

Yaygın Hata Senaryoları ve Teşhis Yöntemleri

NXDOMAIN Hatası

Domain bulunamadı anlamına gelir. Ama dikkatli ol, bazen typo kaynaklı olabilir.

dig nonexistentdomain12345.com A
# ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

NXDOMAIN görünce şunları kontrol et:

  • Domain gerçekten var mı? Süresi dolmuş olabilir
  • Doğru domain adını mı yazıyorsun?
  • DNS kaydı silinmiş olabilir mi?
# Domain'in expire olup olmadığını kontrol etmek için
dig example.com SOA
# MNAME ve RNAME alanlarına bak

SERVFAIL Hatası

DNS sunucusu isteği işleyemedi demektir. Bu daha ciddi bir sorundur.

dig brokendomain.example SERVFAIL
# Status: SERVFAIL olarak dönecek

# Önce yetkili sunucuya sor, SERVFAIL orada da var mı?
dig @ns1.example.com subdomain.example.com

SERVFAIL’in yaygın nedenleri:

  • Zone dosyasında syntax hatası
  • Yetkili sunucu ile zone verisi arasında tutarsızlık
  • DNSSEC doğrulama hatası
  • Yetkili sunuculara ulaşılamaması

Timeout ve REFUSED

# Timeout kontrolü
dig @192.168.1.10 example.com +time=5 +tries=2

# REFUSED durumu genellikle erişim kısıtlaması demektir
# Firewall ACL veya DNS ACL'i kontrol et

Batch Sorgu ve Script Kullanımı

Birden fazla domain’i kontrol etmen gerektiğinde tek tek sorgu yapmak vakit kaybı olur.

# Dosyadan domain listesi okuma
cat domains.txt | while read domain; do
    result=$(dig +short $domain A)
    echo "$domain -> $result"
done
# Daha gelişmiş versiyon: çözümlenemeyen domain'leri bul
#!/bin/bash
while IFS= read -r domain; do
    result=$(dig +short "$domain" A 2>/dev/null)
    if [ -z "$result" ]; then
        echo "HATA: $domain cozumlenemedi"
    else
        echo "OK: $domain -> $result"
    fi
done < domains.txt

Bu script özellikle toplu DNS migration’larında çok işe yarar. Yüzlerce subdomain’i migrate ettiğinde, hepsinin doğru çözümlenip çözümlenmediğini tek seferde kontrol edebilirsin.

DNS Yanıt Sürelerini İzlemek

Yavaş DNS yanıtları, uygulamanın genel performansını ciddi şekilde etkiler.

# Sorgu süresini görmek için
dig example.com | grep "Query time"

# Birden fazla sunucuyu karşılaştır
for server in 8.8.8.8 1.1.1.1 9.9.9.9; do
    time=$(dig @$server example.com +stats | grep "Query time" | awk '{print $4}')
    echo "DNS $server: ${time}ms"
done
# Sürekli izleme için basit döngü
while true; do
    dig @your-dns-server example.com +short +stats 2>&1 | grep -E "Query time|ANSWER"
    sleep 5
done

Gerçek Senaryo: Bir e-ticaret sitesinin checkout süreci yavaşlamıştı. APM araçları DNS lookup sürelerinin 2-3 saniyeye çıktığını gösteriyordu. Yukarıdaki döngüyü çalıştırdığımda, iç DNS sunucusunun belirli aralıklarla 3000ms üzeri yanıt verdiğini gördüm. Sonuçta sorun, DNS sunucusunun disk I/O darboğazı yaşamasıydı. Sorunu dig ile tespit ettim, çözümü ise disk boyutlandırması ve query cache ayarlamasıyla geldi.

Internal DNS Sorunları

Kurumsal ortamlarda iç DNS sunucuları ayrı bir sorun kaynağıdır. Split-horizon DNS yapılandırması, yani aynı domain için farklı internal/external cevaplar döndürme, özellikle kafa karıştırıcı olabilir.

# Internal sunucuya sor
dig @10.0.0.1 app.company.local A

# External sunucuya sor (farklı cevap vermeli)
dig @8.8.8.8 app.company.local A

# Forwarding yapılandırmasını test et
dig @internal-dns.company.local google.com A
# Eğer cevap gelmiyorsa forwarder problemi var demektir
# Recursive sorgu yapıp yapamadığını test et
dig @your-dns example.com +recurse

# Non-recursive sorgu (sadece cache'e bak)
dig @your-dns example.com +norecurse

Split-horizon’da sık karşılaşılan durum şudur: VPN’e bağlanan kullanıcı, internal servise erişemiyor çünkü DNS sorgular external sunucuya gidiyor ve NXDomain alıyor. Bunun tespiti için:

# VPN bağlantısında hangi DNS kullanılıyor?
cat /etc/resolv.conf

# O sunucuya internal domain'i sor
dig @$(grep nameserver /etc/resolv.conf | head -1 | awk '{print $2}') internal.company.local

dig Çıktısını Sadeleştirmek

Bazen tam çıktıya ihtiyaç duymaz, sadece hızlıca cevap görmek istersin.

# Sadece IP adresi
dig example.com +short

# Header'ı gizle
dig example.com +noall +answer

# Tüm bölümleri ayrı ayrı kontrol et
dig example.com +noall +question +answer

# Stats bölümünü göster
dig example.com +noall +stats
# Birden fazla sorguyu temiz görüntüle
dig +noall +answer example.com A example.com MX example.com NS

Gerçek Dünya Sorun Giderme Akışı

Bir DNS sorunu geldiğinde kafan karışmasın diye sistematik bir yaklaşım belirledim. Bunu bir nevi zihinsel checklist olarak kullan:

Adım 1: Sorunun kapsamını belirle

# Sadece bu domain mi etkileniyor?
dig google.com +short
dig problematic-domain.com +short

# Sadece belirli bir kayıt türü mü?
dig problematic-domain.com A
dig problematic-domain.com AAAA

Adım 2: Hangi DNS sunucusunun sorun çıkardığını bul

# Sistemin kullandığı DNS
cat /etc/resolv.conf
dig problematic-domain.com

# Public DNS ile karşılaştır
dig @8.8.8.8 problematic-domain.com
dig @1.1.1.1 problematic-domain.com

Adım 3: Yetkili sunucuyu kontrol et

# Önce NS kayıtlarını bul
dig problematic-domain.com NS +short

# Sonra doğrudan yetkili sunucuya sor
dig @ns1.problematic-domain.com problematic-domain.com A

Adım 4: Propagasyon durumunu değerlendir

# TTL'e bak
dig problematic-domain.com A | grep -A1 "ANSWER SECTION"

# Farklı coğrafi lokasyonlar için farklı DNS'lere sor
dig @ns1.he.net problematic-domain.com A    # Hurricane Electric
dig @ns1.quad9.net problematic-domain.com A  # Quad9

Faydalı dig Parametreleri

Sık kullandığım parametrelerin kısa bir özeti:

  • +short: Sadece cevabı gösterir, gereksiz detay olmadan
  • +trace: Root’tan başlayarak tüm DNS yolculuğunu takip eder
  • +dnssec: DNSSEC bilgilerini dahil eder
  • +time=N: Timeout süresini saniye cinsinden ayarlar
  • +tries=N: Kaç kez deneyeceğini belirler
  • +noall: Tüm çıktı bölümlerini gizler, seçici gösterim için kullanılır
  • +answer: Sadece ANSWER bölümünü gösterir
  • +stats: İstatistik bölümünü gösterir (sorgu süresi burada)
  • +recurse: Recursive sorgu ister (varsayılan zaten açık)
  • +norecurse: Non-recursive sorgu yapar
  • +tcp: UDP yerine TCP kullanır (büyük yanıtlar için veya UDP sorunlarında)
  • -4: Sadece IPv4 kullan
  • -6: Sadece IPv6 kullan
  • +multiline: SOA ve diğer karmaşık kayıtları okunabilir formatta gösterir
# TCP üzerinden sorgu (DNS over TCP testi)
dig @8.8.8.8 example.com +tcp

# IPv4 üzerinden sorgu zorla
dig -4 example.com A

dig ile Birlikte Kullanılan Araçlar

dig tek başına güçlü ama bazı durumlarda arkadaşlarıyla birlikte daha iyi çalışır:

# whois ile domain bilgisini kontrol et
whois example.com | grep -E "Expiry|Name Server"

# nmap ile DNS portunun açık olup olmadığını test et
nmap -p 53 dns-server-ip

# tcpdump ile DNS trafiğini yakala
sudo tcpdump -i eth0 port 53 -w dns-capture.pcap

# systemd-resolve (modern Linux sistemlerde)
resolvectl status
resolvectl query example.com

Sonuç

DNS sorunları, karmaşık göründüğü kadar gizemli değil. dig komutunu doğru kullandığında, sorunun kaynağını genellikle birkaç sorgu ile tespit edebiliyorsun. Önemli olan sistematik düşünmek: önce sorunun kapsamını belirle, sonra hangi sunucunun yanlış cevap verdiğini bul, ardından yetkili sunucudan başlayarak yukarı doğru çalış.

Pratikte en çok işe yarayan birkaç kuralı aklında tut: her zaman önce +short ile hızlı kontrol yap, fark varsa +trace ile nerede koptuğunu gör, TTL’i ihmal etme ve internal ile external DNS’i her zaman ayrı ayrı test et.

Bir de şunu ekleyeyim: bu sorguları bir kenara kaydet, .bashrc dosyana alias olarak ekle. “dig_check” gibi bir alias ile sık kullandığın sorgu setini tek komutla çalıştırabilirsin. Sysadmin hayatında en değerli şey, kriz anında hazır araçlara sahip olmaktır.

Benzer Konular

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir