DNS Sorgu Hacmi Nasıl Analiz Edilir?

Sesli Dinle — Makale

DNS sorgu hacmi analizi, yalnızca bir günlük dosyasındaki satırları saymak değildir. İlk adım, verinin yetkili DNS sunucusundan mı, recursive resolver (özyinelemeli DNS çözümleyicisi) hizmetinden mi yoksa istemci telemetrisinden mi geldiğini belirlemektir; bu kaynaklar aynı trafiği görmez.

Veri kaynağını, amacı, zaman aralığını ve karşılaştırılacak dağılımları birlikte tanımlayın. Aksi halde yüksek görünen bir sayı kapasite ihtiyacı, normal kullanıcı davranışı veya kötüye kullanım belirtisi olarak yanlış yorumlanabilir.

Güvenilir bir analiz yalnız mevcut verinin desteklediği hacim ve güvenlik bulgularına dayanır. Eksik günlüklerin, örneklenmiş kayıtların, önbellek davranışının ve gizlilik amacıyla uygulanan veri sınırlamalarının sonuçları nasıl etkilediğini de raporda açıkça belirtin.

DNS Veri Kaynağının Analiz Sonucuna Etkisi

DNS rollerini birbirinden ayırmak analizin temelidir. Aynı alan adı için bir istemcinin gönderdiği sorguyu recursive resolver önbellekten yanıtlayabilir; sorgu bu durumda yetkili sunucuya hiç ulaşmaz. Bu nedenle farklı gözlem noktalarındaki sayıları doğrudan toplamayın veya birbirinin yerine kullanmayın.

Aşağıdaki karşılaştırma, üç veri kaynağının hangi soruya yanıt verebildiğini ve hangi sonucu tek başına desteklemediğini gösterir.

Yetkili DNS Sunucusu Verisi

Yetkili sunucu verisi, yönetilen alan adları için yetkili altyapıya ulaşan sorguları gösterir. Bu kaynak, alan adı bazında gelen yükü, kayıt türü dağılımını, yanıt kodlarını ve sorgu kaynağı olarak görünen recursive resolver hizmetlerinin ağlarını incelemek için uygundur.

Bu veri, son kullanıcıların yaptığı bütün DNS sorgularını göstermez. Recursive resolver önbelleği nedeniyle çok sayıda istemci isteği tek bir yetkili sorguya dönüşebilir. Bu yüzden yetkili trafik, kullanıcı cihazlarındaki toplam sorgu sayısını vermez.

Recursive Resolver Verisi

Recursive resolver telemetrisi, kendisine başvuran istemcilerden gelen sorguları ve çözümleme sürecini gözlemleyebilir. Yapılandırmaya bağlı olarak toplam istek sayısı, önbellekten karşılanan sorgular, çözümleme sırasında başka DNS sunucularına gönderilen sorgular, yanıt kodları, gecikme ve taşıma yöntemleri gibi veriler ölçülebilir.

Bu kaynak, recursive resolver kapasitesini ve istemci gruplarının davranışını incelemek için daha uygundur. Ancak tek bir recursive resolver hizmetinden alınan veriler, internetteki toplam yetkili DNS trafiğini temsil etmez ve başka recursive resolver hizmetlerinin aldığı sorguları kapsamaz.

İstemci Telemetrisi

İstemci telemetrisi bir cihazın, uygulamanın veya sınırlı bir uç nokta grubunun DNS etkinliğini gösterir. Belirli bir uygulama sürümünün neden çok sorgu ürettiğini veya bir cihazda tekrar eden başarısız çözümlemeleri araştırırken yararlı olabilir.

İstemci geçmişi, alan adının toplam sorgu hacmi değildir. Yerel önbellek, işletim sistemi davranışı, uygulamanın kendi DNS çözümleme yöntemi ve şifreli DNS seçenekleri gözlemlenen kayıtları değiştirebilir.

DNS Sorgu Hacmi Farklı Amaçlarla Nasıl Yorumlanır?

Aynı veri, farklı amaçlarla farklı biçimde gruplanır. Kapasite planlamasında saniyedeki sorgu sayısını gösteren QPS, gecikme ve hata oranı öne çıkarken kötüye kullanım incelemesinde kaynak ağlar, sorgu adı çeşitliliği ve olağan dışı yanıt kodları daha anlamlı olabilir.

Kapasite Planlama

Kapasite analizi, ortalama yükün yanı sıra hizmetin taşıması gereken tepe yükü de gösterir. Toplam sorgu sayısı tek başına yeterli değildir; kısa süreli sıçramaları, yoğun saatleri, yanıt süresini ve sistemin doygunluğa yaklaşıp yaklaşmadığını aynı zaman çizelgesinde inceleyin.

Örneğin günlük toplam sabit kalırken sorgular birkaç dakikada yoğunlaşıyorsa ortalama QPS düşük görünebilir. Bu nedenle kapasite kararı verirken ölçüm aralığı kısaltıldığında görülen tepe değerlerini altyapının gerçek kaynak kullanım ölçümleriyle birlikte değerlendirin.

DNS Sorunlarını Araştırma

Sorun giderirken hacim değişikliğini belirli bir belirtiyle eşleştirin. Yanıt kodu dağılımındaki değişim, belirli kayıt türündeki artış, gecikmenin artması veya önbellek isabetindeki düşüş aynı zaman aralığında karşılaştırılabilir.

Bir değişikliğin veya yeni bir uygulama sürümünün devreye alındığı an ya da ağ kesintisinin zamanı biliniyorsa önceki ve sonraki dönemleri aynı göstergelerle incelemek gerekir. Farklı uzunluklardaki ya da eksik veri içeren aralıklar doğrudan karşılaştırıldığında sonuç yanıltıcı olur.

Recursive resolver hizmetindeki önbellek isabetinin düşmesi, daha fazla sorgunun başka DNS sunucularına gönderilmesine ve gecikmenin artmasına yol açabilir. Bunun nedeni, kaydın önbellekteki normal geçerliliğini saniye cinsinden belirten TTL değerinin kısa olması, çok sayıda farklı sorgu adı, boş önbellek veya yapılandırma değişikliği olabilir. Yalnız oran değişimine bakarak belirli bir neden seçmeyin.

Kötüye Kullanım ve Güvenlik İncelemesi

Yüksek sorgu hacmi tek başına saldırı kanıtı değildir. Belirli kaynak ağlarda beklenmedik yoğunluk, var olmayan adlara yönelen çok sayıda sorgu, sıra dışı kayıt türleri veya kısa sürede artan sorgu adı çeşitliliği daha yakından inceleme gerektirebilir; ancak normal kampanya trafiği, hatalı istemci yazılımı veya otomasyon da benzer belirtiler gösterebilir.

Güvenlik değerlendirmesinde hacim verisini sorguların zamanı, kaynak dağılımı, yanıt davranışı ve ilgili altyapı olaylarıyla birlikte inceleyin. Yeterli veri yoksa gerçek saldırı büyüklüğünü veya saldırgan sayısını tahmin etmeyin.

NXDOMAIN, sorgulanan adın veya adlar arasında takma ad ilişkisi kuran CNAME zincirindeki bir adın bulunmadığını belirten yanıt kodudur. Bu kodun yanıtlar içindeki oranının artması, mutlak NXDOMAIN sayısının da arttığı anlamına gelmez; toplam yanıt sayısı azalmış olabilir. Nedeni araştırırken yazım hatası, eski yapılandırma, otomatik ad üretimi ve kötüye kullanım olasılıklarını ayrı kanıtlarla inceleyin. Sunucunun sorguyu tamamlayamadığını bildiren SERVFAIL kodundaki artış da tek bir arıza nedenini göstermez.

DNS Sorgu Hacminde Zaman Aralığı Seçimi

İnceleyeceğiniz zaman aralığını araştırılan olayın süresine göre seçin. Saniyelik veya dakikalık aralıklar ani sıçramaları gösterirken saatlik ve günlük aralıklar düzenli kullanım eğilimlerini ortaya çıkarır. Tek bir aralığa bağlı kalmak yerine genel eğilimden ayrıntıya doğru ilerlemek daha güvenilir sonuç verir.

Karşılaştırma dönemi, incelenen dönemin gün ve saat koşullarını mümkün olduğunca yansıtmalıdır. Hafta içini hafta sonuyla, bakım dönemini normal çalışma dönemiyle veya farklı saat dilimlerindeki verileri açıklama yapmadan kıyaslamak doğal trafik döngülerini anormallik gibi gösterebilir.

QPS, seçilen aralıktaki sorgu sayısının saniye sayısına bölünmesiyle elde edilir. Ortalama QPS genel yükü özetler; kısa zaman aralıklarında görülen en yüksek QPS ise tepe yükünü ve kapasite ihtiyacını anlamaya yardımcı olur. Kullandığınız aralığı ve hesap yöntemini raporda açıkça yazın.

Sorgu Hacmini Açıklayan Veriler

DNS trafik analizi tek bir sayı yerine, hacmi açıklayan birden fazla ölçüm ve dağılım kullanır. Hangi ölçüm ve dağılımların kullanılabileceği veri kaynağına bağlıdır; yetkili sunucuda bulunmayan önbellek bilgilerini sonradan varsayımla eklemeyin.

• Toplam sorgu ve QPS: Genel hacmi ve birim zamandaki yükü gösterir; ortalama QPS ile tepe QPS değeri ayrı tutulur.
• Yanıt kodu: NXDOMAIN ve SERVFAIL yanında NOERROR ve REFUSED dağılımını da inceleyin. NOERROR hata kodu bildirilmediğini, REFUSED ise sunucunun sorguyu reddettiğini gösterir. NOERROR yanıtında istenen kayıt bulunmayabilir; bu kod tek başına kayıt bulunduğu anlamına gelmez.
• Kayıt türü: IPv4 adresi için A, IPv6 adresi için AAAA, posta sunucusu için MX ve metin verisi için TXT sorgularının yük içindeki payını karşılaştırın.
• İstemci ağı: Tam istemci IP adreslerini ayrı ayrı göstermeden, ağ veya uygun biçimde gruplanmış adres aralıkları üzerinden yoğunluğu karşılaştırır.
• Önbellek isabeti: recursive resolver verisinde, istemci isteklerinin ne kadarının önbellekten karşılandığını gösterir; yetkili DNS için aynı anlamda kullanılamaz.
• Gecikme ve taşıma: Ölçüm kaynağı destekliyorsa yanıt süresini ve taşıma yöntemini ayrı inceleyin. Klasik DNS sorguları UDP veri paketleriyle veya TCP bağlantılarıyla taşınabilir; DoH, HTTPS üzerinden, DoT ise TLS ile şifrelenmiş bir bağlantı üzerinden DNS taşır. Alt taşıma protokolü ile şifreli DNS yöntemini ayrı alanlarda tutun; aynı DoT sorgusunu hem TCP hem DoT diye genel toplama iki kez eklemeyin.

Bu ölçümleri ve dağılımları birlikte kullanmak değişimin kaynağını daraltır. Örneğin toplam hacim artarken yalnız AAAA sorguları yükseliyorsa bu durum genel talep artışından çok belirli bir istemci türüne veya yapılandırma değişikliğine işaret edebilir. Bu gözlem tek başına hata veya saldırı kanıtı değildir.

İstemci IP adresi sayısı gerçek kullanıcı sayısı değildir. Adres çevirisi yapan NAT, aboneler arasında genel IPv4 adresini paylaşan CGNAT, kurumsal çıkışlar ve recursive resolver hizmetleri birçok kullanıcıyı tek adres altında gösterebilir. IPv6 adres değişimleri ise tek kullanıcıyı birden fazla adresle temsil edebilir.

DNS Günlüklerinden Sorgu Hacmini Hesaplama

1. Sayılacak olay: Seçtiğiniz gözlem noktasındaki sorgu olaylarını ayırın. Günlük hem sorgu hem yanıt içeriyorsa iki satırı iki sorgu saymayın. Recursive resolver hizmetinin istemciden aldığı ve başka sunuculara gönderdiği sorguları ayrı toplamlar halinde tutun.
2. Veri bütünlüğü: Kayıp dönemleri, saat uyumsuzluğunu, örneklemeyi, filtrelemeyi ve yeniden başlatma boşluklarını işaretleyin. Eksik kayıt aralığını sıfır trafik olarak göstermeyin.
3. Zaman aralıkları: Zaman damgalarını ortak saat dilimine çevirin ve eşit uzunluktaki aralıklara ayırın. Karşılaştırmalarda aynı sorgu türünü, kapsamı ve süreyi kullanın.
4. Sorgu sayısı: Her aralıktaki sorgu olaylarını sayın. Ağ yükünü ölçerken yeniden gönderilen sorguları da sayın; aynı olayın günlük sisteminde oluşan kopyalarını ise ayrı sorgu gibi eklemeyin.
5. QPS hesabı: Eksiksiz gözlenen aralıktaki sorgu sayısını o aralığın saniye sayısına bölün. Eşit aralıklardaki en yüksek değeri tepe QPS olarak raporlayın; aralık uzunluğunu mutlaka belirtin.
6. Yanıt ve olay karşılaştırması: Yanıt kodu oranlarının hangi toplam üzerinden hesaplandığını yazın. Yanıtsız sorguları ayrı gösterin; bunları kendiliğinden SERVFAIL saymayın. Değişiklik, bakım ve uygulama sürümü kayıtlarını aynı zaman çizelgesiyle karşılaştırın.

Örneğin beş dakikalık eksiksiz bir kayıtta 60.000 sorgu varsa ortalama QPS, 60.000 / 300 = 200 olur. Aynı sürede bir saniyede 1.500 sorgu görülmüşse bir saniyelik aralıklarla ölçülen tepe 1.500 QPS olabilir; beş dakikalık ortalama bu sıçramayı göstermez. Bir dakikalık günlük eksikse kalan dört dakikanın sayısını beş dakikaya bölüp sonucu eksiksiz ölçüm gibi sunmayın.

Ham günlük biçimi değişse bile zaman, sorgu, yanıt, taşıma ve gözlem noktası alanlarını aynı anlamla kullanın. Kapsanan sistemleri, filtreleri, örnekleme yöntemini, karşılaştırma dönemini ve verinin desteklemediği çıkarımları raporda belirtin. Örnekten elde edilen hacmi kesin sayım değil, kullanılan yönteme bağlı bir tahmin olarak gösterin.

DNS Günlüklerinde Gizlilik ve Saklama Süresi

DNS günlükleri, istemcilerin erişmeye çalıştığı hizmetler hakkında hassas bilgi taşıyabilir. Bu nedenle yalnız analiz için gerekli alanları toplamak, istemcilerin tam IP adreslerini uygun biçimde maskelemek veya ağ düzeyinde gruplamak ve ayrıntılı sorgu adlarına erişimi sınırlamak gerekir.

DNS günlüklerini ne kadar saklayacağınızı analizin amacına göre belirleyin ve bu süreyi gerekçelendirin. Sorun giderme için tutulan kısa süreli kayıtlarla uzun dönem eğilim verilerini aynı ayrıntı düzeyinde tutmak gerekmez. Eski verileri toplu istatistiklere dönüştürebilirsiniz; ancak IP adreslerini maskelemek tek başına tam anonimlik sağlamaz. Ayrıntılı sorgu adları ve sorguların zaman içindeki düzeni, kayıtların aynı cihaz veya kullanıcıyla yeniden ilişkilendirilmesine yol açabilir.

Erişim yetkileri, kayıtların dışa aktarımı ve silme süreci analiz tasarımının parçasıdır. Gizlilik için uygulanan örnekleme veya anonimleştirme hacim hesabını etkiliyorsa kullanılan yöntemi raporda açıkça belirtin.