DNS yapılandırma hataları, bir alan adının yanlış sunucuya çözülmesine veya hiç çözülememesine neden olabilir. Yetkili DNS bölgesindeki yanlış, eksik ya da artık kullanılmayan kayıtlar yüzünden kullanıcılar doğru alan adını yazsa bile hizmete erişemeyebilir veya beklenmeyen bir hedefe bağlanabilir.

Güvenlik etkisi yalnız erişim kesintisi değildir. Bir alan adını başka bir ada bağlayan CNAME kaydı sahipsiz kaldığında alt alan üçüncü bir tarafça ele geçirilebilir; bunun mümkün olup olmadığı hedef hizmetin kurallarına bağlıdır. DNS verisini imzalarla doğrulayan DNSSEC ve sertifika verebilecek kuruluşları kısıtlayan CAA kayıtlarındaki hatalar da doğrulama veya sertifika yenileme sorunları oluşturabilir. Her DNS hatası saldırı anlamına gelmez; yanlış hedef, doğrulama hatası ve erişim kesintisi ayrı ayrı incelenmelidir.

Yetkili DNS Bölgesindeki Hatalar Neden Geniş Etki Yaratır?

Yetkili DNS sunucuları, alan adı için yönetici tarafından yayımlanan kayıtları sunar. Buradaki bir hata, tek bir cihaz ayarından farklı olarak, kaydı sorgulayıp önbelleğe alan çok sayıda recursive resolver (özyinelemeli DNS çözümleyicisi) hizmetine aynı yanlış bilgiyi ulaştırabilir. TTL, kaydın normal önbellek kullanım süresini saniye cinsinden belirtir. Kayıt düzeltilse bile daha önce önbelleğe alınmış yanıtlar bu süre boyunca kullanılabilir; bazı DNS hizmetleri yeni yanıt alamadığında özel kurallarla süresi dolmuş veriyi de sunabilir.

Yanlış Hedefe Yönlenen Kayıtlar

Sırasıyla IPv4 ve IPv6 adresi taşıyan A ve AAAA kayıtları yanlış bir IP adresini gösterdiğinde alan adı başka bir sunucuya, kapatılmış bir altyapıya veya aynı IP adresinde çalışan beklenmeyen bir web hizmetine ulaşabilir. CNAME kaydı yanlış alan adını gösterdiğinde çözümleme o hedef üzerinden devam eder. Sonuç, sertifika adı uyuşmazlığından yanlış içerik sunumuna veya tamamen erişim kaybına kadar değişebilir.

Bu durum otomatik olarak saldırı kanıtı değildir. Önceki bir dağıtımdan kalan kayıt, hatalı kopyalama, eksik nokta kullanımı, yanlış bölge adı veya değişiklik sırasında güncellenmeyen ikincil sunucu da aynı belirtiyi oluşturabilir. DNS yöneticisi önce yetkili sunucuların verdiği yanıtları, ardından hedef altyapının gerçekten kuruluşun denetiminde olup olmadığını kontrol etmelidir. Sertifika uyarısını aşarak devam etmek, bu incelemenin güvenli bir yolu değildir.

Sahipsiz CNAME ve Alt Alan Sahiplenme Riski

Sahipsiz DNS kaydı, DNS'te kalmayı sürdürürken işaret ettiği bulut kaynağı, barındırma hizmeti veya alan adı kuruluşun denetiminden çıkmış kayıttır. CNAME hedefi yeniden kaydedilebiliyor veya ilgili hizmette başka bir hesap tarafından sahiplenilebiliyorsa saldırgan alt alanın çözümlemesini kendi içeriğine yönlendirebilir.

Hedefi artık kuruluşa ait olmayan her CNAME kaydı kötüye kullanılamaz; ilgili hizmetin sahiplik doğrulaması ve hedef kaynağın yeniden tahsis kuralları sonucu belirler. Hizmeti kapatan ekip önce DNS kaydını kaldırmalı veya denetimindeki başka bir hedefe almalıdır. Değişiklik yetkili sunucularda doğrulandıktan sonra eski kaydın TTL süresini hesaba katmalı, önbellekten eski hedefe ulaşan istekler için geçiş süresi bırakmalı ve ancak bundan sonra eski kaynağı serbest bırakmalıdır. Tek bir DNS sorgusunda kaydın görünmemesi, bütün önbelleklerin temizlendiğini kanıtlamaz. Hizmetin yeniden sahiplenmeyi engelleyen doğrulama kaydı varsa bunu sırf eski göründüğü için silmeyin; hizmetin koruma koşullarını kontrol edin.

Delegasyon ve Yetkili Sunucu Tutarsızlıkları

Yetkili DNS sunucularının adlarını taşıyan NS kayıtları, üst bölgedeki yetki devrinde ve bölgenin kendi kayıtlarında uyumlu olmalıdır. Delegasyonda adı bulunan bir sunucu ilgili bölge için yetkili değilse bu durum lame delegation olarak adlandırılır. Bazı sorgular doğru sunucuya ulaşırken diğerleri yanıtsız kalabilir veya sunucu tarafından reddedilebilir. Yetkili olmayan yanıt, tek başına sahte yanıt demek değildir; önemli olan, yönlendirilen sunucunun beklenen bölgeyi yetkili olarak sunabilmesidir.

Risk yalnız kesintiyle sınırlı kalmaz. Bir alt alan eski bir DNS hizmetine delege edilmiş ve hizmet sonlandırıldığı halde üst bölgedeki delegasyon kaldırılmamışsa ilgili hizmetin sahiplik kontrollerine bağlı olarak başka bir hesap aynı alt alanı hizmete tanımlamayı deneyebilir. Bir alt alanın DNS hizmeti kapatılırken üst bölgedeki delegasyon önce kaldırılmalı veya yeni hizmete geçirilmelidir. Eski delegasyonun önbelleklerde kullanılabileceği süre dolmadan eski DNS hizmetini başka bir hesabın sahiplenebileceği biçimde serbest bırakmayın.

İkincil sunucuların güncel bölgeyi alması da önemlidir. Bölge seri numarasının artırılmaması, aktarımın başarısız olması veya farklı yönetim panellerinde bağımsız değişiklik yapılması, yetkili sunucular arasında kayıt sapmasına neden olabilir. DNS Sağlık Kontrolü aracında alan adını sorgulayarak delegasyon ve yetkili sunucu tutarsızlıklarını inceleyebilirsiniz; bulguları DNS yönetimindeki beklenen sunucu listesiyle karşılaştırın.

DNSSEC Hataları Neden Erişimi Engelleyebilir?

DNSSEC doğrulamasındaki uyumsuzluklar, bir recursive resolver hizmetinin DNS yanıtını kabul etmesini engelleyebilir. DS kaydı, üst bölgeden alt bölgenin anahtarına güven bağlantısı kurar; DNSKEY açık anahtarları, RRSIG ise kayıt imzalarını taşır. Doğrulama yalnız bu kayıtların birbirini tutmasına değil, önceden güvenilen bir anahtardan başlayan doğrulanabilir zincire ve geçerli imzalara dayanır.

Yanlış DS kaydı, eksik DNSKEY, süresi dolmuş imza veya hatalı anahtar geçişi doğrulayan recursive resolver hizmetlerinin yanıtı geçersiz saymasına yol açabilir. Bu durumda DNS verisi doğru sunucuda bulunsa bile kullanıcı siteye erişemeyebilir. DNS yöneticisi DNSSEC değişikliklerini yalnızca bir kayıt eklemekten ibaret görmemeli; üst ve alt bölge eş güdümünü, imza sürelerini ve geri dönüş planını birlikte yönetmelidir.

Geçerli DNSSEC imzası, kaydın doğru hizmeti gösterdiğini veya hedef web sitesinin güvenilir olduğunu kanıtlamaz. DNS yönetiminde yanlış bir kayıt yayımlanıp geçerli biçimde imzalanmışsa imza denetimi başarılı olabilir. Bu nedenle kayıt değerleri ve DNS yönetim hesabının güvenliği de incelenmelidir.

CAA Kayıtları Sertifika Yetkisini Nasıl Etkiler?

CAA kaydı, alan adı için sertifika düzenleyebilecek sertifika otoritelerini kısıtlayabilir. Doğru kullanıldığında istenmeyen sertifika düzenleme riskini azaltan ek bir kontroldür. Hatalı yazılan ya da kuruluşun kullandığı sertifika otoritesini dışlayan bir CAA politikası yeni sertifika alınmasını veya otomatik yenilemeyi engelleyebilir. Uygulanacak politika belirlenirken takma adlar ve gerektiğinde üst alan adları da kontrol edilir; yalnız incelenen adda CAA bulunmaması, kısıt bulunmadığını göstermez.

CAA, tarayıcının mevcut sertifikayı doğrulamasının yerine geçmez ve HTTPS bağlantısını tek başına kurmaz. DNS yöneticisi, sertifika verilmeden önce denetlenecek CAA politikasını kullanılan sertifika otoritesi ve yenileme ayarlarıyla karşılaştırmalıdır. CAA değişikliği daha önce verilmiş sertifikayı kendiliğinden iptal etmez.

DNS Hatalarının E-posta ve Diğer Hizmetlere Etkisi

Yetkili bölgedeki kayıtlar yalnız web hizmetlerini etkilemez. Posta teslim hedefini belirten MX kaydı yanlışsa e-posta hatalı sunucuya gidebilir veya teslim edilemeyebilir. SPF, e-posta aktarımında kullanılan alan adı için gönderime izin verilen sunucuları bildirir; DKIM ileti imzasının doğrulanmasını sağlar. DMARC, SPF ve DKIM sonuçlarını görünen gönderen alan adıyla ilişkilendirir ve doğrulama başarısız olduğunda istenen işlemi belirtir. Metin verisi taşıyan TXT kayıtlarında SPF ve DMARC politikaları ile DKIM açık anahtarı yayımlanır. Bu verilerdeki biçim ya da kapsam hataları meşru iletilerin reddedilmesine veya gönderen doğrulamasının zayıflamasına neden olabilir.

Gereksiz TXT kayıtları, eski doğrulama belirteçleri ve kullanılmayan hizmet kayıtları da bölgenin yönetimini zorlaştırır. Her kaydın sorumlu ekibi, amacı, hedef hizmeti ve kaldırma koşulu bilinmediğinde ekipler kaydın güvenle silinip silinemeyeceğini belirlemekte zorlanır. Kayıtların ne zaman güncelleneceği veya kaldırılacağı, bağlı hizmetlerin durumuna göre belirlenmelidir.

Değişiklik Kontrolü ve Kayıt Envanteri

DNS yapılandırma güvenliği, düzenli ve izlenebilir bir yönetim süreci gerektirir. Bu süreç şu adımları içerir:

  1. Yetkili bölgelerdeki A, AAAA, CNAME, NS, MX, TXT, CAA, DS ve DNSKEY kayıtlarını envantere alın.
  2. Her kaydın sorumlu ekibini, bağlı olduğu hizmeti, oluşturulma nedenini ve kaldırma koşulunu kaydedin.
  3. Bulut, CDN, barındırma veya doğrulama hizmeti kapatılırken bağlı DNS kayıtlarının hangilerinin değişeceğini, silineceğini veya sahiplik koruması için kalacağını belirleyin.
  4. Değişiklikleri yetkili sunucuların tamamında doğrulayın; yalnız yönetim panelindeki görünüme güvenmeyin.
  5. DNSSEC, delegasyon ve sertifika yenilemesi gibi bağımlı işlemler için geri dönüş ve izleme planı hazırlayın.

Düşük TTL, yeni kayıtların daha sık alınmasını sağlayabilir fakat hatalı kaydı düzeltmez. TTL değişikliğini önceden planlayın; önbelleğe daha önce alınmış bir kaydın kalan süresi, yetkili sunucudaki TTL değeri düşürüldüğünde kısalmaz. Çok kısa değerlerin sorgu yükünü artırabileceğini ve TTL hesabının bütün eski yanıtların kaybolduğunu tek başına kanıtlamadığını da hesaba katın.

TLS, Web Sunucusu ve Uygulama Güvenliği

DNSSEC, DNS sorgularını şifrelemez ve HTTPS'nin yerini tutmaz. HTTPS bağlantısında TLS, sunucu kimliğinin sertifikayla doğrulanmasını ve web verisinin aktarım sırasında şifrelenmesini sağlar. Geçerli sertifika ve doğru DNS kayıtlarının yanında güncel sunucu yazılımı, erişim kontrolü, güvenli uygulama kodu, yedekleme ve izleme de gerekir; DNS denetimi bu kontrollerin yerine geçmez.