DNS Spoofing ve Önbellek Zehirlenmesi

Tarayıcınıza bankam.com yazdığınızda, adres çubuğunda doğru ismi görmeniz her şeyin yolunda olduğu anlamına gelmez. O ismi bir IP adresine çeviren DNS altyapısı, tasarımı gereği gelen cevabın gerçekten yetkili sunucudan mı geldiğini sorgulamaz. Doğru soruya makul görünen bir cevap gelirse, çözümleyici onu kabul eder ve önbelleğine yazar. İşte saldırganların istismar ettiği açık tam olarak burada başlar: cevabın kimliği hiç doğrulanmadığı için, gerçek cevaptan önce yetiştirilen sahte bir yanıt, koca bir kullanıcı kitlesini fark ettirmeden zararlı bir sunucuya yönlendirebilir.

Bu yazıda DNS spoofing ve önbellek zehirlenmesi (cache poisoning) saldırılarının kaputun altında nasıl çalıştığını, çözümleyicinin önbelleğine sahte bir kaydın nasıl enjekte edildiğini ve bunun neden bu kadar tehlikeli olduğunu adım adım açıklayacağız. Ardından savunma tarafına geçip kaynak port rastgeleleştirme, DNSSEC ve şifreli DNS gibi yöntemlerle bu saldırıların pratikte nasıl imkânsız hâle getirildiğini, kendi sunucunuzda ve çözümleyicinizde uygulayabileceğiniz somut yapılandırmalarla göstereceğiz. Kıdemli bir sistem yöneticisinin gözünden, "neyi neden yaptığımızı" es geçmeden ilerleyeceğiz.

DNS Neden Bu Kadar Kırılgan Tasarlandı?#

DNS, 1980'lerde internetin çok daha küçük ve daha güvenilir bir yer olduğu bir dünyada tasarlandı. Öncelik hız ve ölçeklenebilirlikti; kimlik doğrulama akla bile gelmedi. Sorgular çoğunlukla bağlantısız ve durumsuz olan UDP protokolü üzerinden gönderilir. Bir özyineli çözümleyici (recursive resolver), yetkili sunucuya bir soru sorar ve dönen ilk geçerli görünen paketi kabul eder.

Bir cevabın "geçerli görünmesi" için birkaç basit kriteri sağlaması yeterlidir. Cevap doğru IP adresi ve porttan geliyor gibi görünmeli, doğru soruyu (aynı alan adı ve kayıt türü) içermeli ve en kritik olarak, sorgunun 16 bitlik işlem kimliğiyle (transaction ID / TXID) eşleşmelidir. Bu TXID, çözümleyicinin gönderdiği her sorguya iliştirdiği rastgele bir sayıdır ve teorik olarak cevabı gerçek sunucuya bağlamalıdır.

Sorun şu ki 16 bit yalnızca 65.536 olası değer demektir. Eğer bir saldırgan çözümleyiciyi belirli bir alan adı için sorgu yapmaya zorlayabiliyorsa, o kısa zaman aralığında farklı TXID'lerle donatılmış binlerce sahte cevabı çözümleyiciye yağdırabilir. Gerçek yetkili sunucu cevabı gelmeden önce, doğru TXID'yi tutturan tek bir sahte paket yeterlidir. Bu "yarış", zehirlenmenin kalbindeki mekanizmadır. DNS'in genel çalışma mantığını tazelemek isterseniz önce DNS önbellek temizleme yazısındaki önbellek kavramına göz atmanız faydalı olur.

DNS Spoofing ve Cache Poisoning Arasındaki Fark#

Bu iki terim sık sık birbirinin yerine kullanılır ama aralarında pratik bir ayrım vardır. Her ikisinin de amacı kullanıcıyı sahte bir cevapla yanlış IP'ye yönlendirmektir; farklılık, sahte cevabın nereye ve ne kadar kalıcı biçimde yerleştirildiğindedir.

DNS spoofing daha genel bir şemsiye terimdir ve "sahte bir DNS cevabı üretmek" anlamına gelir. Bu, kullanıcı ile çözümleyici arasındaki trafiği izleyebilen bir saldırganın (örneğin aynı Wi-Fi ağındaki bir MITM saldırısında) gerçek cevaptan önce sahte bir yanıt göndermesiyle olabilir. Bu durumda etki genellikle tek bir kullanıcıyla ya da tek bir oturumla sınırlıdır; saldırgan trafiği görebildiği sürece geçerlidir.

Cache poisoning (önbellek zehirlenmesi) ise spoofing'in çok daha yıkıcı bir alt türüdür. Burada hedef, tek bir kullanıcı değil, çözümleyicinin önbelleğidir. Sahte kayıt bir kez önbelleğe yazıldığında, o çözümleyiciyi kullanan herkes — belki binlerce kişi — kaydın TTL süresi (yani geçerlilik ömrü) boyunca sahte IP'ye yönlendirilir. Saldırganın artık trafiği izlemesine bile gerek yoktur; zehir çözümleyicinin belleğine yerleşmiştir ve kendi kendine çalışır.

Bu tablodan çıkarılacak en önemli sonuç şudur: cache poisoning, saldırgan hedef ağa fiziksel olarak erişemese bile mümkün olabilir. Sadece çözümleyiciyi belirli bir alan adı için sorgu yapmaya zorlayıp doğru TXID'yi tahmin etmesi yeterlidir. İşte bunu ünlü bir zafiyet üzerinden somutlaştıralım.

Bir Cache Poisoning Saldırısı Adım Adım#

2008'de güvenlik araştırmacısı Dan Kaminsky, cache poisoning'in o güne kadar sanılandan çok daha kolay olduğunu gösteren bir yöntem yayınladı. Kaminsky saldırısı, bugün hâlâ savunmaların neden bu şekilde tasarlandığını anlamak için en iyi örnektir. Mekanizmayı basitleştirerek anlatalım.

Saldırgan bankam.com alan adını zehirlemek ister. Doğrudan bankam.com için tahmin yürütmek yerine, çözümleyiciye var olmayan rastgele alt alan adlarını sordurur. Örneğin aaa123.bankam.com, aaa124.bankam.com gibi. Bu isimler önbellekte olmadığı için çözümleyici her seferinde yetkili sunucuya yeni bir sorgu göndermek zorunda kalır — yani saldırgan tahmin için sürekli yeni "yarışlar" tetikleyebilir.

# Saldırgan, çözümleyiciyi ardı ardına sorgu yapmaya zorlar (kavramsal)
for i in $(seq 1 100000); do
  dig @kurban-resolver.example rastgele$i.bankam.com A &
done

Her sorgu gönderildiği anda, saldırgan çözümleyiciye yönelik sahte cevaplar yağdırır. Bu sahte cevapların dehası, ANSWER bölümündedir değil — asıl zehir AUTHORITY ve ADDITIONAL bölümlerindedir. Sahte cevap şöyle der: "rastgele123.bankam.com diye bir kayıt yok ama bankam.com alan adının yetkili sunucusu (NS kaydı) şu adrestedir ve o sunucunun IP'si de (glue/A kaydı) saldırganın IP'sidir."

;; QUESTION SECTION:
rastgele123.bankam.com.   IN  A

;; AUTHORITY SECTION:
bankam.com.        86400  IN  NS   ns1.bankam.com.

;; ADDITIONAL SECTION:
ns1.bankam.com.    86400  IN  A    203.0.113.66   ; <- saldırganın sunucusu

Eğer bu sahte cevaplardan biri doğru TXID'yi tutturur ve gerçek cevaptan önce yetişirse, çözümleyici artık bankam.com'un tüm alt alan adları için saldırganın sunucusunu yetkili kabul eder. Tek bir alt alan adı değil, koca alan adı zehirlenmiş olur. Kaminsky'nin dâhice noktası, saldırganın bir tahmin tutmazsa hemen yeni bir rastgele isimle yeniden deneyebilmesiydi; klasik saldırılarda ise önbellekteki geçerli kayıt yüzünden saatlerce beklemek gerekiyordu.

Bu senaryoda tek gerçek engel, 16 bitlik TXID'yi tahmin etmektir. O dönemde birçok çözümleyici sabit bir kaynak port kullandığı için tahmin edilecek tek şey buydu ve modern ağ hızlarında saniyeler içinde tutturulabiliyordu. Savunmanın çıkış noktası tam olarak bu tahmin alanını genişletmek oldu.

Bu Saldırı Neden Bu Kadar Tehlikeli?#

Cache poisoning'in gerçek tehlikesi, kullanıcının hiçbir hata yapmamasında yatar. Kurban doğru alan adını yazar, yer imini kullanır, hatta HTTPS'i bekler; ama DNS katmanı sessizce yalan söylediği için tüm bu doğru davranışlar boşa çıkar. Saldırı, kullanıcının gözünden tamamen görünmezdir.

En bilindik senaryo kimlik avı ve kimlik bilgisi hırsızlığıdır. Kullanıcı bankasının ya da e-posta sağlayıcısının adını yazar, saldırganın pikseli piksele aynı klonlanmış sayfasına düşer ve giriş bilgilerini kendi elleriyle teslim eder. Bu, klasik kimlik avından çok daha sinsidir çünkü adres çubuğundaki alan adı gerçektir; kullanıcının şüphelenmesi için görsel bir ipucu yoktur. Kimlik avının genel mantığını ve korunma yollarını ayrıca ele aldığımız içerikler de mevcuttur.

İkinci büyük risk kötü amaçlı yazılım dağıtımıdır. Bir yazılımın güncelleme sunucusu ya da bir paket deposu zehirlenirse, kurbanların sistemleri güncelleme diye zararlı ikili dosyalar indirir. Üçüncüsü, HTTPS'in bile bir noktaya kadar aldatılabilmesidir: Let's Encrypt gibi otomatik sertifika otoriteleri, alan adı sahipliğini DNS ya da HTTP üzerinden doğrular. Saldırgan DNS'i zehirleyip doğrulama trafiğini kendi sunucusuna yönlendirebilirse, hedef alan adı için geçerli bir SSL sertifikası bile çıkarabilir — bu durumda tarayıcıdaki yeşil kilit dahi güvence vermez. İşte bu yüzden DNS güvenliği, aktarım katmanı güvenliği olan SSL sertifikalarıyla birlikte, uçtan uca bir güven zincirinin ayrılmaz parçasıdır.

Son olarak, kurumsal ölçekte bir çözümleyicinin zehirlenmesi, tek bir sahte kayıtla binlerce çalışanı ya da müşteriyi aynı anda etkileyebilir. Bu, saldırının neden "yüksek etki, düşük maliyet" kategorisinde değerlendirildiğini açıklar. Neyse ki bugün elimizde bu saldırıyı pratikte imkânsıza yaklaştıran katmanlı savunmalar var.

Savunma 1 — Kaynak Port Rastgeleleştirme#

Kaminsky sonrası uygulanan ilk ve en yaygın acil önlem, kaynak port rastgeleleştirme (source port randomization) oldu. Mantık basit ama etkilidir: saldırganın tahmin etmesi gereken bilgi miktarını artırarak kör tahmini pratikte imkânsız hâle getirmek.

Klasik çözümleyicilerde saldırgan yalnızca 16 bitlik TXID'yi (65.536 olasılık) tahmin etmek zorundaydı, çünkü kaynak UDP portu sabitti. Kaynak port da rastgeleleştirildiğinde, saldırganın hem TXID'yi hem de ~16 bitlik kaynak portu aynı anda tutturması gerekir. Bu, tahmin alanını yaklaşık 32 bite, yani milyarlarca olasılığa çıkarır. Doğru portu bilmeden gönderilen bir paket çözümleyici tarafından sessizce düşürülür.

Bunu şu şekilde düşünün: TXID tek başına, kilidini bir haftada zorlayabileceğiniz bir kombinasyondu. Kaynak portu eklemek, kilidi milyonlarca yıl sürecek bir kombinasyona dönüştürür. Modern çözümleyiciler (BIND, Unbound, PowerDNS, systemd-resolved) bunu varsayılan olarak yapar. Kendi çözümleyicinizin bunu düzgün uyguladığını DNS-OARC'ın klasik test aracıyla doğrulayabilirsiniz:

# Çözümleyicinizin kaynak port rastgeleleştirmesini test edin
dig +short porttest.dns-oarc.net TXT

# Beklenen çıktı "GREAT" derecesini içermelidir:
# "x.x.x.x is GREAT: 26 queries in ... seconds from 26 ports with std dev ..."

Sonuç GREAT yerine POOR ya da FAIR çıkıyorsa, önünüzdeki bir NAT/güvenlik duvarı portları yeniden yazarak (port derandomization) rastgeleliği bozuyor olabilir. Bu, ağ katmanında düzeltilmesi gereken ciddi bir güvenlik sorunudur. Çözümleyici yazılımının ayarlarında da rastgeleleştirmenin kapatılmadığından emin olun; örneğin Unbound'da varsayılan davranış zaten güvenlidir:

server:
    # 0-0 aralığı = işletim sistemine rastgele kaynak port seçtir (varsayılan, doğru)
    outgoing-port-permit: 0
    # Aşağıdaki gibi sabit bir port ARALIĞINA kilitlemekten kaçının
    # outgoing-port-avoid: "0-32767"

Port rastgeleleştirme kritik bir savunmadır ancak tek başına yeterli değildir. Trafiği doğrudan görebilen bir MITM saldırgan hem TXID'yi hem portu okuyabilir; bu durumda tahmine gerek kalmaz. Bu yüzden rastgeleleştirme, saldırıyı zorlaştıran ama kökten çözmeyen bir katmandır. Kökten çözüm, cevabın kriptografik olarak doğrulanmasıdır.

Savunma 2 — DNSSEC ile Cevapların Doğrulanması#

Port rastgeleleştirme saldırganın işini zorlaştırır; DNSSEC (DNS Security Extensions) ise saldırının temelini ortadan kaldırır. Fikir şudur: her DNS kaydını yetkili sunucunun özel anahtarıyla kriptografik olarak imzalamak, böylece çözümleyicinin gelen cevabın gerçekten yetkili kaynaktan geldiğini ve yolda değiştirilmediğini matematiksel olarak doğrulayabilmesi.

DNSSEC, cevaplara imza kayıtları (RRSIG), doğrulama anahtarları (DNSKEY) ve zinciri üst bölgeye bağlayan bir özet kaydı (DS) ekler. Kökten alan adınıza kadar uzanan bu "güven zinciri" sayesinde, saldırganın ürettiği sahte bir cevap geçerli bir imza taşımadığı için doğrulama yapan çözümleyici tarafından reddedilir. Saldırgan doğru TXID ve portu tutturmuş olsa bile, geçerli bir imza üretemeyeceği için zehir tutmaz. Bir alan adının DNSSEC ile korunup korunmadığını ve imzaların doğrulandığını dig ile kontrol edebilirsiniz:

# DNSSEC imzalarıyla birlikte sorgula ve AD (Authenticated Data) bayrağını ara
dig @1.1.1.1 ornek.com A +dnssec

# Başlıkta "flags: ... ad" görüyorsanız çözümleyici imzayı doğrulamıştır
# ANSWER bölümünde A kaydının yanında bir RRSIG satırı bulunmalıdır

Üst bölgede yayınlanan DS kaydı, zincirin en kritik halkasıdır ve şu biçimdedir:

ornek.com.   3600  IN  DS   12345 13 2 (49FD46E6C4B45C55D4AC69E3F1F5B0E4...)

DNSSEC güçlü bir korumadır ama iki önemli sınırı vardır. Birincisi, şifreleme sağlamaz — cevabın doğruluğunu kanıtlar, gizliliğini değil. İkincisi, yalnızca çözümleyici doğrulama yapıyorsa işe yarar. Neyse ki Cloudflare (1.1.1.1), Google (8.8.8.8) ve Quad9 (9.9.9.9) gibi büyük genel çözümleyiciler varsayılan olarak doğrulama yapar. Kurulum, imzalama sırası ve olası tuzaklar konusunda derinlemesine bilgi için DNSSEC nedir rehberimiz konuyu baştan sona ele alır. En önemli uyarı şudur: yanlış yapılandırılmış bir DS kaydı alan adını doğrulama yapan tüm çözümleyicilerde erişilemez yapabileceği için, anahtar yönetimini otomatikleştiren güvenilir bir DNS sağlayıcısıyla ilerlemek en akıllıcasıdır.

Savunma 3 — Şifreli DNS (DoH, DoT, DNSCrypt)#

DNSSEC "cevap gerçek mi?" sorusunu çözer; ama "bu trafiği aradaki biri görüp değiştirebilir mi?" sorusunu çözmez. İşte bu boşluğu şifreli DNS doldurur. Sizinle çözümleyici arasındaki tüm sorgu-cevap trafiğini şifreleyerek, aynı ağdaki bir saldırganın hem sorguları izlemesini hem de araya sahte cevap enjekte etmesini engeller. Bu, özellikle halka açık Wi-Fi gibi güvensiz ağlarda MITM tabanlı spoofing'e karşı doğrudan bir çözümdür.

Üç yaygın yaklaşım vardır. DNS-over-TLS (DoT) sorguları 853 portunda bir TLS tüneli içinde taşır; ağ yöneticisi trafiğin DNS olduğunu görür ama içeriğini okuyamaz. DNS-over-HTTPS (DoH) ise sorguları 443 portunda normal HTTPS trafiğine karıştırır; bu, ağ düzeyinde DNS'i engellemeyi ya da izlemeyi neredeyse imkânsız kılar. DNSCrypt ise çözümleyiciyle istemci arasında ayrı bir şifreleme ve kimlik doğrulama katmanı ekleyen daha eski ama hâlâ kullanılan bir protokoldür.

Linux tarafında systemd-resolved ile DoT'u etkinleştirmek oldukça basittir:

[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
DNSOverTLS=yes
DNSSEC=yes

Bu yapılandırma iki savunmayı birleştirir: DNSOverTLS=yes trafiği şifreler (gizlilik ve MITM koruması), DNSSEC=yes ise cevabın doğruluğunu kriptografik olarak denetler. Değişikliğin ardından servisi yeniden başlatıp durumunu doğrulayabilirsiniz:

sudo systemctl restart systemd-resolved
resolvectl status | grep -E "DNSOverTLS|DNSSEC|Current DNS"

Şunu vurgulamak gerekir: DNSSEC ve şifreli DNS birbirinin alternatifi değil, tamamlayıcısıdır. DNSSEC bütünlüğü, DoH/DoT gizliliği sağlar. En sağlam kurulum ikisini bir arada kullanır. Bir web sunucusu işletiyorsanız, uygulama sunucularınızın çıkış (upstream) DNS çözümleyicisini de doğrulama yapan ve şifreli bir çözümleyiciye yönlendirmek, arka planda çalışan servislerin de zehirlenmiş kayıtlara düşmesini engeller.

Sunucu ve Uygulama Tarafında Ek Sertleştirme#

Bir hosting ya da sunucu işletiyorsanız, savunma yalnızca son kullanıcının çözümleyicisiyle sınırlı değildir. Kendi kontrolünüzdeki katmanlarda alacağınız önlemler, hem sizi hem müşterilerinizi korur. Aşağıdaki tablo, uçtan uca savunma için hangi katmanda ne yapılabileceğini özetler.

Kendi özyineli çözümleyicinizi işletiyorsanız Unbound gibi modern bir yazılımda birkaç ek sertleştirme seçeneği daha vardır. Özellikle DNS Cookies ve 0x20 (case randomization) tekniği, sorgudaki harflerin büyük/küçük halini rastgeleleştirerek saldırganın tahmin etmesi gereken entropiyi bir kat daha artırır:

server:
    # DNSSEC yanıtı beklendiği halde imzasız gelirse cevabı reddet
    harden-dnssec-stripped: yes
    # Referral kayıtlarının yetki alanı dışına çıkmasını engelle
    harden-referral-path: yes
    # 0x20 — sorgudaki harflerin büyük/küçük halini rastgeleleştir
    use-caps-for-id: yes
    # Kök güven çıpası (DNSSEC doğrulaması için)
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

Bunların ötesinde, yönetilen bir sunucu hizmeti alıyorsanız bu katmanların çoğu sizin için hazır ve güncel gelir. Kendi altyapınızı sertleştirmek yerine bu yükü uzmanlara devretmek isterseniz sunucu yönetimi hizmetimiz DNS ve güvenlik yapılandırmalarını sizin adınıza yürütür; uygulama katmanında ise bir web uygulama güvenlik duvarı (WAF) yanlış yönlendirilen ya da kötü niyetli isteklere karşı ek bir savunma hattı ekler. Alan adı yönetimini DNSSEC destekli modern bir panelle yapmak için alan adı hizmetlerimize, tüm bu katmanların bütünleşik geldiği barındırma çözümleri için hosting paketlerimize göz atabilirsiniz.

Sıkça Sorulan Sorular#

DNS spoofing ile cache poisoning aynı şey mi?#

Tam olarak değildir. DNS spoofing, "sahte bir DNS cevabı üretmek" anlamına gelen genel bir terimdir ve etkisi çoğunlukla tek bir kullanıcı ya da oturumla sınırlı kalır. Cache poisoning ise bu sahte cevabı doğrudan çözümleyicinin önbelleğine yerleştirir; bu durumda o çözümleyiciyi kullanan herkes, kaydın TTL süresi boyunca sahte adrese yönlendirilir. Kısacası cache poisoning, çok daha geniş etkili ve kalıcı olan bir spoofing türüdür.

HTTPS kullanıyorsam DNS zehirlenmesinden etkilenir miyim?#

HTTPS önemli bir koruma katmanıdır ama tek başına yeterli değildir. Bir saldırgan DNS'i zehirleyip alan adı doğrulama trafiğini kendi sunucusuna yönlendirebilirse, hedef alan adı için otomatik bir sertifika otoritesinden geçerli bir SSL sertifikası bile çıkarabilir. Bu durumda tarayıcıdaki kilit simgesi güvence vermez. Ayrıca kullanıcı sertifika uyarısını görmezden gelirse koruma tamamen devre dışı kalır. Bu yüzden HTTPS'i, DNS katmanını koruyan DNSSEC ile birlikte düşünmek gerekir.

Cache poisoning saldırısına uğradığımı nasıl anlarım?#

Belirtiler çoğunlukla sinsidir çünkü alan adı doğru görünür. Yine de birkaç işaret dikkat çekicidir. Tanıdık bir sitede beklenmedik sertifika uyarıları, sizi başka bir alan adına atan yönlendirmeler, bir alan adının farklı ağlardan farklı IP'lere çözülmesi ya da e-posta ve güncelleme servislerinin aniden bozulması şüphe uyandırmalıdır. Şüphelendiğinizde farklı bir çözümleyiciyle dig ornek.com A sonucunu karşılaştırıp yerel DNS önbelleğinizi temizlemek ilk yapılması gerekenlerdendir.

DNSSEC bu saldırıları tamamen durdurur mu?#

DNSSEC, sahte cevapları geçerli bir imza taşımadıkları için reddederek cache poisoning ve spoofing'in temelini büyük ölçüde ortadan kaldırır. Ancak iki koşula bağlıdır. Birincisi, hem alan adının imzalı olması hem de son kullanıcının çözümleyicisinin doğrulama yapması gerekir; doğrulama yapmayan bir çözümleyici imzayı görmezden gelir. İkincisi, DNSSEC trafiği şifrelemediği için gizlilik gerektiren senaryolarda DoH veya DoT ile birlikte kullanılmalıdır. Yani DNSSEC çok güçlü bir katmandır ama bütüncül bir savunmanın parçası olarak en etkilidir.

Ev kullanıcısı olarak kendimi nasıl korurum?#

En pratik adım, DNSSEC doğrulaması yapan güvenilir bir genel çözümleyiciye geçmektir. Cloudflare 1.1.1.1, Quad9 9.9.9.9 ve Google 8.8.8.8 bunların başında gelir. Mümkünse cihazınızda ya da yönlendiricinizde şifreli DNS'i (DoH veya DoT) etkinleştirin; bu, özellikle halka açık Wi-Fi ağlarında araya girme saldırılarını engeller. Ayrıca işletim sisteminizi ve tarayıcınızı güncel tutmak, sertifika uyarılarını asla görmezden gelmemek ve tanıdık olmayan ağlarda hassas işlemlerden kaçınmak temel ama etkili alışkanlıklardır.

Kendi sunucumun çözümleyicisinin güvenli olduğunu nasıl test ederim?#

İki hızlı testle başlayabilirsiniz. Kaynak port rastgeleleştirmesini dig +short porttest.dns-oarc.net TXT komutuyla kontrol edin; sonucun GREAT derecesini içermesi gerekir, POOR çıkması önünüzdeki bir NAT ya da güvenlik duvarının rastgeleliği bozduğunu gösterir. DNSSEC doğrulamasını ise dig @sunucu-ip dnssec-failed.org A gibi bilinçli olarak bozuk imzalı bir alan adıyla test edebilirsiniz; doğrulama yapan bir çözümleyici bu sorguya cevap yerine SERVFAIL döndürmelidir. Bu iki test, temel savunmaların yerinde olup olmadığını hızla ortaya koyar.

Kapanış#

DNS spoofing ve önbellek zehirlenmesi, internetin en eski ve en çok güvenilen ama tarihsel olarak en az korunan katmanlarından birini hedef alır. Saldırının dehası, kullanıcının hiçbir hata yapmamasına rağmen görünmez biçimde yanlış yere yönlendirilebilmesinde yatar. Neyse ki bu tehdit bugün çözümsüz değildir: kaynak port rastgeleleştirme kör tahmini pratikte imkânsıza yaklaştırır, DNSSEC her cevabın gerçekliğini kriptografik olarak kanıtlar ve şifreli DNS trafiği araya girmelere karşı mühürler. Bu üç katman bir arada kullanıldığında, saldırganın elinde tutunacak neredeyse hiçbir dal kalmaz.

Alan adınızı ve sunucunuzu bu savunmalarla donatmak sandığınızdan daha kolay. DNSSEC destekli modern bir DNS paneli için alan adı ve hosting hizmetlerimiz imzalama ile DS kaydı yönetimini tek panelde toplar; sunucu tarafındaki çözümleyici sertleştirme, şifreli DNS ve güvenlik güncellemelerini uzmanlarımıza bırakmak isterseniz sunucu yönetimi ekibimiz bu yükü üstlenir. DNS güvenliğinizi, aktarım katmanını koruyan bir SSL sertifikasıyla birlikte düşünerek ziyaretçilerinize uçtan uca bir güven zinciri sunabilirsiniz.