DNS Sahtekarlığı ve Cache Poisoning’e Karşı Net Koruma Rehberi

Domain sahtekarlığı (domain hijacking) ve DNS cache poisoning (DNS önbellek zehirleme) saldırıları, kullanıcıyı sitenizin yerine sahte bir hedefe yönlendirmeyi amaçlar. Bu tür saldırılar çoğu zaman “bir gün çalışır, sonra aniden bozulur” gibi görünür; kök neden ise DNS çözümleme zincirindeki güven boşluklarıdır. Bu rehberde, saldırıyı engellemek için DNSSEC, servis sağlayıcı seviyesinde RPKI, kullanıcı/istemci tarafında DoH/DoT ve operasyon tarafında kayıt izleme adımlarını pratik biçimde kuracaksınız. Ayrıca hangi sinyallerin sizi uyarması gerektiğini net bir kontrol listesiyle göreceksiniz.

Not: Aşağıdaki adımlar, “tamamen görünmez saldırı” hedeflemez; saldırı yüzeyini azaltır, tespit ve hızlı müdahaleyi belirgin şekilde iyileştirir.

1) Tehdit modelini netleştirin: DNS nasıl “bozuluyor”?

DNS çözümlemesi sırasında saldırganın hedefi genellikle iki parçadır:

DNS kayıtlarının sahteleşmesi: Kullanıcı DNS sorgusu yaptığında, saldırgan yanıtı manipüle edip yanlış IP adresini “doğruymuş gibi” kabul ettirebilir.
Yönlendirme katmanının ele geçirilmesi: Alan adının (domain) kontrolü veya isim sunucusu (nameserver) kayıtları, yetkisiz şekilde değiştirilebilir.

DNS cache poisoning’de kritik nokta şudur: Doğru yanıt gibi görünen sahte yanıt, istemcinin DNS önbelleğine yazılabildiği ölçüde etki büyür. Domain sahtekarlığında ise genellikle alan adı tescil (registrar) hesabı, DNS yönetimi ekranları veya yetki/anahtarlar üzerinden ilerlenir.

Bu iki farklı senaryo için aynı önlem seti yeterli değildir. O yüzden rehberi iki eksen üzerine kuruyoruz:

Kriptografik doğrulama (DNSSEC, RPKI)
Operasyonel gözlem ve hızlı tepki (kayıt izleme, TTL/NS yönetimi, erişim güvenliği)

2) DNSSEC’i etkinleştirin: Yanlış DNS yanıtını “kanıt olmadan” kabul ettirmeyin

DNSSEC (Domain Name System Security Extensions), DNS yanıtlarının imzalı olmasını sağlar. İstemci/çözümleyici (resolver) doğrulama yapabiliyorsa, imzası geçersiz yanıtların önbelleğe yazılması ve “sessizce yanlış yere yönlendirme” etkisi azalır.

DNSSEC’i ne zaman ve nasıl devreye almalısınız?

Alan adınız için DS kaydı yayınlanıyorsa, üst seviye doğrulama zinciri kurulmuş olur.
Uygulamada üç bileşen birlikte düşünülür:
DNSKEY / RRSIG kayıtları (zone içinde)
DS kaydı (genellikle üst seviye; registrar/registry yönetimine bağlı)
Doğrulayan resolver tarafı (bazı sistemlerde otomatik doğrulama yoksa etki sınırlanabilir)

Net kontrol: DNSSEC açıldıktan sonra doğrulama yapabilen resolver’larda alan adınız “secure” olarak işaretlenmelidir.

Sahada doğrulama testi (pratik)

Aşağıdaki komut, DNSSEC doğrulamasının çalışıp çalışmadığını anlamanızı sağlar. (Sistemde dig yüklü olmalıdır.)

dig +dnssec example.com A

Çıktıda ilgilendiğiniz alanlar: - ad (Authenticated Data) bayrağı - RRSIG varlığı - Hata mesajları (servfail/timeout)

DNSSEC sertleştirme önerileri

İmzalama anahtarlarını (key) yönetilebilir sıklıkta döndürün. Bu dönüşüm, yanlış kurulumla “tam tersi” probleme dönüşebileceği için kontrollü yapılmalıdır.
TTL değerlerini DNSSEC sonrası aşırı kısaltmayın; yanlışlıkla sık güncelleme, servis karmaşıklığını artırır.
Cloud tabanlı DNS kullanıyorsanız DNSSEC butonunun sadece “aç/kapat” değil, gerçekten imzalı zone üretip üretmediğini kontrol edin.

3) RPKI ile BGP yönlendirme sahtekarlığını azaltın: “Doğru DNS, yanlış IP” sorununu kapatın

DNSSEC domain adını doğru IP’ye ulaştırmaya yardımcı olur; ancak IP’ye giden yol BGP (Border Gateway Protocol) üzerinden ilerir. Saldırgan, hedef IP bloğunu “daha iyi rota”ymış gibi ilan ettirerek trafiği kendine çekebilir. Burada RPKI (Route Origin Authorization), hangi ASN’in hangi prefix’i duyurabileceğini kriptografik bir doğrulama ile kısıtlar.

RPKI ne sağlar?

Bir prefix için yetkisiz ASN’in route ilan etmesi daha zorlaşır.
Uygulama “tüm internette otomatik durur” gibi düşünülmemelidir; etki, RPKI doğrulaması yapan operatörlerin ve yönlendiricilerin durumuna bağlıdır.

Pratik uygulama yaklaşımı

RPKI genellikle şu şekilde uygulanır: - Siz bir IP bloğu/ASN yönetiyorsanız (ör. kendi colocation’ınız, kendi ASN’iniz), RPKI kayıtlarını oluşturursunuz. - Hosting veya transit sağlayıcı üzerinden hizmet alıyorsanız, sağlayıcınızın RPKI doğrulaması yaptığını teyit edersiniz.

NetKıyas mantığıyla karar ölçütü şudur: - Sağlayıcıdan “RPKI/ROA doğrulaması” yaptığını ve hangi ölçekte uyguladığını yazılı olarak isteyin. - Özellikle iş sürekliliği olan projelerde, “BGP’ye dokunmadan” gerçekleşen yönlendirme saldırılarına karşı bir katman eklenmiş olur.

4) DoH/DoT kullanın: İstemci-çözümleyici arasındaki manipülasyonu azaltın

DoH (DNS over HTTPS) ve DoT (DNS over TLS), DNS sorgularını şifreleyerek üçüncü tarafların (ör. ağ içi saldırganlar, bazı MITM senaryoları) DNS trafiğini görmesini ve manipüle etmesini zorlaştırır.

Hangi noktada fark yaratır?

Aynı kullanıcı bir kafede/kurumsal ağda DNS sorguları yapıyorsa, şifreleme saldırı yüzeyini azaltır.
Kurumsal ortamda sadece belirli resolver’lar kullanılabiliyorsa, DoH/DoT ile sorgular “rastgele” çözümlemeyi azaltır.

Uygulama seçenekleri

Tarayıcı/uygulama düzeyi DoH: Tarayıcının yerleşik ayarı varsa açılır.
İşletim sistemi düzeyi: Bazı resolver istemcileri DoT/DoH destekler.
Kendi resolver’ınızı çalıştırma: İhtiyaç ve operasyon maliyeti artar ama kontrol sizdedir.

Net öneri: - Her ağ/cihaz için tek tek DoH/DoT davranışını test edin. Bazı ağlarda kurumsal politika DoH’yi engelleyebilir ya da sadece belirli uç noktalara izin verebilir.

5) Kayıt izleme (record monitoring): Saldırıyı “önlemenin yanında” erken yakalayın

Kriptografik katmanlar önemlidir; ancak domain sahtekarlığı çoğu zaman erişim güvenliği ve yönetim ekranlarındaki değişiklikler üzerinden yürür. Bu yüzden izleme kritik olur. Ama “her şeyi izleyelim” yaklaşımı pratik değildir. İzlemeyi, saldırının en sık değiştirdiği kayıt türlerine odaklayın.

İzlemeniz gereken DNS kayıtları

Aşağıdaki türlerde değişiklik olursa alarm kurun:

NS (nameserver) değişiklikleri: Domain hijack’in en tipik tetikleyicisidir.
A / AAAA kayıt değişiklikleri: Yanlış IP’ye yönlendirmeyi hemen fark ettirir.
CNAME değişiklikleri: Özellikle CDN/proxy kurulumlarında önemli.
MX ve TXT (SPF, DKIM, DMARC) değişiklikleri: E-posta kimlik doğrulamasında bozulma ya da sahtecilik işareti.
SOA değişiklikleri: Zone yeniden yapılandırma/transfer girişimi.

TTL sinyalini de izleyin

TTL kısa olduğunda değişikliklerin etkisi hızlı yayılır; ama aynı zamanda değişikliklerin hemen yakalanması gerekir. Şu kuralı uygulayın: - “Normalde uzun TTL kullandığımız” domainlerde TTL aniden düşerse alarm verin. - “Normalde kısa TTL” kullanan geçiş senaryolarında (taşıma/plan) bu alarmı planlı değişikliklerle eşleştirin.

İzleme eşiği (threshold) ve aksiyon

Sadece “tespit” değil “aksiyon” planlayın:

NS değişti → hemen registrar panelinde Nameserver durumunu kontrol et
A/AAAA değişti → anlık olarak web servisinin aldığı IP’yi (sunucu logları ve edge/CDN loglarıyla) doğrula
MX/TXT değişti → e-posta akış testleri ve kimlik doğrulama raporlarını kontrol et

6) Operasyonel hardening: DNS cache poisoning’e karşı savunmayı tamamlama

DNSSEC/DoH katmanlarının yanında, cache poisoning etkisini azaltan somut uygulamalar vardır.

Resolver ve client davranışı

Uygulamalarınızın kullandığı resolver’ları standartlaştırın (ör. kurumsal policy ile belirli resolver).
DNS önbellek davranışlarını gözden geçirin:
Çok uzun cache, saldırı etkisini uzatabilir.
Çok kısa cache, trafiği artırır ve maliyeti yükseltebilir.

Net yaklaşım: - Uygulama düzeyinde cache politikasını, servis SLA’nıza göre belirleyin. - Değişiklik dönemlerinde (taşıma, acil failover) TTL düşürme planını önceden tanımlayın.

DNS yönetimi erişim güvenliği

Domain sahtekarlığı çoğu zaman “DNS’yi kim yönetiyor?” sorusundaki zayıflıkla başlar.

Registrar ve DNS paneli hesaplarında MFA (çok faktörlü doğrulama) zorunlu yapın.
DNS yönetiminde rol bazlı erişim (RBAC) kullanın: Her çalışan “tüm alan adlarını” değiştiremeyecek şekilde yetkilendirin.
E-posta ile yapılan onaylar yerine, yüksek riskli işlemlerde ek doğrulama sağlayın.

Sürekli kontrol için kontrol listesi

Aşağıdaki maddeleri haftalık rutine dönüştürün:

[ ] Alan adında son 7 günde NS değişikliği var mı?
[ ] Son 7 günde A/AAAA değişti mi?
[ ] “Beklenen IP” ile “DNS’den çözünen IP” aynı mı?
[ ] DNSSEC doğrulaması “secure” görünüyor mu?
[ ] MX/TXT’de kimlik doğrulama kayıtlarında (SPF/DKIM/DMARC) beklenmeyen değişiklik var mı?

7) Hızlı karar verme: Hangi adım hangi riski azaltır?

Aşağıdaki tablo, korumayı “tek bir cümleyle” eşleştirir.

Önlem	Azalttığı risk	Etki noktası
DNSSEC	Sahte DNS yanıtının doğrulanmadan kullanılmasını	DNS yanıt doğrulama zinciri
RPKI	BGP ile yetkisiz rota ilanı	İnternet yönlendirme (route origin)
DoH/DoT	Ağ içi manipülasyon ve DNS sorgu görünürlüğü	İstemci ↔ resolver arası
Kayıt izleme (NS/A/MX/TXT)	Domain hijack ve yanlış yönlendirme anında tespit	Yönetim/operasyon
TTL planı ve cache politikası	Yanlış yanıtın yayılma süresini kontrol	Çözümleme davranışı

Sonuç: 1 haftada uygulanabilir net plan

Bugün yapılacak en doğru aksiyon, kriptografik doğrulamayı (özellikle DNSSEC) etkinleştirip, eş zamanlı olarak NS/A/MX/TXT değişikliklerini izleyen bir alarm mekanizması kurmaktır. Ardından ağ politikası ve istemci davranışı uygunsa DoH/DoT ile şifreli DNS kullanıma geçin; IP yönlendirme katmanında ise servis sağlayıcınızın RPKI doğrulaması konusunda net yanıt verdiğini teyit edin.

NetKıyas açısından pratik öneri: Önce “tahmin edilebilir hedef” seçin (NS ve A değişiklikleri), sonra alarm + doğrulama rutinini (DNSSEC check ve beklenen IP karşılaştırması) yazılı hale getirin. Böylece saldırı anında yalnızca “fark etmek” değil, aynı dakika içinde doğrulayıp aksiyon alabilirsiniz.