DNS Sağlık Kontrolü Sonuçları Nasıl Yorumlanır?

Sesli Dinle — Makale

DNS sağlık kontrolü raporundaki her kırmızı veya sarı bulgu aynı etkiye sahip değildir. Bazı hatalar alan adının çözümlenmesini doğrudan engellerken bazı uyarılar yalnız yedeklilik, tutarlılık veya değişiklik yönetimi açısından risk bulunduğunu gösterir.

Raporu değerlendirirken toplam puandan önce DNS çözümleme zincirinin nerede bozulduğuna bakın. İlk olarak üst bölgedeki delegasyonun çalışan yetkili DNS sunucularını gösterip göstermediğini, ardından bu sunucuların yapılandırmada beklenen geçerli yanıtları verip vermediğini kontrol edin.

DNS Sağlık Kontrolü aracından alınan sonuçlar, yapılandırmanın hangi bölümünün incelenmesi gerektiğini gösteren tanılama bulgularıdır. Rapor tek başına her uyarının kesinti veya güvenlik açığı olduğunu kanıtlamaz.

Hata, Uyarı ve Bilgi Sınıfları Ne Anlatır?

Rapor sınıfları bulgunun muhtemel etkisini gösterir. Bir bulgunun gerçek önemini ise test edilen kayıt ve alan adının yapısı belirler. Aynı bulgu bir yapılandırmada kritik, başka bir yapılandırmada beklenen davranış olabilir.

Hata Bulguları

Hata sınıfı genellikle çözümlemenin tamamlanmasını engelleyen veya DNS zincirini geçersiz duruma getiren bir sorun olduğunu belirtir. Çalışan yetkili sunucu bulunamaması ve gerekli delegasyon bilgisinin eksik olması başlıca örneklerdir. DNS kayıtlarının kaynağını ve bütünlüğünü dijital imzalarla denetleyen DNSSEC de beklenen güven zincirini doğrulayamazsa çözümleme başarısız olabilir.

Hatanın tek bir kontrol noktasında mı, yoksa bütün yetkili sunucularda mı görüldüğünü ayrıca kontrol edin. Tek sunucunun yanıt vermemesi yedekliliği azaltabilir; bütün sunucuların yanıtsız olması ise alan adının birçok kullanıcı için çözümlenememesine yol açabilir.

Uyarı Bulguları

Uyarılar, hizmet çalışmaya devam etse bile yapılandırmanın tutarsız, kırılgan veya yönetimi zor olduğunu gösterebilir. Yetkili sunucuları belirten NS kayıtlarının üst ve alt bölgede farklı olması, bölgenin seri numarası ile yenileme sürelerini içeren SOA bilgilerinin sunucular arasında uyuşmaması veya sıra dışı TTL değerleri buna örnektir. TTL, bir kaydın normal koşullarda yeniden sorgulanmadan önbellekten kullanılabileceği süreyi saniye cinsinden belirtir.

Bir uyarıyı ertelemeden önce nedenini anlamak gerekir. Sitenin açılması tek başına yapılandırmanın sağlıklı olduğunu göstermez; önbellekte bulunan eski bir yanıt veya yalnızca tek bir DNS sunucusunun çalışması sorunu geçici olarak gizleyebilir.

Bilgi Bulguları

Bilgi sınıfı, raporun tespit ettiği fakat doğrudan düzeltme gerektirmeyen özellikleri gösterir. DNSSEC kullanılmaması, belirli bir kayıt türünün bulunmaması veya mevcut TTL değerinin raporlanması yapılandırmanın amacına bağlı olarak yalnız bilgilendirme niteliğinde olabilir.

Bilgi bulguları diğer hataların nedenini açıklamak için kullanılabilir. Buna karşılık yalnız bilgi seviyesinde gösterilen bir maddeyi bağlamdan kopararak güvenlik açığı veya kesinti nedeni olarak sınıflandırmak doğru değildir.

Yetkili DNS Sunucusu ve Recursive Resolver Sonuçlarını Karşılaştırma

DNS sağlık sonuçlarını yorumlarken yanıtın nereden geldiğine de bakın. Yetkili DNS sunucusu, alan adının yayımlanan kayıtlarının kaynağıdır; recursive resolver (özyinelemeli DNS çözümleyicisi) ise bu bilgileri DNS zincirinden toplar, önbelleğe alır ve istemciye iletir.

Yetkili Sunucu Bulguları

Yetkili sunucuların doğrudan sorgulanması, bölgenin güncel yapılandırmasını gösterir. Her yetkili sunucu ilgili bölge için yanıt vermeli ve yapılandırmada beklenen güncel veriyi sunmalıdır. Sunucular arasında NS, SOA veya temel yanıt farklılıkları varsa dağıtım tamamlanmamış olabilir ya da sunuculardan biri eski yapılandırmayı sunuyor olabilir.

Adres yanıtlarının farklı olması her zaman hata değildir. Yük dengeleme veya konuma dayalı DNS tasarımı bilinçli olarak farklı adres kümeleri döndürebilir. Bu durumda rapordaki tutarsızlık uyarısını planladığınız davranışla karşılaştırın.

Recursive Resolver Bulguları

Recursive resolver hizmetinden alınan sonuç, önbellek süresi, yerel politika ve önceki çözümleme hatalarından etkilenebilir. Yetkili sunucular yeni ve doğru kayıtları döndürürken bazı recursive resolver hizmetleri TTL sona erene kadar eski yanıtı gösterebilir.

Sorgunun tamamlanamadığını belirten SERVFAIL, sorgunun reddedildiğini belirten REFUSED ve sunucuya ulaşılamaması gibi çözümleme başarısızlıkları da kısa süreli olarak önbellekte tutulur. Güncel standart bu süreyi en az 1 saniye, en fazla 5 dakika olarak belirler; bu süre sorgulanan kaydın TTL değerinden ayrı değerlendirilir. Bu nedenle yapılandırma düzeltildikten hemen sonra görülen eski hata, sorunun devam ettiğini tek başına kanıtlamaz.

Delegasyon Hataları ve Yetkili Sunuculara Erişim

Delegasyon, üst DNS bölgesinin alan adı için hangi yetkili sunuculara başvurulacağını göstermesidir. Bu zincir bozuksa alt bölgedeki kayıtlar doğru olsa bile recursive resolver yetkili kaynağa ulaşamayabilir.

NS ve Glue Kayıtlarındaki Sorunlar

Üst bölgedeki NS listesinde, gerçekten çalışan ve ilgili bölge için yetkili olan DNS sunucuları bulunmalıdır. Üst bölge ile alan adının kendi bölgesindeki NS kayıtlarının farklı olması, bazı recursive resolver hizmetlerinin sorguları başka sunuculara göndermesine ve tutarsız sonuçlara neden olabilir.

Yetkili sunucunun adı devredilen alan adının altında bulunuyorsa çözümlemenin başlayabilmesi için üst bölgede gerekli glue kaydı bulunmalıdır. Bu kayıt, yetkili sunucu adının IP adresini üst bölgede gösterir ve aynı alan adına yeniden başvurma gereksinimini ortadan kaldırır. Glue kaydı eksik veya yanlışsa recursive resolver yetkili sunucunun IP adresini öğrenemeyebilir ve çözümleme döngüye girebilir.

Yanıtsız ve Hatalı Sunucular

Bir DNS sunucusunun hiç yanıt vermemesi, açık bir hata yanıtından farklıdır. Yanıtsız sunucuya yapılan denemeler süre kaybettirebilir. Recursive resolver başka bir sunucuyu da deneyebilir; toplam gecikme, yeniden deneme ve zaman aşımı ayarlarına bağlıdır. Birden fazla sunucu aynı biçimde yanıtsızsa kesinti olasılığı yükselir.

REFUSED yanıtı, sunucunun sorguyu politika gereği reddettiğini gösterir. Yetkili sunucu kendi bölgesindeki normal bir sorguyu reddediyorsa yapılandırmayı inceleyin. Buna karşılık yalnız kendi bölgelerine yanıt vermek üzere yapılandırılmış bir yetkili sunucunun başka bir alan adı için çözümleme isteğini reddetmesi beklenen davranıştır.

SERVFAIL yanıtı ise sunucunun sorguyu tamamlayamadığını gösterir. SERVFAIL'in nedeni yetkili bölgedeki yanlış yapılandırma, DNSSEC doğrulama hatası, erişilemeyen başka bir DNS sunucusu veya recursive resolver hizmetindeki geçici arıza olabilir. Kesin nedeni anlamak için aynı sorguyu hem yetkili sunuculara hem de farklı recursive resolver hizmetlerine gönderip sonuçları karşılaştırmak gerekir.

Yetkili Sunucularda Kayıt ve Bölge Tutarlılığı

Delegasyon doğru çalışıyorsa sonraki adım, bütün yetkili sunucuların bölge verilerini planlanan biçimde sunduğunu doğrulamaktır. NS ve SOA bilgilerindeki farklar, bölge kopyalarının eş zamanlı güncellenmediğini veya sunuculardan birinin yanlış bölgeyi yayımladığını gösterebilir.

SOA seri değerlerinin farklı olması tek başına kesintiyi göstermez. Yine de sunuculardaki kayıtların gerçekten aynı olup olmadığını kontrol etmek gerekir. Eski seri değerini taşıyan sunucu, yakın zamanda yapılan değişikliği henüz almamış olabilir.

CNAME, bir adı başka bir ada takma ad olarak bağlar. Aynı ad ve DNS sınıfında CNAME ile IPv4 adresi taşıyan A veya IPv6 adresi taşıyan AAAA gibi kayıtlar birlikte yayımlanamaz. DNSSEC için gerekli imza ve yokluk kanıtı kayıtları bu yasağın istisnasıdır. Bu tür bir çakışma varsa düzeltme, kaydın kullanım amacına göre DNS hizmetini yönettiğiniz paneldeki asıl bölge yapılandırmasında yapılır.

DNSSEC Kullanılmaması ile Bozuk Güven Zinciri Arasındaki Fark Nedir?

DNSSEC raporlarında “kullanılmıyor” durumu ile “etkin fakat doğrulanamıyor” durumunu birbirinden ayırmak gerekir. Üst bölgedeki DS kaydı, alt bölgenin DNSSEC anahtarını üstteki güven zincirine bağlar. DS kaydı bulunmayan ve imzasız çalışması planlanan bir alan adı için DNSSEC kullanılmaması doğrudan çözümleme hatası değildir.

Üst bölgedeki DS kaydı güvenilen bir zincir üzerinden doğrulanabiliyorsa DNSSEC doğrulaması yapan recursive resolver, alt bölgenin de bu zincire uygun olmasını bekler. DS, açık anahtarı içeren DNSKEY ve kayıtların dijital imzaları birbiriyle uyuşmazsa doğrulama başarısız olur ve istemciye SERVFAIL dönebilir. Bu uyumsuzluk, kesintiye yol açabilecek yüksek öncelikli bir yapılandırma sorunudur ve göz ardı edilmemelidir.

DNSSEC değişikliği yaparken kayıt kuruluşundaki DS bilgisi ile yetkili DNS hizmetindeki anahtarları birlikte yönetmek gerekir. Anahtar değişimi ile DS güncellemesi yanlış sırada yapılırsa bazı recursive resolver hizmetlerinin önbelleğinde geçici bir güven zinciri uyumsuzluğu oluşabilir.

TTL Uyarılarının Değişiklik ve Sorgu Yüküne Etkisi

Yüksek veya düşük TTL değeri tek başına hatalı değildir; hangi TTL değerinin seçileceği değişiklik sıklığına, sorgu yüküne ve yapılacak değişikliklerin planına bağlıdır. Önbellekteki kayıt daha erken silinebilir. Ayrıca bazı recursive resolver hizmetleri, kaydı yenileyemediklerinde hizmetin sürmesi için süresi dolmuş veriyi geçici olarak sunabilir; TTL bütün istemcilerin kesin güncellenme zamanı değildir.

Yüksek TTL, değişiklikten önce önbelleğe alınan eski yanıtların daha uzun süre kullanılmasına neden olabilir. Düşük TTL ise sorguların yetkili sunuculara daha sık ulaşmasına yol açar ve gereksiz yere çok düşük tutulduğunda sorgu yükünü artırabilir.

TTL uyarısına, yanlış delegasyon veya ulaşılamayan sunucu gibi temel hataları giderdikten sonra geçin. Çalışmayan bir kaydın TTL değerini değiştirmek kaydı düzeltmez; yalnız o kaydın önbellekten kullanılma süresini etkiler. Önceden önbelleğe alınmış bir kaydın süresi de yetkili sunucudaki TTL değişikliğiyle geriye dönük kısalmaz.

DNS Bulgularının Düzeltme Öncelikleri

Aşağıdaki sıralama başlangıç noktasıdır; gözlenen kesinti ve etkilenen kullanıcılar önceliği belirler. Eksik glue veya kayıt tutarsızlığı o anda çözümlemeyi engelliyorsa bu bulguları da birinci sıraya alın.

DNS Düzeltmesinden Sonra Sonuçları Doğrulama

Değişiklikten önce hatalı sorgunun tam adını, kayıt türünü, sorgulanan sunucuyu ve test zamanını not edin. Delegasyon değişiklikleri ilgili üst bölgeyi yöneten yerden yapılır; kayıtlı alan adlarında bu işlem genellikle kayıt kuruluşunun panelindedir. Bölge içindeki kayıtlar ise yetkili DNS hizmetinin panelinden değiştirilir.

Düzeltmeden sonra aynı ad ve kayıt türüyle önce ilgili yetkili sunuculara, ardından daha önce hata veren recursive resolver hizmetine sorgu gönderin. Doğrudan yanıt düzelmişken önbellekten eski yanıt geliyorsa kalan TTL veya hata önbelleği süresi sonrasında testi tekrarlayın. Eski sonuç sürüyorsa yalnız beklemekle yetinmeyin; sorgunun hangi sunucuya gittiğini ve o sunucunun yetkili kaynağa ulaşıp ulaşamadığını kontrol edin. Testin zamanı, kullanılan sunucu ve dönen yanıtı ilk sonuçla birlikte kaydedin.