DNSSEC, dijital imzalar ve bir güven zinciri aracılığıyla DNS verisinin yetkili kaynaktan geldiğini ve değiştirilmediğini doğrular. Bu denetimi yapan recursive resolver (özyinelemeli DNS çözümleyicisi), güven zincirini doğrulayamadığında sorguya işlemin başarısız olduğunu bildiren SERVFAIL yanıtını verebilir. İşletim ekibi sorunun bir DNSSEC yapılandırma hatasından kaynaklandığını doğrularsa, Negative Trust Anchor (NTA) ile yalnız etkilenen ad ve altındaki adlar için doğrulamayı geçici olarak durdurabilir.

NTA, DNSSEC'i genel olarak kapatan bir ayar değildir. Recursive resolver, NTA kapsamındaki yanıtları doğrulama bakımından imzasız bir bölgeden gelmiş gibi değerlendirir; bu kapsam dışındaki alan adlarında DNSSEC doğrulaması normal biçimde devam eder.

NTA kalıcı bir onarım değildir; sorumlu ekip DNSSEC hatasını düzeltirken etkilenen ada erişimi geçici olarak geri getirir. Alan adı yöneticisi asıl DNSSEC hatasını düzeltmeli, recursive resolver’ı işleten ekip de istisnayı gerekenden uzun tutmamalıdır.

Negative Trust Anchor Nasıl Çalışır?

Negative Trust Anchor ayrı bir DNS kaynak kaydı değildir; recursive resolver üzerinde tanımlanan yerel bir istisnadır. Recursive resolver, NTA'nın tanımlandığı düğümde DNSSEC doğrulama zincirini durdurur; o ad ve altındaki adlardan gelen yanıtları imzasız bir bölgeden gelmiş gibi değerlendirir.

Bu durumda recursive resolver istemciye döndürdüğü yanıtta DNSSEC doğrulamasının başarılı olduğunu gösteren AD (Authenticated Data) bitini ayarlamaz. Daha üst düzey alanlar ve DNS ağacının başka dalları doğrulanmaya devam eder. NTA'nın daha altındaki bir ad için ayrıca trust anchor, yani doğrulamanın güvenilir başlangıç noktası olarak bir DNSKEY veya DS kaydı tanımlanmışsa doğrulama o noktadan itibaren yeniden başlayabilir. DNSKEY açık anahtarı taşır; DS ise üst DNS bölgesinden alt bölgenin anahtarına bağ kuran özeti içerir.

NTA’nın kapsamını dar tutmak, doğrulama dışı kalan ad sayısını sınırlar. Örneğin yalnız sorunlu bir alt alan etkileniyorsa üst alanın tamamı için istisna tanımlamak, DNSSEC koruması dışında kalan kapsamı gereksiz yere genişletir.

NTA Uygulamadan Önce DNSSEC Hatasını Doğrulama

DNSSEC doğrulama hatası tek başına NTA eklemek için yeterli değildir. Aynı belirti yanlış yapılandırmadan kaynaklanabileceği gibi saldırı, yetkisiz DNS değişikliği veya bilerek bozuk bırakılmış bir test alanı nedeniyle de görülebilir.

  1. Doğrulama arızasını teyit edin. Recursive resolver günlüklerindeki nedeni ve DNSSEC verisini birlikte inceleyin. Sunucu saatini, imzaların geçerlilik zamanlarını ve üst bölgedeki DS kaydının alt bölgedeki DNSKEY ile uyumunu kontrol edin; yalnız SERVFAIL görülmesi DNSSEC hatasını kanıtlamaz.
  2. Tutarlılığı inceleyin. Farklı recursive resolver yazılımlarıyla alınan sonuçları ve mümkün olduğunca çok yetkili sunucunun yanıtını karşılaştırın. Tutarsızlık, yazılım farkı veya daha ciddi bir olay ihtimalini araştırmayı gerektirir.
  3. Yanlış yapılandırma ile saldırıyı ayırmaya çalışın. DNS verisinin geçmişini, son değişiklikleri ve yetkili sunucularda görülen kayıtları inceleyin. Kesin ayrım yapılamıyorsa NTA uygulanmamalıdır.
  4. Alan yöneticisiyle iletişim kurmaya çalışın. Meşru yöneticinin alan üzerindeki kontrolünü ve görülen DNSSEC verisini doğrulamak, hatanın bir yapılandırma sorunundan kaynaklandığını anlamaya yardımcı olur.
  5. En dar adı ve süreyi seçin. İstisnayı yalnız hatalı bölüme erişimi geri getirecek kadar dar tutun ve eklerken kaldırılacağı zamanı belirleyin. Ekleme kararını DNSSEC konusunda yetkin bir ekip vermelidir; hata görüldüğünde sistem kendiliğinden NTA oluşturmamalıdır.

NTA Ne Zaman Kullanılmamalı?

NTA, sebebi bilinmeyen her SERVFAIL yanıtının çözümü değildir. DNSSEC hatasının bir saldırı veya ele geçirilme belirtisi olabileceğine dair makul şüphe varsa doğrulamayı devre dışı bırakmak, DNSSEC'in korumasını tam ihtiyaç duyulan anda ortadan kaldırabilir.

  • Arızanın yanlış yapılandırma olduğu doğrulanmamışsa NTA uygulanmamalıdır.
  • DNSSEC doğrulaması bilerek başarısız olacak biçimde yapılandırılmış test alanlarında NTA kullanılmamalıdır; bu alanların başarısız olması testin beklenen sonucudur.
  • IPv4 adresini belirten A, başka bir adı hedef gösteren CNAME veya e-posta sunucusunu belirleyen MX gibi kayıtların içerik hatalarını maskelemek için NTA kullanılmamalıdır.
  • Recursive resolver genelinde DNSSEC doğrulamasını fiilen devre dışı bırakacak kadar geniş ve kalıcı NTA listeleri kullanılmamalıdır.
  • İşletim ekibi NTA’yı kök nedenin düzeltilmesini erteleyen kalıcı bir uygulamaya dönüştürmemelidir.

NTA Ne Zaman ve Nasıl Kaldırılır?

RFC 7646, NTA'nın yalnız sınırlı süre kullanılmasını ve tanımlı süresi dolduğunda otomatik olarak kaldırılmasını gerektirir. Belge, ömrün bir haftayı aşmamasını önerir; işletim ekibi yine de NTA’yı mümkün olan en kısa sürede kaldırmayı hedeflemelidir. Bir haftalık üst sınır önerisi, NTA'yı yedi gün boyunca tutmak gerektiği anlamına gelmez.

İşletim ekibi, NTA etkin kaldığı sürece sorunlu adın DNSSEC doğrulamasını istisnayı uygulamayan bir kontrolle yeniden denemelidir. NTA kullanan recursive resolver’dan normal yanıt alınması, hatanın düzeldiğini göstermez. BIND gibi recursive resolver yazılımları NTA’yı yok sayarak bu denetimi dönemsel olarak yapabilir; bağımsız bir DNSSEC doğrulayıcıyla da kontrol yapılabilir. Yalnız bölgenin genel bilgilerinin tutulduğu SOA kaydını denemek, başka bir addaki bozuk imzanın düzeldiğini kanıtlamaz; başlangıçta başarısız olan ad ve kayıt türü de yeniden doğrulanmalıdır.

Doğrulama tekrar başarılı olduğunda ekip, tanımlı sürenin bitmesini beklemeden istisnayı kaldırmalıdır. Önce bölgede listelenen yetkili DNS sunucuları mümkün olan ölçüde kontrol edilmelidir. Aynı IP adresinin farklı sunucularca kullanıldığı anycast yapılarında veya yük dengeleme arkasında her fiziksel sunucuya ulaşmak mümkün olmayabilir.

NTA kaldırıldığında recursive resolver’ın ilgili ad ve altındaki adlara ait önbellek girdileri de temizlenmelidir; yazılımın bunu otomatik yapıp yapmadığı doğrulanmalıdır. Bu işlem, NTA etkinken doğrulanmadan alınmış verilerin kullanılmasını önler. Diğer recursive resolver’ların ve istemcilerin ayrı önbelleklerini ise temizlemez.

NTA'nın Güvenlik ve İşletim Riskleri

NTA etkin olduğu süre boyunca, kapsadığı adlar için uçtan uca DNSSEC doğrulaması yapılmaz. Bu nedenle NTA etkilenen ada erişimi geri getirebilir, fakat aynı anda o kapsamda DNSSEC'in sahte veya değiştirilmiş DNS verilerini ayırt edip reddetme özelliğini geçici olarak ortadan kaldırır.

NTA kullanımının başlangıç ve bitiş zamanlarını, etkilenen adı, gerekçeyi ve kararı veren ekibi işletim kayıtlarına yazmak, hangi adların hangi dönemde doğrulama dışında kaldığını anlamayı kolaylaştırır. Aynı hata tekrarlanıyorsa NTA’yı sürekli yenilemek yerine asıl DNSSEC yapılandırması yeniden incelenmelidir.

Bazı istemci uygulamaları belirli bir alan için AD biti bekleyebilir veya DNSSEC doğrulamasını kendileri yapabilir. Böyle bir istemci, recursive resolver tarafında NTA uygulanmış olsa bile yanıtı kabul etmeyebilir; NTA bu tür uygulamalar için evrensel bir uyumluluk çözümü değildir.