DNS Cookies, DNS sorgu ve yanıtlarında tahmin edilmesi güç değerleri kullanarak sahte kaynaklı sorgulara ve bazı sahte yanıtlara karşı ek kontrol sağlayan yöntemdir. Değerler, DNS iletilerine ek seçenekler taşıyan EDNS (Extension Mechanisms for DNS) mekanizmasının COOKIE seçeneğinde bulunur; web sitelerinin tarayıcıya bıraktığı oturum veya tercih çerezleriyle bağlantılı değildir.

DNS trafiği UDP üzerinden taşındığında sorgu ve yanıt için bağlantı kurulmaz. UDP, veriyi ayrı paketler halinde gönderir ve karşı tarafla önceden bağlantı kurarak adresi doğrulamaz. Bu nedenle saldırganın kaynak IP adresini sahte göstermesi veya istemcinin beklediği yanıta benzeyen sahte bir paket göndermesi gibi risklere karşı tek başına yeterli doğrulama sağlamaz.

DNS Cookies sorguyu ya da yanıtı şifrelemez, tarafların gerçek kimliğini güçlü biçimde kanıtlamaz ve ağ yolundaki saldırgana karşı koruma sağlamaz. Mekanizma, sunucuya sorgunun görünen kaynak adresiyle daha önce iletişim kurulduğuna dair ek bir işaret verir. İstemci tarafında da iki uç arasındaki trafiği göremeyen off-path attacker'dan (ağ yolu dışındaki saldırgandan) gelen bazı sahte yanıtların ayırt edilmesine yardımcı olur.

DNS Cookies Alışverişi Nasıl Çalışır?

Client Cookie (istemci çerezi) ile Server Cookie (sunucu çerezi) parola, kullanıcı adı veya hesap bilgisi değildir. İstemci her DNS sunucusu IP adresi için ayrı bir değer üretir. Sunucu ise kendi gizli verisini ağda göndermeden, istemci çerezi ile sorgunun geldiği IP adresine bağlı bir sunucu çerezi hesaplar. Böylece sunucu her istemci için ayrı oturum kaydı tutmadan değeri doğrulayabilir.

İlk Sorguda İstemci Çerezi

İstemci çerezi tam olarak 8 bayt, yani 64 bittir. İstemci bu değeri EDNS COOKIE seçeneğiyle sorguya ekler. DNS Cookies desteği açık olan sunucu, ilk sorguda daha önce verdiği bir sunucu çerezi görmez. Sunucu politikasına göre sorguyu yanıtsız bırakabilir veya normal yanıt ya da BADCOOKIE hata yanıtı gönderebilir. Yanıt gönderdiğinde istemci çerezini geri yansıtır ve kendi ürettiği sunucu çerezini de ekler. BADCOOKIE, geçerli sunucu çerezi gerektiğini bildiren hata kodudur.

İstemci, farklı sunucu IP adresleri için farklı istemci çerezleri kullanmalıdır. İstemcinin IP adresi değiştiğinde yeni bir istemci çerezi üretilmelidir. Bu kurallar, aynı değerin farklı sunucular veya farklı istemci adresleri arasında ilişkilendirme amacıyla kullanılmasını zorlaştırır.

Sonraki Sorgularda Sunucu Çerezi

İstemci aynı sunucuya yönelttiği sonraki sorgularda istemci çerezi ile sunucu çerezini birlikte gönderir. Sunucu değeri yeniden hesaplayarak veya desteklediği doğrulama yöntemiyle denetler. Geçerli sunucu çerezi, sunucunun daha önce aynı kaynak adresindeki ve aynı istemci çerezini kullanan uca yanıt gönderebildiğine dair sınırlı bir güvence sağlar.

Sunucu çerezi geçersizse sunucu bunu sunucu çerezi yokmuş gibi işler; politikasına göre sorguyu atabilir, normal yanıt verebilir veya BADCOOKIE hata yanıtıyla yeni bir sunucu çerezi gönderebilir. İstemci, yanıttaki istemci çerezinin kendi gönderdiği değerle eşleştiğini doğrular; ardından yeni sunucu çereziyle sorguyu yeniden deneyebilir. Yeni alınan sunucu çereziyle yapılan deneme de BADCOOKIE döndürürse RFC 7873, istemcinin bağlantı kurup veriyi sıralı ve güvenilir biçimde ileten TCP üzerinden yeniden denemesini önerir.

RFC 9018 Sürüm 1 Sunucu Çerezi

RFC 7873 sunucu çerezinin 8 ile 32 bayt arasında olmasına izin verir. Onu güncelleyen RFC 9018, farklı yazılımların birlikte çalışabilmesi için sürüm 1 sunucu çerezini 16 bayt olarak tanımlar. Bu yapı sürüm, ayrılmış alan, zaman damgası ve gizli anahtarla doğrulama değeri üreten SipHash-2-4 algoritmasının çıktısını içerir; hesaplamada istemci çerezi, IPv4 veya IPv6 istemci adresi ve yalnız sunucunun bildiği gizli değer kullanılır.

RFC 9018, sürüm 1 sunucu çerezleri için zaman damgasının sunucunun o anki saatine göre bir saat geçmiş ile beş dakika gelecek arasındaki aralıkta kabul edilmesini önerir. Geleceğe doğru küçük pay, sunucuların saatleri arasındaki fark içindir; sunucu başka doğrulama koşullarını da denetler. Sunucunun yarım saatten eski bir sunucu çerezi aldığında yeni bir sunucu çerezi üretmesi önerilir. Farklı sunucu çerezi sürümleri veya yerel politikalar bulunabileceği için bütün uygulamalarda geçerli tek bir mutlak süre yoktur.

Aynı IP adresinin birden fazla sunucudan duyurulduğu anycast yapısında DNS sunucularının aynı sürüm 1 hesaplama yöntemini, ortak gizli değerleri ve eşitlenmiş saatleri kullanması gerekir. RFC 9018'in ortak biçimi, farklı DNS yazılımlarının bulunduğu anycast kümelerinde bir sunucunun ürettiği çerezin diğer sunucularca doğrulanabilmesini sağlar. Gizli değer yenilenirken yeni değer, çerez üretiminde kullanılmadan önce kümedeki bütün sunuculara ulaştırılmalıdır.

UDP Trafiğinde Sahte Kaynak Riski Nasıl Azalır?

UDP bağlantı kurulumu yapmadığından paketteki kaynak IP adresinin gerçekten gönderene ait olduğunu doğrudan kanıtlamaz. Saldırgan, kurbanın IP adresini kaynak olarak gösteren küçük DNS sorguları gönderebilir ve DNS sunucusunun daha büyük yanıtını kurbana yöneltebilir. Bu davranış DNS amplification olarak bilinen trafik büyütme saldırılarında kullanılabilir.

DNS sunucusu büyük bir UDP yanıtı göndermeden önce geçerli bir sunucu çerezi isteyebilir. Kaynak IP adresini sahte gösteren ağ yolu dışındaki saldırgan, sunucunun gönderdiği değeri normal biçimde alamaz. Sunucu, sunucu çerezi bulunmayan veya doğrulanamayan sorguların yanıtını sınırlayabilir, küçük bir hata yanıtı verebilir ya da kendi politikasına göre ek doğrulama uygulayabilir.

İstemci, yanıttaki istemci çerezini sorguda gönderdiği değerle karşılaştırır. Ağ yolu dışındaki saldırganın DNS işlem kimliği ve kaynak bağlantı noktasının yanında bu 64 bitlik değeri de doğru tahmin etmesi gerekir. İstemci yanlış çerez değeri veya geçersiz uzunluk içeren yanıtı reddeder. Yanıtta COOKIE seçeneği bekliyorsa, bu seçeneğin bulunmadığı yanıtı da kabul etmez. Bu kural, DNS Cookies desteği olmayan her sunucunun yanıtının reddedileceği anlamına gelmez.

Ağ yolundaki saldırgan sunucu çerezini görebilir ve geçerli olduğu süre içinde yeniden kullanabilir. DNS Cookies bu nedenle ağ yolundaki saldırgana karşı güvenlik sağlamaz. Kaynak adresi filtreleme, belirli sürede verilecek yanıt sayısını sınırlama ve ağ düzeyindeki diğer savunmalar yine gereklidir.

DNS Cookies ile Diğer Güvenlik Yöntemleri Arasındaki Farklar

  • Güçlü kimlik doğrulama değildir: İstemcinin veya sunucunun gerçek kimliğini kanıtlamaz; yalnız önceki yanıtın görünen kaynak adresine ulaşabildiğine dair sınırlı güvence verir.
  • DNS verisi doğrulaması değildir: DNSSEC gibi dijital imzalarla kayıtların kaynağını ve bütünlüğünü doğrulamaz.
  • Şifreli DNS taşıması değildir: DoH (DNS over HTTPS), DoT (DNS over TLS) veya DoQ (DNS over QUIC) gibi DNS trafiğini şifreli bir kanala taşımaz. DoH web iletişiminde de kullanılan HTTPS'yi, DoT DNS için ayrılmış bir TLS bağlantısını, DoQ ise UDP üzerinde şifreli bağlantılar kuran QUIC protokolünü kullanır. TLS, bağlantıyı şifreleyen bir protokoldür.
  • Tam saldırı önleme sistemi değildir: Uygulama açıklarını veya bütün DNS önbellek zehirleme yöntemlerini engellemez. Çok sayıda kaynaktan gelen trafik ya da istekle bir hizmeti çalışamaz duruma getirmeyi amaçlayan DDoS saldırılarının tümüne karşı da koruma sunmaz.

Bu yöntemler birlikte kullanılabilir. Bir recursive resolver (özyinelemeli DNS çözümleyicisi) veri bütünlüğü için DNSSEC doğrulaması yaparken taşıma gizliliği için şifreli DNS kullanabilir; DNS Cookies ise özellikle UDP tabanlı iletişimde sahte kaynak ve ağ yolu dışından gönderilen sahte yanıt riskini azaltmaya yardımcı olur.

DNS Cookies Desteklenmiyorsa veya Sunucu Çerezi Geçersizse Ne Olur?

DNS Cookies yönteminin ek kontrol sağlaması için istemci ile sunucunun EDNS COOKIE seçeneğini desteklemesi gerekir. Taraflardan biri desteklemiyorsa DNS iletişimi çoğu durumda çerez olmadan sürer; bu mekanizmanın sağladığı ek koruma oluşmaz.

Sunucu çerezinin doğrulanamaması tek başına saldırı kanıtı değildir. İstemcinin genel IP adresi değişmiş, sunucu gizli değerini yenilemiş veya sorgu anycast kümesinde uyumsuz yapılandırılmış başka bir sunucuya ulaşmış olabilir. Uyumlu istemci yeni sunucu çerezini alıp sorguyu yineleyebilir.

Paketlerdeki IP adreslerini çeviren NAT ya da bu işlemi internet servis sağlayıcısının ağında yapan CGNAT arkasındaki istemci, genel IP adresindeki değişikliği her zaman algılayamaz. Dışarıdan görülen adres değişirse eski sunucu çerezi doğrulanmayabilir ve yeni değer alınması gerekebilir.

Gizliliği korumak için istemci, IP adresinin değiştiğini bildiğinde eski istemci ve sunucu çerezlerini yeniden kullanmamalıdır. Ayrıca DNS Cookies desteği bilinmeyen bir sunucuya daha önce kullandığı istemci çerezini tekrar göndermemelidir. DNS Cookies kişisel hesap bilgisi taşımasa da yanlış yeniden kullanım farklı bağlantıların ilişkilendirilmesini kolaylaştırabilir.