Ad sunucularını değiştirdikten sonra tüm kontrol panellerinde işlem başarılı görünse bile web sitesi erişilemez hâle gelebilir. Alan adı aktiftir, yeni yetkili ad sunucuları beklenen IP adresini döndürür ve web sunucusunda hiçbir değişiklik yapılmamıştır. Buna rağmen DNSSEC doğrulaması yapan DNS çözümleyicileri SERVFAIL yanıtı verir. Sorunun kaynağı çoğu zaman eski DNS sağlayıcısının imzalama anahtarına güvenmeye devam eden DNSSEC delegasyonudur.
Bu incelemeye konu olan olayda normal DNS sorguları başarısız olurken DNSSEC doğrulaması atlandığında aynı sorgular başarılıydı. Üst bölge eski DS kaydını yayımlamaya devam ediyordu, ancak yeni yetkili DNS bölgesi başlangıçta imzalanmamıştı. Yeni bölgeye uygun anahtarın eklenip bölgenin imzalanması, test edilen çözümleyicilerde doğrulanmış yanıtları geri getirdi. Buradan çıkarılacak ders DNSSEC'in kapatılması gerektiği değil; ad sunucularının değiştirilmesi ile DNSSEC güven zincirinin taşınmasının iki ayrı işlem olduğudur.
A kayıtları doğru olsa bile neden SERVFAIL oluşabilir?
DNS iki farklı soruya yanıt verir. A kaydı bir adın hangi IPv4 adresine karşılık geldiğini belirtir. DNSSEC ise doğrulama yapan çözümleyicinin bu yanıta güvenip güvenemeyeceğini belirler. Adres bilgisinin doğru olması, DNSSEC güven zincirinin de geçerli olduğu anlamına gelmez.
DNSSEC ile imzalanmış bir alan adında güven zinciri, güvenilen üst bölgeden bir DS (Delegation Signer) kaydı aracılığıyla alt bölgedeki DNSKEY kaydına uzanır. Alt bölge, DNS verileri için imzalar (RRSIG kayıtları) yayımlar. DS kaydı, yetkilendirilmiş bir DNSKEY'i tanımlayan özet değeri içerir; bu kayıt ne bir A kaydıdır ne özel anahtarın kopyasıdır ne de sıradan bir DNS bölgesi düzenleyicisindeki bir ayardır.
Yetkili ad sunucuları değiştirildikten sonra üst bölge eski imzalayıcıya ait DS kaydını yayımlamayı sürdürebilir. Yeni bölgede buna karşılık gelen DNSKEY ve imzalar yoksa doğrulama yapan çözümleyici güven zincirini tamamlayamaz. Böyle bir durumda doğrulanmamış adresi döndürmek yerine yanıtı genellikle geçersiz kabul eder ve SERVFAIL verir.
Bu, bir HTTP kesintisinden farklıdır: istek web sunucusuna hiç ulaşmayabilir. Süresi dolmuş bir TLS sertifikasıyla da aynı şey değildir. DNSSEC DNS verilerini doğrularken HTTPS, daha sonra tarayıcı ile sunucu arasında kurulan bağlantıyı korur.
DNSSEC sorununu eksik kayıttan ayıran tanılama yöntemi
En açıklayıcı test, aynı çözümleyiciye aynı ad için iki sorgu göndermektir. Önce normal bir sorgu yapın ve yalnızca yanıta değil, durum koduna da bakın:
dig example.com A +noall +comments +answerArdından DNSSEC Checking Disabled (CD) biti ayarlanmış olarak sorguyu yineleyin:
dig example.com A +cdflag +noall +comments +answerGözlemlenen arızada normal sorgu SERVFAIL döndürürken CD bitiyle yapılan sorgu beklenen A kaydını döndürdü. Bu fark, eksik DNS kaydından veya yanıt vermeyen bir uygulamadan çok DNSSEC doğrulamasında sorun olduğunu güçlü biçimde gösteriyordu. +cdflag seçeneği, bu özelliği destekleyen özyinelemeli çözümleyiciden söz konusu sorgu için olağan DNSSEC doğrulamasını yapmamasını ister. Bu bir tanılama aracıdır; tarayıcı tarafında sorunu düzeltmez ve ziyaretçiler için DNSSEC'i kapatmaz.
+short ile alınan boş bir yanıttan fazla sonuç çıkarmayın. Hem yanıt kaydının bulunmaması hem de SERVFAIL bu gösterim biçiminde boş görünebilir. Tanılama sırasında +comments seçeneğini koruyun ki status: SERVFAIL ve status: NOERROR bilgileri görünsün.
CD karşılaştırması tek başına DNSSEC'in hangi bileşeninin başarısız olduğunu göstermez; sonraki incelemenin nereye odaklanması gerektiğini gösterir. Çözümleyicide geçici bir üst sunucu hatası da olabilir. Bu nedenle gerektiğinde testi yineleyin ve üst bölgedeki delegasyonu inceleyin.
Yalnızca DNS düzenleyicisini değil, üst bölgedeki DS kaydını da inceleyin
Alan adının DS kayıtlarını sorgulayın:
dig example.com DS +noall +comments +answerDelegasyon yolunu daha ayrıntılı görmek için DNS hiyerarşisini doğrudan sorgulayın:
dig +trace example.com DSÜst bölgenin hangi yetkili ad sunucusuna sahip olduğu, üst düzey alan adına göre değişir. Önemli olan DNS barındırma panelinde görünen özet değil, üst bölgenin gerçekten yayımladığı DS kayıt kümesidir. Alan adı kayıt kuruluşunun değiştirilmesi ad sunucuları aynı kalırken gerçekleşebilir; ad sunucuları da kayıt kuruluşu değişmeden taşınabilir. Her iki durumda da üst bölgedeki DS, etkin yetkili DNS bölgesiyle uyumlu olmalıdır.
DS kaydının dört önemli alanı vardır: anahtar etiketi, algoritma, özet türü ve özet değeri. Anahtar etiketi sorun giderirken kullanışlı bir işarettir, fakat tek başına DNSKEY'in eşleştiğini kanıtlamaz. Özet ve algoritma bilgileri de yetkili bölgenin gerçekten sunduğu anahtara karşılık gelmelidir.
Bu vakada belirleyici durum açıktı: üst bölge eski DNSSEC güven bilgilerini yayımlamayı sürdürürken yeni yetkili DNS bölgesinin yönetim arayüzü imzalamanın etkin olmadığını bildiriyordu. A kayıtları mevcuttu ve doğrulama atlandığında alınabiliyordu. Uygulama yapılandırmasını değiştirmek veya aynı A kaydını tekrar tekrar düzenlemek bu uyumsuzluğu gidermezdi.
Bozulmuş DNSSEC delegasyonunu düzeltmenin iki yolu
İki geçerli kurtarma stratejisi vardır. İkisi de aynı güven zinciri uyumsuzluğunu çözer, ancak işletim açısından farklı sonuçlar doğurur. Birini bilinçli olarak seçin; rastgele birinden diğerine geçmeyin.
Seçenek 1: Eski DS kaydını kaldırıp geçici olarak imzasız çalışmak
Mevcut alan adı kayıt kuruluşundan veya kuruluşun desteklediği DNSSEC yönetim arayüzünden üst bölgedeki güncelliğini yitirmiş DS kaydını kaldırmasını isteyin. Üst bölge artık güvenli bir delegasyon bildirmediğinde, doğrulama yapan çözümleyiciler imzasız alt bölgeyi geçersiz değil, güvenli olarak doğrulanmayan bir bölge olarak değerlendirebilir. DNS çalışmaya devam eder; ancak alan adı için DNSSEC kimlik doğrulaması geçici olarak devre dışı kalır.
Üst bölgedeki DS kayıt kümesini güvenilir biçimde değiştirmek mümkünse bu genellikle daha basit acil durum seçeneğidir. Önceden önbelleğe alınmış DS kayıtları özyinelemeli çözümleyicilerin önbelleğinden düşene kadar mevcut imzalama yapılandırmasını değiştirmeyin. DS kaydının kontrol panelinden kaldırılması tek başına yeterli kanıt değildir: üst bölgedeki kaydı dışarıdan doğrulayın ve TTL süresini hesaba katın. HTTPS, DNSSEC ayarından bağımsızdır. Bu geçici imzasız geçiş RFC 8078 belgesinde de açıklanır.
Seçenek 2: Yeni bölgeyi imzalayıp eşleşen DS kaydını yayımlamak
Diğer yöntem, yeni yetkili DNS sağlayıcısında DNSSEC'i etkinleştirip DNSKEY anahtarlarını üretmek, bölgeyi imzalamak ve karşılık gelen DS kaydını üst bölgede yayımlamaktır. Böylece doğrulama yapan çözümleyici, yeni DNSKEY'e uzanan güvenilir bir yol oluşturup A kaydını doğrulayabilir.
Gerçekte gözlemlenen kurtarma bu yöntemle gerçekleşti. DNS yönetim arayüzü, anahtarları oluşturduğunu, bölgeyi imzaladığını ve yeni bir DS kaydı yayımladığını bildirdi. Daha sonra üst bölgeye gönderilen sorguda yeni DS kaydı eski kayıtla birlikte göründü. DNSSEC doğrulaması yapan özyinelemeli çözümleyiciler beklenen A kaydını döndürmeye başladı; sonraki bir testte ayrıca NOERROR durumuyla birlikte ad bayrağı görüldü. Bu bayrak, ilgili çözümleyicinin veriyi doğruladığını gösteriyordu.
İşlemlerin sırası önemlidir: yayımlanan DS kaydı ancak ona karşılık gelen DNSKEY ve geçerli imzalar yetkili DNS hizmetinde zaten sunuluyorsa işe yarar. Kontrol panelinin “yayımlandı” demesi dışarıdan doğrulamanın yerini tutmaz. Önbelleğe alınmış DS, DNSKEY, RRSIG ve NS kayıtları, farklı çözümleyicilerin farklı zamanlarda düzelmesine neden olabilir.
İki DS kaydı neden sitenin bozuk kalmasına yol açmadı?
Şaşırtıcı sonuçlardan biri, üst bölgede geçici olarak hem eski hem de yeni ve geçerli DS kaydı bulunmasına rağmen DNSSEC doğrulamasının başarılı olmasıydı. Bu bir çelişki değildir. DS kayıt kümesi, anahtar geçişlerinde sıkça olduğu gibi, birden fazla kayıt içerebilir. Doğrulayıcı her DS kaydının şu anda kullanılabilir bir anahtara işaret etmesini şart koşmaz; uygun bir DS kaydından DNSKEY'e ve geçerli imzalara ulaşan tek bir geçerli doğrulama yolu yeterlidir. RFC 6840, doğrulayıcıların tek bir geçerli yolu kabul etmesi gerektiğini açıklar.
Bu, eski anahtarların sonsuza kadar tutulmasının iyi olduğu anlamına gelmez. Güncelliğini yitirmiş DS kaydı yönetim sırasında belirsizlik yaratır; yeni güven zinciri doğrulandıktan sonra kaldırılmalıdır. Ancak doğrulanmış DNS sorguları artık başarılıyken eski kaydın temizlenmesi, yeni ve riskli bir DNSSEC sıfırlaması yapmak için gerekçe değildir; yalnızca bakım işlemidir.
Burada özellikle tehlikeli bir kontrol paneli tuzağı vardır: “DS'yi acil durumda yayından kaldır” gibi adlandırılmış bir işlem, çalışan yeni kayıt da dâhil olmak üzere tüm DS kayıtlarını kaldırabilir. Benzer şekilde, üst bölgede DS kaydı hâlâ yayımlanırken bölge imzalamasını kapatmak kesintiyi hemen yeniden başlatabilir. Bu işlemlerin hiçbiri yalnızca tek bir eski DS kaydını silmekle aynı şey değildir. Arayüz belirli bir kaydı seçmeye izin vermiyorsa toplu sıfırlama yerine kayıt kuruluşunun desteklediği seçici değiştirme yöntemini kullanın.
Yetkili ad sunucuları güvenli biçimde nasıl değiştirilir?
En güvenli sıra, eski ve yeni DNS sağlayıcılarının anahtarları birlikte yönetip yönetememesine bağlıdır. Geçici imzasız dönem kullanılan standart bir taşımada, aşağıdaki sıra bu olayda yaşanan uyumsuzluğu önler:
- Önce hedef bölgeyi hazırlayın. Gerekli A, AAAA, CNAME, MX, TXT ve diğer ilgili kayıtları kopyalayın. Delegasyonu değiştirmeden önce yeni yetkili ad sunucularını doğrudan sorgulayarak test edin.
- Üst bölgedeki DNSSEC durumunu inceleyin. DS kaydı bulunup bulunmadığını ve bunları kimin değiştirebildiğini belirleyin. DNSSEC'i daha önce elle etkinleştirmemiş olsanız bile bu kontrolü yapın; bazı DNS hizmetleri imzalamayı otomatikleştirir.
- Eski imzalı bölge çalışırken eski DS kaydını kaldırın. Değişikliği yetkili üst bölgeden doğrulayın, ardından önbellekteki eski DS verilerinin süresinin dolmasını bekleyin. Bekleme süresini evrensel ve sabit bir dakika sayısı değil, gözlemlenen TTL değerleri belirler.
- Ad sunucusu delegasyonunu değiştirin. Önbelleğe alınmış NS delegasyonları hâlâ eski sunucuları gösterebileceğinden eski yetkili DNS hizmetini çalışır durumda tutun. Üst bölgenin NS TTL değerlerini hesaba katın ve farklı çözümleyicilerin gerçekte hangi sunucuları kullandığını doğrulayın.
- DNSSEC'i yeniden etkinleştirip etkinleştirmeyeceğinize karar verin. Yeni hizmet imzasız kalacaksa DS kaydı yayımlamayın. İmzalı olacaksa eşleşen DS kaydını yayımlamadan önce yeni DNSKEY ve imzaların doğru sunulduğunu doğrulayın. Eski NS kayıtlarının önbellekte kalma süresini de dikkate alarak bu adımı planlayın; aksi hâlde yeni bir doğrulama uyumsuzluğu oluşabilir.
- Bağımsız doğrulama yapın. Üst bölgedeki DS kaydını, yetkili DNSKEY kaydını, normal özyinelemeli DNS çözümlemesini ve doğrulayıcı çözümleyicilerin kimliği doğrulanmış yanıtlarını kontrol edin.
DNSSEC korumasının kesintisiz sürmesi gerekiyorsa imzasız dönem yerine açıkça koordine edilmiş bir anahtar geçişi veya çoklu imzalayıcı geçişi tercih edilmelidir. Bunun için iki DNS sağlayıcısının da gerekli anahtar ve imzalama düzenini desteklemesi gerekir; eski DS özetini yeni sağlayıcıya kopyalamak tek başına anahtar geçişi değildir.
Taşıma sonrası kısa doğrulama listesi
DNSSEC ile ilgili her değişiklikten sonra hem DNS kayıtlarını hem de çözümleyicilerin bunları kabul ettiğini gösteren kanıtları kontrol edin:
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answerKimliği doğrulanmış yanıtı kontrol etmek için DNSSEC doğrulaması yapan özyinelemeli bir çözümleyici kullanın. Yanıtta NOERROR ile beklenen A kaydının bulunması, DNS çözümlemesinin başarılı olduğunu gösterir. Buna ek olarak ad bayrağı varsa çözümleyici, kendi DNSSEC politikasına göre yanıtı doğruladığını bildiriyordur. ad bayrağının olmaması tek başına hata kanıtı değildir; çözümleyicilerin yetenekleri, politikaları ve sorgu bayrakları farklılık gösterir. Kesinti sırasında DNSKEY sorguları doğrulayıcı çözümleyiciden başarısız dönüyorsa incelemenin bir parçası olarak etkin yetkili DNS hizmetini doğrudan sorgulayın.
Tek bir çözümleyiciden başarılı yanıt almakla yetinmeyin. Farklı önbelleklerde bir süre farklı delegasyonlar ve anahtarlar bulunabilir. Açık bir teknik destek talebiniz varsa onu da güncelleyin: tüm DS kayıtlarını kaldırma yönündeki eski talimat, çalışan yeni DS kaydı yayımlandıktan sonra tehlikeli hâle gelir. Takip mesajında etkin anahtarın korunmasını açıkça belirtin ve gerekiyorsa yalnızca eski kaydın kaldırılmasını isteyin.
Arıza, web sunucusunun adresinin yanlış olmasından kaynaklanmıyordu. DNS yanıtlarının sunulduğu yer değiştirilmiş, ancak çözümleyicilere hangi yanıtlara güvenmeleri gerektiğini söyleyen güven bilgileri önceden uyumlu hâle getirilmemişti. Bu yüzden her ad sunucusu geçişinden önce sorulması gereken pratik soru şudur: Üst bölge hangi DS kayıtlarını yayımlıyor ve hedef bölgenin DNSKEY ile imzaları bu kayıtları doğrulayabiliyor mu?