Oblivious DoH (ODoH) Nedir ve Klasik DoH'den Nasıl Ayrılır?
Oblivious DoH (ODoH), istemci ile DNS sorgusunu işleyen ODoH hedefi arasına ayrı bir ODoH proxy'si yerleştirir. Bu yapı, istemcinin IP adresi ile açık DNS sorgusunun içeriğini farklı taraflarda tutar. İstemci DNS mesajını yalnız hedefin açabileceği biçimde ayrıca şifreler ve proxy üzerinden hedefe gönderir.
DNS, alan adlarının IP adresleri gibi kayıtlarını sorgulamaya yarayan sistemdir. DoH (DNS over HTTPS), bu mesajları şifreli web bağlantısı olan HTTPS içinde taşır; bağlantıyı TLS protokolü korur. ODoH buna ek olarak sorgu içeriğini proxy'den gizler. Gizlilik modeli, proxy ile hedefin istemci ve sorgu bilgilerini birleştirmek üzere işbirliği yapmamasına dayanır.
ODoH Nasıl Çalışır?
ODoH sorgusunda istemci, şifreli mesajı ileten ODoH proxy'si ve mesajı açan ODoH hedefi olmak üzere üç taraf bulunur. İstemci kullanacağı proxy ile hedefi belirler ve DNS sorgusunu şifrelemek için hedefin açık anahtar bilgisine sahip olur.
- İstemci normal bir DNS sorgusu oluşturur ve gerekli ODoH mesaj yapısına yerleştirir.
- İstemci, hedefin açık anahtarını kullanan HPKE yöntemiyle DNS mesajını şifreler. HPKE, açık anahtarlı işlemden elde edilen geçici anahtarlarla mesajı korur; hedef karşılık gelen özel anahtarı kullanarak mesajı açabilir.
- İstemci bu şifreli mesajı HTTPS üzerinden proxy'ye gönderir. Proxy hedefi bilir ve mesajı hedefe iletir, ancak DNS sorgusunun açık içeriğini göremez.
- Hedef mesajı çözer; DNS sorgusunu kendisi işler veya sorgu için bir recursive resolver (özyinelemeli DNS çözümleyicisi) kullanır ve DNS yanıtını oluşturur.
- Hedef yanıtı, istemciyle paylaştığı sorguya özgü gizli bilgiden türetilen anahtarla şifreler. Proxy bu yanıtı değiştirmeden istemciye iletir; açık DNS içeriğini göremez.
Hedef, recursive resolver'ın kendisi olabilir, aynı altyapıda bulunabilir veya sorguyu başka bir recursive resolver'a iletebilir. ODoH açısından belirleyici nokta, istemciyle hedef arasındaki DNS mesajını proxy'nin açamaması ve hedefin doğrudan istemci bağlantısını almamasıdır.
Proxy ile Hedef Arasındaki Bilgi Ayrımı
Aşağıdaki ayrım, proxy ile hedefin bilgilerini birleştirmediği ve DNS mesajının istemciyi ayrıca tanımlamadığı durumda geçerlidir. Kaynak IP adresi, karşı tarafın bağlantıda gördüğü adrestir; cihazın yerel adresi olmak zorunda değildir. Örneğin bağlantı, trafiği şifreli bir tünelden taşıyan VPN üzerinden geçiyorsa karşı taraf VPN çıkışının adresini görebilir.
| Taraf | Görebildiği bilgi | Göremediği bilgi |
|---|---|---|
| ODoH proxy'si | İstemci bağlantısının kaynak IP adresi ve mesajın iletileceği hedef | DNS sorgusunun ve yanıtının açık içeriği |
| ODoH hedefi | Açık DNS sorgusu ve proxy üzerinden gelen bağlantı | İstemcinin kaynak IP adresi |
ODoH proxy'si DNS sorgusunu çözmez; hedefe şifreli mesajı iletir. İstemcinin kaynak adresini bildiren Forwarded gibi HTTP başlıklarını veya istemciye ait kimlik doğrulama bilgisini hedefe aktarmamalıdır. İstemci de proxy'ye gönderdiği isteğe çerez gibi özel oturum verileri eklememelidir.
Klasik DoH ile ODoH Arasındaki Temel Farklar
Klasik DoH ile ODoH arasındaki esas fark HTTPS kullanılıp kullanılmaması değildir. İki model arasındaki belirleyici ayrım, DNS sorgusunu gören taraf ile bağlantının kaynağını gören tarafın aynı hizmet olup olmamasıdır.
| Özellik | Klasik DoH | ODoH |
|---|---|---|
| Temel bağlantı yolu | İstemci ile DoH sunucusu arasında doğrudan bağlantı | İstemci ile proxy, ardından proxy ile hedef arasında iki aşamalı bağlantı |
| DNS sorgusunun açık içeriği | DoH sunucusu görebilir | Hedef görebilir; sorgu hedef için ayrıca şifrelenmiştir ve proxy içeriği açamaz |
| Bağlantının kaynak IP adresi | DoH sunucusu doğrudan istemcinin kaynak IP adresini görür | Proxy istemcinin kaynak IP adresini görür; hedef bağlantıyı proxy'den alır |
| Kaynak IP adresini ve DNS sorgusunu gören taraflar | DoH sunucusu iki bilgiyi de görebilir | Proxy kaynak IP adresini, hedef DNS sorgusunu görür; taraflar işbirliği yapmadığında iki bilgi tek hizmette birleşmez |
| DNS mesajına ek koruma | DNS mesajı HTTPS bağlantısının TLS koruması içindedir | DNS mesajı, proxy'nin açamayacağı biçimde hedef için ayrıca şifrelenir |
| Temel gizlilik amacı | Ağ yolu üzerindeki tarafların DNS içeriğini doğrudan okumasını sınırlar | Tek bir hizmetin hem istemcinin IP adresini hem de DNS içeriğini bilmesini önlemeye çalışır |
ODoH Kullanımı Neden Tam Anonimlik Sağlamaz?
İki sunucunun farklı adreslerde bulunması tek başına yeterli değildir. Gizlilik için proxy ile hedefin kayıtlarını birleştirmemesi ve mesajların istemciyi tanımlayan ek bilgi taşımaması gerekir. ODoH, bütün internet etkinliğini anonimleştirmez.
- Proxy ve hedefin işbirliği yapmaması gerekir. İki taraf kayıtlarını veya gözlemlerini birleştirirse istemci ile sorgu arasında yeniden ilişki kurulabilir.
- Trafik analizi bütünüyle ortadan kalkmaz. RFC 9230, zamanlama ve mesaj boyutu gibi trafik analizi yöntemlerine karşı kapsamlı korumayı protokolün kapsamı dışında bırakır.
- Koruma DNS sorgusuyla sınırlıdır. DNS çözümlemesinden sonra bir web sitesine veya başka bir internet hizmetine kurulan bağlantı ayrı bir işlemdir. ODoH bu sonraki bağlantının kaynak IP adresini kendiliğinden gizlemez.
- DNS mesajına eklenen ağ bilgisi hedef tarafından görülebilir. ECS (EDNS Client Subnet), istemcinin bulunduğu ağın adres aralığını DNS sorgusuna ekleyebilen bir seçenektir. Böyle bir bilgi gönderilirse ODoH bunu hedef sunucudan gizlemez; paylaşılan aralık daraldıkça istemciyi diğerlerinden ayırmak kolaylaşabilir.
Şifreli ODoH Mesajı ile DNS Önbelleği Aynı Şey Değildir
RFC 9230, şifreli ODoH istek ve yanıtlarının önbelleğe alınmasını yasaklar; bu mesajların şifrelemesi sorguya özgü geçici anahtar bilgisine bağlıdır. Bu kural, istemcinin çözdüğü DNS yanıtındaki kayıtları veya recursive resolver'ın elde ettiği verileri normal DNS önbelleğinde saklamasını yasaklamaz. TTL, DNS kaydının normal önbellek geçerlilik süresini belirtir; bu süre ile şifreli ODoH mesajının yeniden kullanılması farklı konulardır.
ODoH Kullanımı İçin Gereken Bileşenler
ODoH'yi destekleyen istemci, uyumlu proxy, hedef sunucu ve hedefin güncel açık anahtar yapılandırması gerekir. Her klasik DoH sunucusu ODoH desteği sunmaz. RFC 9230, bu bileşenlerin ve açık anahtarların nasıl bulunup yapılandırılacağını tanımlamaz. İstemcinin, açık anahtarın seçilen hedefe ait olduğunu doğrulayan bir yapılandırma kaynağı kullanması gerekir; yanlış anahtarla şifreleme yapmak sorguyu başka bir tarafa açabilir.
İstemci ODoH çalışmadığında doğrudan klasik DoH'ye dönüyorsa bağlantı şifreli kalabilir, ancak kaynak IP adresiyle sorguyu farklı taraflarda tutma özelliği kaybolur. Desteği yalnız ayarın adına bakarak varsaymayın; uygulamanın kullandığı sorgu yolunu ve geri dönüş davranışını kontrol edin. RFC 9230 deneysel kategoridedir ve bütün cihazlarda ODoH desteği bulunduğu anlamına gelmez.
