DNS-over-HTTPS ve DNS-over-TLS Nedir

Bir web sitesine bağlanırken tarayıcınızın en önce yaptığı işlerden biri, yazdığınız alan adını bir IP adresine çevirmek için DNS'e sorması. Bu sorgu, internetin en eski protokollerinden biri üzerinden ve neredeyse her zaman düz metin olarak gider. Yani banka.com yazdığınızda, aynı Wi-Fi ağındaki biri, kaldığınız otelin internet altyapısı ya da internet servis sağlayıcınız, tam olarak hangi siteyi ziyaret etmek istediğinizi çıplak gözle görebilir. HTTPS ile sayfa içeriğini şifrelemiş olsanız bile, o sayfaya nasıl ulaştığınızı belli eden DNS sorgusu açıkta kalır.

İşte DNS-over-HTTPS (DoH) ve DNS-over-TLS (DoT) tam olarak bu boşluğu kapatmak için tasarlandı. Her ikisi de sizinle DNS çözücü (resolver) arasındaki trafiği şifreleyerek, sorgularınızın yolda okunmasını ve değiştirilmesini engeller. Bu rehberde iki protokolün nasıl çalıştığını, aralarındaki port ve görünürlük farkının pratikte ne anlama geldiğini, bunların DNSSEC'ten neden tamamen farklı bir problemi çözdüğünü ve tarayıcıdan işletim sistemine kadar kurulumu adım adım ele alacağız.

Klasik DNS Neden Açıkta Çalışır?#

DNS 1980'lerde, güvenlik değil hız ve basitlik önceliğiyle tasarlandı. Standart bir DNS sorgusu 53 numaralı port üzerinden, çoğunlukla UDP ile ve hiçbir şifreleme olmadan gönderilir. Bu, iki ciddi soruna yol açar: gizlilik ve bütünlük.

Gizlilik sorunu şudur: sorgu düz metin olduğu için, trafiği görebilen herkes hangi alan adlarını çözdüğünüzü okuyabilir. İnternet servis sağlayıcınız bu veriyi ticari amaçla toplayabilir, bir kafenin misafir ağı ziyaret ettiğiniz siteleri kaydedebilir, ya da bir sansür sistemi belirli alan adlarına giden sorguları tespit edip engelleyebilir. HTTPS sayfayı korur ama "nereye gittiğinizi" korumaz; bu bilgi DNS katmanında sızar.

Bütünlük sorunu ise sorgunun cevabıyla ilgilidir. Araya giren bir saldırgan, gerçek yanıt gelmeden önce sahte bir cevap enjekte ederek sizi yanlış bir sunucuya yönlendirebilir. DNS'in nasıl çalıştığını ve bu sürecin adımlarını hatırlamak isterseniz DNS nedir yazısı iyi bir temel sunar. Şifreli DNS protokolleri öncelikli olarak birinci sorunu, yani gizliliği ve yol üzerindeki manipülasyonu çözer; ikinci sorunun kriptografik ispatı ise DNSSEC'in görevidir. Bu ayrımı birazdan netleştireceğiz.

DNS-over-HTTPS (DoH) Nedir?#

DNS-over-HTTPS (RFC 8484), DNS sorgularını sıradan bir HTTPS isteği gibi paketleyip 443 numaralı port üzerinden gönderir. Yani DNS sorgunuz, tıpkı bir web sayfası yüklerken kurulan bağlantı gibi görünür. Çözücü tarafında bir HTTPS uç noktası vardır; örneğin Cloudflare için https://cloudflare-dns.com/dns-query, Google için https://dns.google/dns-query, Quad9 için https://dns.quad9.net/dns-query.

DoH'un en belirgin özelliği, DNS trafiğini normal web trafiğinden ayırt edilemez hale getirmesidir. Bir ağ yöneticisi ya da sansür sistemi 443 portundaki HTTPS trafiğini tümden engellemeden DoH'u seçici olarak durduramaz, çünkü DNS sorguları milyonlarca sıradan HTTPS bağlantısının arasında kaybolur. Bu, gizlilik ve sansür aşımı açısından güçlü bir özelliktir.

DoH'un JSON API biçimini komut satırından denemek, protokolün ne kadar "web gibi" olduğunu iyi gösterir:

# DoH uç noktasına doğrudan HTTP isteğiyle A kaydı sorma
curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=clou.tr&type=A' | jq

# Yanıt (kısaltılmış):
# {
#   "Status": 0,
#   "Answer": [
#     { "name": "clou.tr", "type": 1, "TTL": 300, "data": "203.0.113.10" }
#   ]
# }

Bu esnekliğin bir bedeli var. DoH çoğunlukla uygulama seviyesinde çalışır: modern tarayıcılar kendi DoH ayarlarını taşır ve işletim sisteminin DNS ayarlarını atlayarak (bypass) doğrudan seçtikleri çözücüye sorar. Bu, bir kurumda yerel DNS ile yapılan içerik filtreleme, ebeveyn denetimi ya da iç ağdaki split-horizon çözümlerini devre dışı bırakabilir. Yani DoH kullanıcı için güçlü, ağ yöneticisi için ise bazen başa çıkılması gereken bir davranıştır.

DNS-over-TLS (DoT) Nedir?#

DNS-over-TLS (RFC 7858) aynı hedefe farklı bir yoldan ulaşır: DNS sorgularını bir TLS tüneli içine alır ama bunu kendine ait 853 numaralı port üzerinden yapar. Şifreleme yine standart TLS'tir; bağlantı kurulurken çözücünün sertifikası doğrulanır ve tüm sorgu-cevap trafiği bu tünelin içinde akar.

DoH'tan temel farkı görünürlüktür. DoT ayrı bir port kullandığı için ağ üzerinde açıkça tanımlanabilir. Bir güvenlik duvarı 853 portunu görüp "bu DoT trafiği" diyebilir; isterse buna izin verir, isterse engeller. Bu, gizliliği bir miktar azaltır (birinin DNS'i şifrelediğiniz görülür, ama içeriği yine görülmez) ama kurumsal ağlar için bir avantaja dönüşür: yönetici DNS'in şifrelenmesine izin verirken hangi çözücünün kullanılacağını hâlâ denetleyebilir.

DoT genellikle işletim sistemi seviyesinde yapılandırılır. Linux'ta systemd-resolved bunu yerleşik olarak destekler:

# /etc/systemd/resolved.conf
[Resolve]
DNS=1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
DNSOverTLS=yes

#cloudflare-dns.com kısmı kritik: bu, TLS el sıkışmasında sunucunun sertifikasının hangi ada karşı doğrulanacağını söyler. Bu doğrulama olmadan şifreleme olur ama "doğru çözücüye mi bağlandım?" güvencesi zayıflar. Ayarı uyguladıktan sonra:

sudo systemctl restart systemd-resolved
resolvectl status | grep -A2 'DNS Servers'
# +DNSOverTLS satırını görmelisiniz

# Bir sorgunun gerçekten TLS ile gittiğini test etmek için:
resolvectl query clou.tr

Bir DoT sorgusunu elle doğrulamak isterseniz Knot DNS'in kdig aracı bunun için biçilmiş kaftandır:

kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com clou.tr
# Çıktıda "TLS session ... verified" ve şifreli bağlantı bilgisi görünür

DoH ve DoT Arasındaki Fark#

İki protokol de aynı kriptografik gücü (TLS) kullanır ve ikisi de sizinle çözücü arasındaki trafiği şifreler. Fark, bu şifreli trafiğin ağda nasıl göründüğü ve nerede yapılandırıldığıyla ilgilidir. Aşağıdaki tablo pratikteki ayrımları özetliyor:

Bu farkı bir cümleyle özetlemek gerekirse: DoH gizli olmak için kalabalığa karışır, DoT ise şeffaf bir biçimde şifreler. Bir birey için, örneğin kamuya açık bir Wi-Fi'de ya da sansürün yoğun olduğu bir ağda, DoH'un ayırt edilemezliği genellikle daha çok işe yarar. Bir kurum ya da sunucu yöneticisi için ise DoT'un yönetilebilirliği tercih sebebidir; çünkü çalışanların DNS'ini şifrelerken hangi çözücüye gittiğini denetleyebilir ve güvenlik loglamasını sürdürebilirsiniz.

Hangisini seçerseniz seçin, dikkat edilmesi gereken bir sınır var: her iki protokol de yalnızca sizinle çözücü arasındaki yolu şifreler. Çözücünün yetkili sunucularla konuşması hâlâ büyük ölçüde şifresizdir. Yani DoH/DoT, DNS trafiğini internet servis sağlayıcınızdan ve yerel ağdaki dinleyicilerden gizler; ama artık seçtiğiniz çözücü sağlayıcısı (Cloudflare, Google, Quad9 ya da kendi çözücünüz) tüm sorgularınızı görür. Güven noktası ISP'den çözücü sağlayıcısına kayar. Bu yüzden çözücü seçimi ve o sağlayıcının log/gizlilik politikası, protokol seçiminden daha önemli hale gelir.

DNSSEC ile Farkı: Bütünlük mü Gizlilik mi?#

Şifreli DNS ile DNSSEC en sık karıştırılan iki konudur, oysa tamamen farklı problemleri çözerler. En net ayrım şu: DoH/DoT gizlilik sağlar, DNSSEC bütünlük sağlar.

DoH ve DoT sorgunuzun okunmasını engeller ama gelen cevabın gerçekten yetkili kaynaktan geldiğini kriptografik olarak kanıtlamaz. Şifreli bir tünelin ucundaki çözücü size yanlış ya da manipüle edilmiş bir cevap verirse, tünelin şifreli olması sizi kurtarmaz. Buna karşılık DNSSEC, her DNS kaydını yetkili sunucunun anahtarıyla imzalar; böylece cevabın doğruluğunu ve değiştirilmediğini matematiksel olarak doğrularsınız, ama bu imzalar trafiği şifrelemez — sorgu-cevap yolda hâlâ okunabilir.

Bunlar birbirinin alternatifi değil, birbirini tamamlayan katmanlardır. En sağlam kurulum ikisini birden kullanır: DNSSEC ile cevabın doğruluğunu garanti eder, DoH/DoT ile de o cevaba giden yolu gizlersiniz. DNSSEC'in güven zincirini ve DS kaydı kurulumunu ayrıntılı görmek için DNSSEC nedir yazısına göz atabilirsiniz. Kendi alan adınızda DNSSEC'i açtıktan sonra istemci tarafında DoH/DoT'a geçmek, hem gizlilik hem bütünlük tarafını aynı anda kapatmanın en pratik yoludur.

Tarayıcıda DoH Kurulumu#

Modern tarayıcıların çoğu DoH'u yerleşik olarak destekler ve bunu birkaç tıkla açabilirsiniz. Bu yol, işletim sistemine dokunmadan yalnızca tarayıcı trafiğinizi şifrelemek istediğinizde en hızlı çözümdür.

Firefox DoH'u en olgun şekilde destekleyen tarayıcılardan biridir. Ayarlar → Gizlilik ve Güvenlik → HTTPS üzerinden DNS bölümünden açabilir, sağlayıcı olarak Cloudflare, NextDNS ya da özel bir uç nokta seçebilirsiniz. İnce ayar isteyenler için about:config üzerinden manuel yapılandırma da mümkündür:

# about:config içinde ayarlanır
network.trr.mode = 2          ; 2 = DoH öncelikli, başarısızsa sistem DNS'e düş
network.trr.uri = https://cloudflare-dns.com/dns-query
network.trr.bootstrapAddress = 1.1.1.1

Buradaki network.trr.mode değeri önemlidir: 2 "önce DoH dene, olmazsa sistem DNS'ine düş" anlamına gelir ve günlük kullanım için en dengeli seçenektir; 3 ise "yalnızca DoH, başka yolu kabul etme" demektir ve daha katı gizlilik ister.

Chrome, Edge ve tabanı Chromium olan tarayıcılar için ayar Ayarlar → Gizlilik ve güvenlik → Güvenlik → Güvenli DNS'i kullan altındadır. Buradan hazır bir sağlayıcı seçebilir ya da özel bir DoH şablonu girebilirsiniz. Ayarı yaptıktan sonra tarayıcının gerçekten DoH kullandığını, Cloudflare'ın https://1.1.1.1/help sayfasına girerek "Using DNS over HTTPS (DoH)" satırının Yes olduğunu görerek doğrulayabilirsiniz.

İşletim Sisteminde Kurulum#

Tarayıcı ayarı yalnızca o tarayıcıyı korur; e-posta istemcisi, mobil uygulamalar ve diğer programlar hâlâ şifresiz DNS kullanır. Tüm sistemin trafiğini korumak için şifrelemeyi işletim sistemi seviyesinde açmak gerekir.

Windows 11, DoT değil ama DoH'u yerleşik olarak destekler. Ayarlar → Ağ ve İnternet → (bağlantınız) → DNS sunucusu ataması → Düzenle yolunda DNS'i elle 1.1.1.1 gibi bilinen bir çözücüye ayarlar ve "Şifreli DNS" seçeneğini "Yalnızca şifreli (DoH)" yaparsanız, tüm sistem sorguları DoH ile gider.

Linux tarafında en temiz yol yukarıda gösterdiğimiz systemd-resolved ile DoT'tur. systemd-resolved kullanmayan ya da daha fazla denetim isteyen dağıtımlarda stubby ya da dnscrypt-proxy gibi yerel bir vekil (proxy) kurup 127.0.0.1'i sistem çözücüsü yaparak DoT/DoH'u tüm makineye yayabilirsiniz. Örnek bir stubby yapılandırması:

# /etc/stubby/stubby.yml (kısaltılmış)
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS      # yalnızca DoT kullan
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
listen_addresses:
  - 127.0.0.1@53
upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 9.9.9.9
    tls_auth_name: "dns.quad9.net"

tls_authentication: REQUIRED satırı, sertifika doğrulaması başarısız olursa sorguyu düz metne düşürmeden reddeder — gizlilik açısından doğru olan katı davranış budur.

Android 9 ve üzeri, "Özel DNS" (Private DNS) adı altında DoT'u ayarlar menüsünden destekler. Ayarlar → Ağ ve internet → Özel DNS bölümüne çözücünün ana adını (one.one.one.one, dns.google ya da dns.quad9.net) yazmanız yeterlidir; Android bunu tüm bağlantılarda DoT olarak uygular. iOS ise DoH/DoT'u yapılandırma profilleri ya da NextDNS gibi uygulamalar aracılığıyla destekler.

Kendi Sunucunuzda Şifreli Çözücü#

Üçüncü taraf bir sağlayıcıya güven noktanızı devretmek istemiyorsanız, kendi çözücünüzü çalıştırıp önüne bir DoT/DoH ucu koyabilirsiniz. Bu, hem gizliliği kendi elinizde tutmanızı sağlar hem de kurum içi çözümler için idealdir. Örneğin arka planda çalışan bir çözücünün (Unbound, Knot Resolver vb.) önüne, DoT bağlantılarını 853 portunda karşılayıp yerel çözücüye ileten bir TLS sonlandırıcı koyabilirsiniz. Nginx'in stream modülü bunun için kullanışlıdır:

# nginx stream bloğu: 853 portunda DoT'u sonlandırıp
# yerel Unbound'a (127.0.0.1:53) ilet
stream {
    upstream dns_backend {
        server 127.0.0.1:5353;   # yerel çözücü
    }
    server {
        listen 853 ssl;
        ssl_certificate     /etc/letsencrypt/live/dns.ornek.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/dns.ornek.com/privkey.pem;
        ssl_protocols       TLSv1.2 TLSv1.3;
        proxy_pass          dns_backend;
        proxy_timeout       5s;
    }
}

Burada dikkat edilecek nokta, DoT ucunun geçerli bir TLS sertifikası gerektirmesidir; istemciler tıpkı bir web sitesinde olduğu gibi sertifikayı doğrular. Sertifika yönetimi ve güvenli TLS yapılandırması konusunda profesyonel destek isterseniz sunucu yönetimi hizmetimiz bu tür kurulumları sizin için üstlenebilir; sertifikanın nasıl alınıp yenilendiği tarafını ise SSL çözümleri sayfamızda bulabilirsiniz. Bu tarz bir kurulum, kendi ağınızdaki tüm cihazları tek bir şifreli çözücüye yönlendirerek hem gizliliği merkezileştirir hem de DNS tabanlı filtreleme kurallarınızı kendi kontrolünüzde tutmanızı sağlar.

Şifreli DNS'in Sınırları ve Dikkat Edilecekler#

Şifreli DNS güçlü bir gizlilik katmanı ekler ama sihirli bir kalkan değildir; birkaç sınırı bilmek gerçekçi bir beklenti kurmayı sağlar.

Birincisi, daha önce değindiğimiz gibi güven noktası kaybolmaz, yalnızca yer değiştirir. Sorgularınız artık ISP'niz yerine seçtiğiniz çözücü sağlayıcısına görünür. Bu yüzden log tutmayan, açık gizlilik politikası olan bir sağlayıcı seçmek ya da kendi çözücünüzü çalıştırmak önemlidir.

İkincisi, DNS şifrelense bile bağlantınızın bir kısmı hâlâ hedef siteyi ele verebilir. Özellikle TLS el sıkışmasındaki SNI alanı çoğu durumda hangi siteye bağlandığınızı düz metin olarak taşır; Encrypted Client Hello (ECH) bunu kapatmaya çalışsa da henüz her yerde yaygın değildir. Yani DoH/DoT, gizlilik bulmacasının önemli ama tek parçası değildir.

Üçüncüsü, kurumsal ortamlarda DoH'un yerel DNS'i atlaması istenmeyen sonuçlar doğurabilir: iç ağdaki split-horizon kayıtları çözülemez, güvenlik filtreleri devre dışı kalır, sorun giderme zorlaşır. Bu yüzden birçok kurum, kendi ağında DoT'u tercih eder ya da onaylı bir DoH çözücüsünü zorunlu kılar. Ev kullanıcısı için DoH neredeyse her zaman kazançtır; bir ağı yönetiyorsanız, seçiminizi denetim ihtiyacınıza göre yapın.

Sıkça Sorulan Sorular#

DoH mu DoT mu daha iyi?#

Hangisinin "daha iyi" olduğu kime ve hangi ortama sorduğunuza bağlıdır. Bireysel gizlilik, kamuya açık ağlar veya sansür aşımı önceliğinizse DoH genellikle daha uygundur, çünkü trafiği normal HTTPS'ten ayırt edilemez hale getirir. Bir kurum ya da sunucu ağını yönetiyorsanız DoT'un yönetilebilirliği ve şeffaflığı tercih sebebidir; DNS'i şifrelerken hangi çözücünün kullanıldığını denetlemeye devam edebilirsiniz.

Şifreli DNS internetimi yavaşlatır mı?#

Pratikte fark çoğu kullanıcı için hissedilmez düzeydedir. TLS el sıkışması ilk bağlantıda küçük bir gecikme ekler, ancak bağlantı yeniden kullanıldığı ve çözücüler önbellek tuttuğu için günlük gezinti hızınız neredeyse aynı kalır. DoH, HTTP/2 ve HTTP/3 üzerinde bağlantıyı yeniden kullanabildiği için bu ek maliyeti daha da azaltır. Coğrafi olarak size yakın ve hızlı bir çözücü seçmek olası gecikmeyi en aza indirir.

DNSSEC varsa DoH veya DoT'a gerek var mı?#

Evet, çünkü ikisi farklı problemleri çözer. DNSSEC cevabın gerçek ve değiştirilmemiş olduğunu kanıtlar ama sorgunuzu şifrelemez; yani birileri hâlâ hangi siteyi sorduğunuzu görebilir. DoH ve DoT ise trafiği şifreleyerek bu görünürlüğü kapatır ama cevabın doğruluğunu garanti etmez. Tam koruma için ikisini birlikte kullanmak gerekir: DNSSEC bütünlüğü, şifreli DNS gizliliği sağlar.

İşyeri veya okul ağı şifreli DNS'i engelleyebilir mi?#

DoT için bu görece kolaydır, çünkü 853 portu ayrıdır ve güvenlik duvarı bu portu kapatarak DoT'u engelleyebilir. DoH ise 443 portunda normal HTTPS gibi göründüğünden seçici olarak engellenmesi çok daha zordur; ağ yöneticisinin bunu durdurmak için ya bilinen DoH sunucularının IP'lerini engellemesi ya da tüm HTTPS trafiğini denetlemesi gerekir. Kurumsal ağlar bu yüzden genellikle onaylı bir çözücüyü zorunlu kılma yolunu seçer.

Hangi ücretsiz şifreli DNS sağlayıcılarını kullanabilirim?#

En yaygın kullanılan ücretsiz sağlayıcılar Cloudflare (1.1.1.1 / cloudflare-dns.com), Google Public DNS (8.8.8.8 / dns.google) ve Quad9'dur (9.9.9.9 / dns.quad9.net). Üçü de hem DoH hem DoT destekler; Quad9 ayrıca kötü amaçlı alan adlarını engelleme özelliği sunar. Seçim yaparken sağlayıcının gizlilik politikasını ve log tutma davranışını okumakta fayda var, çünkü şifreli DNS ile birlikte sorgularınızı gören taraf artık bu sağlayıcı olur.

Kendi çözücümü çalıştırmak mantıklı mı?#

Gizliliği tamamen kendi kontrolünüzde tutmak, kurum içi filtreleme kuralları uygulamak ya da üçüncü taraf bir sağlayıcıya güvenmek istemiyorsanız kendi çözücünüzü çalıştırmak mantıklıdır. Bir Unbound veya Knot Resolver kurup önüne DoT/DoH ucu koyarak ağınızdaki tüm cihazları tek bir şifreli çözücüye yönlendirebilirsiniz. Bu yaklaşım biraz bakım gerektirir; sertifika yenileme, çözücü güncellemeleri ve izleme işini üstlenmeniz gerekir, ancak karşılığında güven noktasını kimseyle paylaşmazsınız.

Kapanış#

DNS-over-HTTPS ve DNS-over-TLS, uzun yıllar açıkta akan DNS trafiğini nihayet kapatan iki pratik protokol. İkisi de sizinle çözücü arasındaki yolu şifreler; fark, DoH'un normal web trafiğine karışıp ayırt edilemez olması, DoT'un ise ayrı bir portta şeffaf biçimde çalışıp yönetilebilir kalmasıdır. Bunu DNSSEC ile birlikte düşündüğünüzde tablo tamamlanır: DNSSEC cevabın doğruluğunu, şifreli DNS ise sorgunun gizliliğini korur. Birey olarak tarayıcınızda birkaç tıkla DoH açmak bugün atabileceğiniz en kolay gizlilik adımlarından biri; bir ağ yönetiyorsanız DoT ile denetimi elinizde tutabilirsiniz.

Kendi alan adınız ve sunucunuz için bu katmanları birlikte kurmak istiyorsanız Clou.TR yanınızda. Güçlü ve DNSSEC uyumlu altyapımızla hosting paketlerimizi inceleyebilir, kendi şifreli çözücünüzü barındıracak esneklik için sanal ve fiziksel sunucu çözümlerimize göz atabilir, kurulum ve TLS yapılandırmasını bize bırakmak isterseniz sunucu yönetimi hizmetimizden yararlanabilirsiniz. DNS ve güvenlik tarafını doğru kuralım, siz işinize odaklanın.