dig ile işlem geçmişini inceleme

dig ile işlem geçmişini inceleme

İnternet üzerindeki alan adlarına ilişkin bilgi toplarken kullandığımız araçlardan biri olan dig, sadece anlık sorguların ötesine geçip işlem geçmişini anlamak için de güçlü bir ipucu verebilir. Bu yazı, dig’in günlük yönetim veya güvenlik bağlamında nasıl kullanıldığını, hangi çıktıları nasıl yorumlamamız gerektiğini ve sık karşılaşılan sorunları adım adım ele alır.

1) dig’in temel çalışma prensibi ve çıktılarının okunması
dig, DNS sorgularını yerel veya uzak resolver üzerinden işler ve A/AAAA, MX, NS, TXT gibi kayıt türlerine dair yanıtlar ile birlikte sorgu süresi, cache durumları ve ters DNS ipuçlarını da sunar. En temel çıktı şu bölümlerden oluşur:

• HEADER: Sorgu türü ve yanıtın başarılı olup olmadığına dair bayraklar.
• QUESTION: Gönderilen sorgunun formatı ve hedef alan adı.
• ANSWER: Hedef kaydın tipi ve değerleri.
• AUTHORITY: Yetkili sunucularla ilgili bilgiler, çoğu zaman NS kayıtları veya yetki kaynağına dair ipuçları verir.
• ADDITIONAL: Ek bilgiler, IP adresleri veya ilgili başka kayıtlar (A/AAAA, glue kayıtları vb.).
• Query time: Sorgunun tamamlanma süresi.
• WHEN/CLIENT: Zaman damgası ve kullanılan istemci.

2) işlem geçmişini incelemek için pratik kullanımlar

• Sorgu geçmişinin izlenmesi: Süreçlerin tam olarak hangi adımlarda zaman aldığına bakmak için dig +trace kullanılır. Bu mod, kök sunucular üzerinden başlayan zincirde hangi adımlarda gecikme veya başarısızlık olduğunu gösterir.
• Zaman damgaları ve gecikme analizi: dig +stats çıktısı, cache süresi, sorgu süreleri ve yanıt boyutları gibi metrikleri verir. Özellikle sık tekrarlanan sorguların gecikme ayarlarını anlamak için yararlıdır.
• Güvenlik ve doğrulama: dig +norecurse veya dig +short ile yalnızca güvenilir ve minimal yanıtlar elde edilerek, ağ yöneticileri doğruluk kontrolleri yapabilir. Ayrıca dig +answerflags ile DNSSEC durumunu kontrol etmek mümkündür.
• Offline analiz için çıktı biçimleri: dig +noall +answer +additional +answer gibi özelleştirilmiş çıktılar, log analizine uyarlanabilir. Giriş noktası olarak CSV veya JSON dönüştürme için dış araçlar kullanılabilir.

3) güvenlik ve performans açısından dikkat edilmesi gerekenler

• Kök ve yetkili sunuculara yönelik sorgularda politika ve rate limit etkileri göz önünde bulundurulmalı; aşırı sorgu, ağ üzerinde beklenmeyen yük oluşturabilir.
• TTL değerlerinin anlamı: Yükselen TTL, cache etkileri ve güncellemelerin görünürlüğüne bağlı olarak değişir; yanlış yorumlanan TTL, sahte veya eski bilgilerle hareket etmenize yol açabilir.
• DNSSEC kontrolü: DNSSEC imzaları bozulduysa veya zincir kırık görünüyorsa, güvenlik açıkları ortaya çıkabilir. Bu durumda güvenilirlik için ek doğrulama adımlarına ihtiyaç duyulur.

4) örnek pratik senaryo
Bir kullanıcı bir alan adını çözerken beklenen A kaydı yerine güncellenmiş bir IP görmüyor. Önce dig +trace ile kök sunucularından başlayıp yetkili ad sunucularına kadar adımları takip etmek, hangi aşamada eski kaydın döndüğünü veya cache’e takılı kaldığını gösterir. Ardından dig @ns1.example.net example.org A +norecurse ile doğrulama yapıp, dig +stats ile yanıt sürelerini karşılaştırmak sorunun kaynağını netleştirebilir. Sonuç olarak TTL’nin dolma süresiyle ilgili bir sorun mu yoksa yetkili sunucuda güncelleme gecikmesi mi olduğu ortaya çıkar.

5) kapanış
Bu yöntemi kullanırken, hangi adımların izlenebilir olduğunu ve çıktıyı nasıl yorumlayacağınızı temel adımlarla kavramak, günlük ağ yönetimini hızlı ve güvenilir kılar. Özellikle yapılandırma değişikliklerinin hemen etkisini görmek için +trace ve +stats kombinasyonu pratik bir çerçeve sunar. Bu konuya ilişkin deneyimlerinizi ve karşılaştığınız ilginç durumları paylaşabilirsiniz.