DNSSEC Hatası Neden Yalnız Bazı Kullanıcılarda Görülür?

Bir alan adı bir ağda çözümlenirken başka bir ağdaki DNS sorgusu SERVFAIL veriyorsa ikinci ağda ad çözümleme işlemi başarısız olmuş demektir. Fark, kullanıcı adına DNS yanıtını bulan recursive resolver (özyinelemeli DNS çözümleyicisi) hizmetlerinin DNSSEC doğrulaması ve önbellek durumlarının aynı olmamasından kaynaklanabilir.
DNS, alan adlarına ait IP adresi ve diğer kayıtların bulunmasını sağlar. DNSSEC ise bu kayıtların kaynağını ve bütünlüğünü dijital imzalarla doğrular; DNS sorgusunu şifrelemez.
Doğrulama yapan bir recursive resolver, güven zinciri kurulması gereken DNS verisinin imzalarını doğrulayamazsa yanıtı geçersiz kabul edebilir ve istemciye SERVFAIL döndürebilir. Doğrulama yapmayan, doğrulamayı yerel politika gereği devre dışı bırakan veya farklı önbellek durumuna sahip başka bir recursive resolver ise aynı DNS yanıtını kullanılabilir kabul edip istemciye iletebilir.
Bu nedenle yalnız “bir yerde açılıyor, bir yerde açılmıyor” gözlemi DNSSEC arızasını kanıtlamaz. Aynı alan adı ve kayıt türü için kullanılan recursive resolver hizmetlerini, DNS yanıtının sonucunu belirten RCODE değerlerini, imza doğrulamasını ve önbellek durumunu birlikte karşılaştırın. SERVFAIL, bu sonuç kodlarından biridir.
DNSSEC Hatasının Yalnız Bazı Ağlarda Görülmesinin Nedenleri
Kullanıcıların aynı alan adına ulaşması, aynı recursive resolver hizmetini kullandıkları anlamına gelmez. Ev ağı, mobil bağlantı, kurumsal ağ veya uygulama içindeki DNS ayarı sorguları farklı recursive resolver hizmetlerine yönlendirebilir; bu hizmetlerin DNSSEC doğrulama ve önbellek durumları da aynı olmayabilir.
DNSSEC Doğrulaması Yapan ve Yapmayan Recursive Resolver Hizmetleri
DNSSEC açısından en belirleyici ayrım, recursive resolver hizmetinin imza doğrulaması yapıp yapmamasıdır. Doğrulama yapan bir recursive resolver, önceden güvenilir kabul ettiği bir anahtar veya anahtar özetinden başlayarak yanıtın güven zincirini kurar. DNSKEY kaydı açık anahtarı taşır; üst bölgedeki DS kaydı ise yetkinin devredildiği alt bölgenin anahtarına güven bağı kurmak için kullanılır. RRSIG kayıtları da DNS kayıt kümelerinin imzalarını taşır. Zincirin kurulması beklenmesine rağmen doğrulama başarısız olursa recursive resolver veriyi bogus (geçersiz) sayabilir ve istemciye RCODE 2, yani SERVFAIL döndürebilir.
Doğrulama yapmayan bir recursive resolver aynı kriptografik kontrolü uygulamadığı için imzası sorunlu DNS verisini yine de istemciye iletebilir. Bu durum, sitenin gerçekten sağlıklı olduğu anlamına gelmez; yalnız iki recursive resolver hizmetinin aynı DNS verisine farklı güvenlik denetimi uyguladığını gösterir.
Recursive Resolver Önbelleklerinin Farklı Sürelerde Yenilenmesi
Recursive resolver hizmetleri yanıtları ve DNSSEC ile ilişkili kayıtları önbelleğe alır. DS kaydı üst bölgede, DNSKEY veya imza kayıtları ilgili alt bölgede değiştirildikten sonra bazı hizmetler eski veriyi tutarken diğerleri yeni veriyi almış olabilir. Önbellekteki ilgili kayıtlar yenilenene kadar aynı alan adının DNS verisi bir recursive resolver hizmetinde doğrulanırken diğerinde doğrulanamayabilir.
Recursive resolver hizmetleri DNSSEC doğrulama hatalarını kısa süreli önbelleğe alır. RFC 9520, DNSSEC doğrulama hataları dahil çözümleme hatalarının en az 1 saniye ve en fazla 5 dakika önbellekte tutulmasını zorunlu kılar. Bu nedenle yapılandırma düzeltilse bile daha önce hatayı görmüş bir recursive resolver hemen farklı sonuç vermeyebilir; test zamanını ve hizmetin gösterdiği önbellek bilgilerini kaydedin. Hata yanıtı, kalan önbellek süresini her zaman göstermez. Beş dakikalık üst sınır hata önbelleği içindir; DS ve DNSKEY gibi kayıtların kendi önbellek sürelerini belirleyen TTL değerleri farklı olabilir.
DS ve DNSKEY Uyuşmazlığı
Üst bölgedeki DS kaydı, alt bölgenin DNSKEY kaydına güven zinciri kurmak için kullanılır. Anahtar değişimi sırasında eski DS üst bölgede kalmış, onun işaret ettiği DNSKEY alt bölgeden kaldırılmış ve geçerli başka bir doğrulama yolu da kalmamışsa recursive resolver beklenen zinciri tamamlayamaz. Yanlış DS yayımlanması da aynı soruna yol açabilir. Tek bir eski DS kaydının bulunması ise başka geçerli bir güven zinciri kurulabiliyorsa tek başına doğrulama hatası demek değildir.
Bu tür bir uyumsuzluk her kullanıcıda aynı anda görünmeyebilir. Bazı recursive resolver hizmetleri eski DS veya DNSKEY verisini önbellekten kullanırken diğerleri yeni durumu sorgulamış olabilir. Farkın kaynağını anlamak için üst bölgedeki DS ile alt bölgedeki DNSKEY kayıtlarını mümkün olduğunca yakın zamanlarda karşılaştırın.
RRSIG Geçerlilik Süresi ve Recursive Resolver Saati
DNSSEC imzasının yalnız kriptografik olarak doğru olması yeterli değildir; RRSIG kaydındaki başlangıç ve bitiş zamanlarının da doğrulama anına uygun olması gerekir. Süresi dolmuş veya henüz geçerli olmayan bir imza doğrulamada kullanılamaz. Ancak aynı kayıt kümesi başka geçerli bir imzayla doğrulanabiliyorsa tek bir bozuk imza yüzünden bütün yanıtı hatalı saymamak gerekir.
Recursive resolver sisteminin saatinin belirgin biçimde yanlış olması da aynı sonucu doğurabilir. İki recursive resolver farklı davranıyorsa kayıtlarla birlikte doğrulama zamanını ve sistem saatlerinin doğru zamanı gösterip göstermediğini de kontrol edin.
DNS Sorgusunun Geçtiği Ağ ve Ulaştığı Sunucu
DNSSEC doğrulama sonucu yalnız recursive resolver yapılandırmasından kaynaklanmaz. İstemci ile recursive resolver arasında sorguları ileten DNS proxy hizmeti veya yönlendiricideki DNS aracısı sorgu özelliklerini değiştirebilir; recursive resolver ile yetkili DNS sunucusu arasındaki ağ cihazları da büyük DNSSEC yanıtlarını engelleyebilir.
Aynı recursive resolver hizmeti farklı ağlardan kullanıldığında sonuç değişiyorsa ağ yolunu ayrıca incelemek gerekir. Test sırasında sorgunun gerçekten hangi recursive resolver hizmetine ulaştığını, ağ yolunda DNS sorgusunu yeniden işleyen bir ara katman bulunup bulunmadığını ve büyük yanıtların bağlantısız UDP ile bağlantı kuran TCP üzerinden tamamlanıp tamamlanmadığını doğrulayın.
Aynı hizmetin IP adresini kullanmak, aynı sunucu düğümüne ulaşmayı garanti etmez. Aynı IP adresini birden fazla düğümden sunan anycast yapısında farklı ağlardan yapılan sorgular farklı düğümlere gidebilir. Bu düğümlerin önbellekleri de farklı olabilir; ağ yolu ile sunucu tarafındaki farkı birlikte değerlendirin.
DNSSEC Doğrulama Hatasını Karşılaştırmalı Testlerle Ayırma
Çalışan ve çalışmayan iki ortamın aynı kayıt için kontrollü biçimde karşılaştırılması, farkın hangi katmanda başladığını gösterir. Testleri mümkün olduğunca aynı zaman aralığında yapın; alan adının yanı sıra kayıt türünü ve sorgu koşullarını da aynı tutun.
- Kullanılan recursive resolver hizmetini belirleyin. Çalışan ve çalışmayan ağın hangi recursive resolver hizmetine sorgu gönderdiğini kaydedin. Yalnız internet servis sağlayıcısının adını bilmek yeterli değildir; istemci veya uygulama farklı bir DNS hizmeti kullanabilir.
- Aynı ad ve kayıt türünü sorgulayın. Her iki recursive resolver hizmetinde RCODE sonucunu, dönen kayıtları ve sunucunun veriyi doğrulanmış kabul ettiğini bildiren AD bitini karşılaştırın. Bir tarafta SERVFAIL, diğer tarafta normal yanıt görülmesi iki sorgu yolunun farklı davrandığını gösterir; tek başına DNSSEC kanıtı değildir.
- CD biti etkin sorgu ile normal sorguyu karşılaştırın. CD biti, recursive resolver hizmetinden DNSSEC doğrulamasını geçemeyen veriyi de döndürmesini ister. Kullandığınız tanılama aracı bunu destekliyorsa aynı hizmete aynı sorguyu CD bitiyle tekrarlayın; diğer sorgu koşullarını değiştirmeyin. CD biti ayarlanmamış normal sorgu SERVFAIL verirken CD biti etkin sorgu DNS verisini döndürüyorsa DNSSEC doğrulamasında sorun olma olasılığı güçlenir. Ham yanıtı ayrıca doğrulamadan güvenilir kabul etmeyin; bu test DNSSEC yapılandırmasını düzeltmez.
- Üst bölgedeki DS ile alt bölgedeki DNSKEY kayıtlarını karşılaştırın. İlgili DS kaydının işaret ettiği anahtarın alt bölgedeki DNSKEY kümesinde bulunduğunu ve bu anahtarla güven zinciri kurulabildiğini doğrulayın. Birden fazla DS veya anahtar varsa yalnız ilkine bakmayın.
- RRSIG zamanlarını kontrol edin. Sorunlu kayıt kümesini imzalayan RRSIG kayıtlarının başlangıç ve bitiş zamanlarını test anıyla karşılaştırın. Doğrulama için kullanılabilir ve zaman bakımından geçerli bir imza bulunup bulunmadığını denetleyin.
- Önbellek ve ağ yolu farkını ayırın. Aynı recursive resolver hizmetinde sonuç zamanla değişiyorsa önbellek etkisini araştırın. Aynı hizmet farklı ağlarda farklı sonuç veriyorsa sorgu yolunu, ulaşılan sunucu düğümünü, DNS proxy davranışını ve kullanılan taşıma yöntemini karşılaştırın.
SERVFAIL, CD ve AD Bulgularını Birlikte Yorumlama
Tek bir belirti yerine bütün kanıt zincirini değerlendirin. Örneğin yalnız SERVFAIL görmek DNSSEC hatasını kesinleştirmez; aynı hata yetkili sunucuya erişememe veya başka DNS sorunlarında da görülebilir. Buna karşılık CD biti ayarlanmamış normal sorgunun SERVFAIL vermesi, CD biti etkin sorgunun ham yanıtı döndürmesi ve DS-DNSKEY ya da RRSIG kontrolünde somut bir tutarsızlık bulunması çok daha belirleyicidir.
AD bitinin bulunmaması da tek başına “DNSSEC bozuk” anlamına gelmez. AD biti, recursive resolver hizmetinin yanıt verisini ve varsa adın ya da kayıt türünün bulunmadığını gösteren ilgili kanıtları doğrulanmış kabul ettiğini bildirir. İstemcinin bu bilgiyi istediğini belirtmemesi de AD bitinin yanıtta bulunmamasına neden olabilir. İstemci, AD bitini yalnız güvenilir bir recursive resolver hizmetinden güvenli bağlantı üzerinden aldığı yanıtlarda kanıt olarak kullanabilir; AD bitini diğer kayıtlarla birlikte değerlendirin.
DNSSEC Hatasının Kaynağına Göre Düzeltme
Kanıt DS-DNSKEY uyuşmazlığına işaret ediyorsa alan adı yöneticisi, DNS sağlayıcısıyla birlikte üst bölgedeki DS kaydını alt bölgedeki uygun DNSKEY kaydıyla uyumlu hale getirir. Planlı anahtar değişiminde eski anahtarlar ve kayıtlar, geçiş için gerekli önbellek süreleri dikkate alınmadan kaldırılmaz. İmzaların süresi dolmuşsa veya imzalar yanlış zamanla üretilmişse DNS bölgesi yöneticisi imzalama sisteminin saatini ve yenileme işlemini kontrol eder, ardından kayıtları geçerli imzalarla yeniden imzalar. İmzalar doğru olup recursive resolver saati yanlışsa bu kez o hizmetin yöneticisi saati düzeltir. Fark önbellekten kaynaklanıyorsa alan adı yöneticisi önce yetkili kayıtların düzeldiğini doğrular, ardından eski veri veya hata kayıtları için ilgili recursive resolver önbelleklerindeki sürelerin dolmasını bekler.
Ağ yolunda çalışan DNS proxy hizmeti sorguyu değiştiriyor veya büyük DNSSEC yanıtları engelleniyorsa web sunucusunda veya web bağlantısını şifreleyen TLS yapılandırmasında değişiklik yapmak temel nedeni çözmez. Ağ yöneticisi, sorgunun hangi recursive resolver hizmetine ulaştığını, sorgu bayraklarının korunup korunmadığını ve yanıtın UDP ile TCP üzerinden tamamlanıp tamamlanmadığını doğrular.
Düzeltmeyi, önce hata görülen ağlarda DNSSEC doğrulaması açık normal sorgularla yeniden test edin. Doğrulamayı kapatarak alınan yanıt başarı kanıtı değildir. Fark sürüyorsa yalnız beklemek yerine yetkili sunucu verisini, recursive resolver önbelleğini ve sorgunun izlediği yolu yeniden inceleyin.







