DNS, Ağ Güvenliği ve Şifreleme Protokolleri

DNS, Ağ Güvenliği ve Şifreleme Protokolleri
Ağ Güvenliği · Ağ Protokolleri

DNS, Ağ Güvenliği ve
Şifreleme Protokolleri

İnternetin omurgasını oluşturan protokollerin, güvenlik katmanlarının ve şifreleme mekanizmalarının derinlemesine teknik incelemesi. DNS çözümlemesinden TLS el sıkışmasına, saldırı vektörlerinden modern savunma stratejilerine kapsamlı bir rehber.

Konu DNS / PKI / TLS / IPSec
Katman OSI 2–7
Seviye İleri Düzey
01

DNS Mimarisi:
Dağıtık İsimlendirme Sistemi

Domain Name System (DNS), 1983’te RFC 882 ile tanımlanan ve günümüzde yaklaşık 350 milyonun üzerinde kayıtlı alan adını yöneten hiyerarşik, dağıtık bir veritabanı sistemidir. Tek bir merkezi otorite yerine, milyonlarca sunucunun birlikte çalıştığı bu yapı, insan tarafından okunabilir alan adlarını makine tarafından işlenebilen IP adreslerine çevirir.

Hiyerarşik Yapı ve Yetki Devri

DNS ağacı, en tepede kök bölgesi (root zone) ile başlar. ICANN tarafından koordine edilen ve 13 adres kümesine sahip kök sunucular, dünya genelinde Anycast adresleme ile 1.000’den fazla fiziksel node üzerinden servis verir. Her kök sunucu kümesi, gerçekte onlarca ile yüzlerce fiziksel makineye yönlendirilir; bu sayede yük dağıtımı ve yüksek erişilebilirlik sağlanır.

Kök bölgesinin altında Üst Düzey Alan Adları (TLD) yer alır: .com, .net, .org gibi jenerik TLD’ler ve .tr, .de, .uk gibi ülke kodlu TLD’ler. Yetkili isim sunucuları (authoritative name servers) ise belirli bir alan için nihai ve kesin cevabı döndüren sunuculardır.

DNS Çözümleme Akışı — Yinelemeli Sorgu
1

İstemci → Stub Resolver

Kullanıcı tarayıcısı www.example.com için sorgu oluşturur. İşletim sisteminin stub resolver’ı önce yerel önbelleği (/etc/hosts ve OS cache) kontrol eder.

2

Stub → Özyinelemeli Resolver

Önbellekte kayıt yoksa, sorgu ISP’nin veya yapılandırılmış özyinelemeli resolver’ına (örn. 8.8.8.8, 1.1.1.1) iletilir. Bu sunucu, istemci adına tüm çözümleme yükünü üstlenir.

3

Resolver → Kök Sunucu

Resolver, kök sunuculardan birine referral (yönlendirme) sorgusu gönderir. Kök, .com TLD’sini yöneten sunucuların adres listesini (NS kayıtları ve glue records) döndürür.

4

Resolver → TLD Sunucusu

Verisign’ın işlettiği .com TLD sunucusuna sorgu iletilir. TLD, example.com için yetkili isim sunucularının NS kayıtlarını döndürür.

5

Resolver → Yetkili Sunucu → İstemci

Yetkili sunucu, A veya AAAA kaydını döndürür. Resolver yanıtı önbelleğe alır (TTL süresi boyunca) ve istemciye iletir. Tüm bu işlem tipik olarak 20–120 ms arasında tamamlanır.

DNS Kayıt Türleri

DNS protokolü, farklı amaçlara hizmet eden onlarca kayıt türünü destekler. Bu kayıtlar, basit IP eşlemesinden e-posta yönlendirmeye, metin tabanlı doğrulamaya kadar geniş bir işlevsellik sağlar.

Tür Açıklama Örnek Değer Kullanım
A IPv4 adresi eşlemesi 93.184.216.34 Temel
AAAA IPv6 adresi eşlemesi 2606:2800:220:1::68 Temel
CNAME Kanonik isim takma adı; başka bir FQDN’e yönlendirir alias.example.com. Yönlendirme
MX Posta sunucusu ve öncelik değeri 10 mail.example.com. E-posta
TXT Serbest metin; SPF, DKIM, DMARC doğrulaması için kullanılır v=spf1 include:… -all Güvenlik
NS Yetkili isim sunucuları ns1.example.com. Yetki
SOA Bölge otoritesi başlangıcı; seri numarası, TTL, sorumlu e-posta ns1 admin 2024010101 … Bölge
PTR Ters DNS çözümlemesi (IP → isim) host.example.com. Ters
SRV Servis konumu; protokol, ağırlık, port, hedef 0 5 443 sip.example.com. Servis
CAA Sertifika yetkilisi kısıtlaması; hangi CA sertifika verebilir 0 issue “letsencrypt.org” Kritik
⚡ TTL ve Önbellek Stratejisi

TTL (Time To Live) değeri, bir DNS kaydının özyinelemeli resolver ve istemci önbelleklerinde ne kadar süre tutulacağını saniye cinsinden belirtir. Düşük TTL değerleri (60–300s) hızlı güncelleme esnekliği sağlarken, kök sunucularına ve TLD sunucularına gönderilen sorgu yükünü artırır. Yüksek TTL değerleri (3600–86400s) sorgu sayısını azaltır ancak IP geçişleri veya DNS kayıt güncellemelerinde yavaş yayılmaya neden olur.

Kritik DNS değişikliklerinden (IP geçişi, hosting taşıması) önce TTL değerini geçici olarak düşürmek (pre-lowering), olası sorunlarda hızlı geri dönüş imkânı sunar.


02

DNSSEC:
Kriptografik Bölge İmzalama

DNS, tasarım itibarıyla kimlik doğrulama mekanizmasından yoksundur; herhangi bir resolver, herhangi bir yanıt döndürebilir. DNSSEC (Domain Name System Security Extensions), RFC 4033–4035 ile tanımlanmış ve bölge verilerini asimetrik kriptografi ile imzalayan bir güven zinciri oluşturur.

DNSSEC Kayıt Türleri

DNSSEC, mevcut DNS’e ek dört kritik kayıt türü ekler. Bu kayıtlar, kaynağın gerçekliğini doğrulamak ve veri bütünlüğünü güvence altına almak için birlikte çalışır:

🔑

DNSKEY

Bölge için genel (public) anahtarları barındırır. ZSK (Zone Signing Key) ve KSK (Key Signing Key) olmak üzere iki anahtar çifti kullanılır. KSK, diğer DNSKEY kayıtlarını imzalar; ZSK ise tüm bölge kayıtlarını imzalar.

✍️

RRSIG

Resource Record Signature. Her DNS kayıt kümesine (RRset) ait kriptografik imzayı içerir. İmza, hangi anahtarla oluşturulduğunu, geçerlilik süresini ve algoritma türünü belirtir.

🛡️

DS

Delegation Signer. Alt bölgenin KSK’sının özet (hash) değerini üst bölgede depolar. Güven zincirinin halkası olarak görev yapar; kök → TLD → yetkili sunucu arasındaki güveni köprüler.

🚫

NSEC / NSEC3

Var olmayan kayıtların kriptografik kanıtını sunar (authenticated denial of existence). NSEC3, bölge içeriğinin tüm isimlerini ifşa etmemek için hashleme kullanır ve “zone walking” saldırısını engeller.

⚠ DNSSEC Sınırlılıkları

DNSSEC, DNS yanıtlarının kaynağını ve bütünlüğünü doğrular; ancak sorgular ve yanıtlar hâlâ açık metin olarak iletilir. Bu nedenle DNSSEC, gizlilik (confidentiality) sağlamaz. İstemci hangi alan adlarına sorgu yaptığını ağ gözlemcileri hâlâ görebilir. Gizlilik için DNS-over-HTTPS (DoH) veya DNS-over-TLS (DoT) kullanılmalıdır.

BASH# DNSSEC doğrulama kontrolü dig +dnssec +short DS example.com @8.8.8.8 # Belirli bir bölgenin DNSKEY kayıtlarını sorgula dig DNSKEY example.com +multiline # Güven zinciri doğrulama (delv aracı) delv +rtrace www.example.com A # DNSSEC imza geçerlilik süresini kontrol et dig RRSIG example.com SOA @ns1.example.com

03

TLS / SSL:
Taşıma Katmanı Güvenliği

Transport Layer Security (TLS), ağ üzerinden iletilen verilerin gizliliğini, bütünlüğünü ve kimlik doğrulamasını sağlayan kriptografik protokoldür. SSL’in halefi olan TLS, HTTPS’den SMTP’ye, IMAPS’tan FTPS’e kadar pek çok protokolün güvenlik katmanını oluşturur. TLS 1.3 ile birlikte protokol önemli ölçüde sadeleştirilmiş ve güçlendirilmiştir.

TLS 1.3, yalnızca El Sıkışma (Handshake) süresini tek bir tur-döngüsüne (1-RTT) indirgemekle kalmaz; önceki sürümlerde yer alan tüm zayıf şifre paketlerini (cipher suites) de protokol düzeyinde ortadan kaldırır.

TLS 1.2 vs TLS 1.3: Temel Farklar

TLS 1.3, protokol geçmişindeki en kapsamlı revizyonu temsil eder. 2018’de RFC 8446 ile standartlaştırılan bu sürüm, hem güvenlik hem de performans açısından köklü değişiklikler içerir.

Özellik TLS 1.2 TLS 1.3
El sıkışma süresi 2-RTT (tam el sıkışma) 1-RTT; 0-RTT (tekrar bağlantı için)
Anahtar değişimi RSA, DH, ECDH (statik) Yalnızca ECDHE, DHE (Forward Secrecy zorunlu)
Şifre paketleri 370+ şifre paketi (birçoğu zayıf) 5 güçlü şifre paketi (AES-GCM, ChaCha20)
Şifreli handshake Kısmen; ServerHello’dan sonra Sertifikalar dahil tüm handshake şifreli
Kaldırılan özellikler RC4, MD5, SHA-1, RSA anahtar değişimi Sıkıştırma, renegotiation, statik RSA/DH
İleri gizlilik Opsiyonel Zorunlu

TLS El Sıkışma Mekanizması (TLS 1.3)

TLS 1.3 el sıkışması, önceki sürümlere kıyasla dramatik biçimde basitleştirilmiştir. İstemci, ClientHello mesajında desteklediği şifre paketlerini ve anahtar paylaşım parametrelerini (key_share) eş zamanlı olarak gönderir; böylece sunucunun ekstra tur-döngüsü gerektirmeden anahtar türetmesine olanak tanır.

TLS 1.3 Handshake — 1-RTT El Sıkışması
C

ClientHello

İstemci: Desteklenen TLS sürümleri, şifre paketleri (cipher_suites), ECDHE anahtar paylaşımları (key_share), SNI uzantısı ve rastgele nonce değeri gönderilir.

S

ServerHello + Şifreli Mesajlar

Sunucu: Seçilen şifre paketi, kendi key_share değeri ve rastgele nonce döndürülür. Bu noktadan itibaren bağlantı şifrelenir. Sunucu sertifikasını ve CertificateVerify (özel anahtarla imzalanmış el sıkışma özeti) gönderir.

K

Anahtar Türetme (HKDF)

Her iki taraf, ECDH paylaşılan sırrından HKDF (HMAC-based Extract-and-Expand Key Derivation Function) kullanarak oturum anahtarlarını türetir. Handshake, uygulama ve yeniden başlatma için ayrı anahtar hiyerarşisi oluşturulur.

F

Finished + Uygulama Verisi

İstemci, Finished mesajı (el sıkışma özetinin HMAC’i) gönderir. Bağlantı kurulur ve uygulama verisi iletilmeye başlar. Tüm süreç tipik olarak tek bir RTT gerektirir.

✦ Forward Secrecy (İleri Gizlilik)

TLS 1.3’te zorunlu olan Perfect Forward Secrecy (PFS), her oturum için bağımsız, geçici (ephemeral) anahtar çiftleri kullanılmasını sağlar. Bir sunucunun özel anahtarının çalınması durumunda, geçmişte yapılan oturumların şifreleri çözülemez; çünkü her oturumun anahtar materyali o oturumla birlikte yok olur. Bu özellik, pasif ağ dinleme saldırılarına (NSA, PRISM tipi kitlesel gözetleme dahil) karşı temel savunma katmanını oluşturur.

OPENSSL# Sunucunun TLS sürümü ve şifre paketlerini sorgula openssl s_client -connect example.com:443 -tls1_3 2>&1 | grep -E “Protocol|Cipher” # Sertifika zincirini ve geçerlilik tarihlerini kontrol et openssl s_client -connect example.com:443 -showcerts 2>/dev/null | \ openssl x509 -noout -dates -subject -issuer # TLS 1.2 şifre paketi listesi (SSL Labs benzeri analiz) nmap –script ssl-enum-ciphers -p 443 example.com # 0-RTT destekleyip desteklemediğini test et openssl s_client -connect example.com:443 -early_data /dev/null

04

PKI & X.509 Sertifikaları:
Dijital Kimlik Altyapısı

Public Key Infrastructure (PKI), dijital sertifikaların verilmesi, yönetimi, dağıtımı, kullanımı, depolanması ve iptali için gereken politikaları, prosedürleri ve teknolojiyi kapsayan bir çerçevedir. PKI, asimetrik kriptografinin pratikte kullanılabilmesini sağlayan güven modelini tanımlar.

X.509 Sertifika Yapısı

X.509 v3 sertifikaları, ITU-T standardı olan ASN.1 formatında DER (ikili) veya PEM (Base64) kodlamasıyla depolanır. Her sertifika, sahibi, veren CA, geçerlilik süresi, açık anahtar ve kritik uzantılar (key usage, extended key usage, SAN) içerir.

🏛️

Kök CA (Root CA)

Güven hiyerarşisinin tepesi. Sertifikaları kendi kendine imzalanmıştır (self-signed). Genellikle fiziksel olarak izole, çevrimdışı donanım güvenlik modülleri (HSM) üzerinde tutulur. Kompromi durumu tüm zinciri çökerter.

🔗

Ara CA (Intermediate CA)

Kök CA tarafından imzalanmış; son varlık sertifikalarını veren CA. Kök CA’nın çevrimdışı kalmasına olanak tanır. Çoklu ara CA’lar, farklı coğrafyalar veya hizmet türleri için yetki devri sağlar.

📄

Son Varlık Sertifikası

Sunucu, istemci veya kod imzalama için verilen son halka. Domain Validated (DV), Organization Validated (OV) veya Extended Validation (EV) doğrulama seviyelerinde gelir.

🔍

CRL / OCSP

Sertifika iptal mekanizmaları. CRL (Certificate Revocation List) büyük listeler gerektirir. OCSP (Online Certificate Status Protocol) gerçek zamanlı sorgu sağlar. OCSP Stapling, bu sorguyu sunucuya devrederek gizliliği artırır.

📌 Certificate Transparency (CT)

Certificate Transparency (RFC 6962), CA’ların verdiği tüm sertifikaları, herkes tarafından denetlenebilir halka açık günlük sunucularına (log server) kaydetmesini zorunlu kılan bir ekosistemdir. Google, 2018’den itibaren tüm güvenilen sertifikaların CT günlüklerine kaydedilmesini Chrome’da zorunlu hale getirmiştir.

Bu sistem, sahte veya kötü niyetli sertifika verilmesini tespit etmeyi mümkün kılar. SCT (Signed Certificate Timestamp) uzantısı, sertifikanın bir CT günlüğüne kaydedildiğinin kriptografik kanıtını taşır ve sertifikaya gömülür ya da TLS handshake sırasında iletilir.

PEM—–BEGIN CERTIFICATE—– # X.509 DER kodlu ikili veri, Base64 ile temsil edilmiş # Alanlar: Version: 3 (X.509v3) Serial Number: 0x04:d5:f5:84:… (CA’nın atadığı benzersiz seri) Signature Alg: sha256WithRSAEncryption veya ecdsa-with-SHA256 Issuer: CN=Let’s Encrypt R3, O=Let’s Encrypt, C=US Validity: Not Before: 2024-01-01, Not After: 2024-04-01 (90 gün) Subject: CN=www.example.com Public Key: EC Public Key (256 bit) — secp256r1 / P-256 X509v3 Extensions: Subject Alternative Names: DNS:example.com, DNS:www.example.com Key Usage: Digital Signature Extended Key Usage: TLS Web Server Authentication OCSP Responder: http://r3.o.lencr.org CT Precertificate SCTs: [Google Xenon 2024, Cloudflare Nimbus 2024] —–END CERTIFICATE—–

05

IPSec & VPN Protokolleri:
Ağ Katmanı Güvenliği

IPSec (Internet Protocol Security), IP katmanında kimlik doğrulama ve şifreleme sağlayan protokol paketidir. TLS’in uygulama katmanında çalışmasının aksine, IPSec ağ katmanında (Layer 3) çalışarak IP paketlerinin tamamını koruma altına alır. Bu özellik, onu site-to-site VPN ve uzaktan erişim senaryolarında özellikle güçlü kılar.

IPSec Protokol Bileşenleri

IPSec, birbiriyle koordineli çalışan üç temel bileşenden oluşur:

IKE (Internet Key Exchange): IKEv2, IPSec güvenlik ilişkilerini (SA — Security Association) müzakere eden ve yönetilink anahtar değişim protokolüdür. İki aşamada çalışır: Faz 1’de güvenli bir IKE tüneli kurulur; Faz 2’de IPSec SA’ları bu tünel üzerinden müzakere edilir. IKEv2, MOBIKE uzantısıyla ağ değişimlerinde (Wi-Fi → LTE) oturumu kesintisiz sürdürebilir.

AH (Authentication Header): Kimlik doğrulama ve bütünlük sağlar; ancak şifreleme sunmaz. IP başlığı dahil tüm paketi korur. NAT ortamlarında sorunludur çünkü NAT, IP başlığını değiştirerek bütünlük doğrulamasını bozar.

ESP (Encapsulating Security Payload): Hem şifreleme hem kimlik doğrulama hem de bütünlük sağlar. Tünel modunda (tunnel mode) orijinal IP paketi tamamen kapsüllenir ve yeni bir IP başlığı eklenir; bu sayede uçtan uca VPN tünelleri kurulabilir.

Protokol / Çözüm Katman Şifreleme Performans Kullanım Alanı
IPSec/IKEv2 L3 AES-256-GCM Yüksek Kurumsal VPN, mobil
WireGuard L3 ChaCha20-Poly1305 Çok Yüksek Modern VPN, IoT
OpenVPN L4 TLS üzerinden AES Orta Esnek kurumsal VPN
L2TP/IPSec L2/L3 IPSec + AES Orta Eski cihaz uyumluluğu
PPTP L2 MS-CHAPv2 / MPPE Yüksek Güvensiz / Kullanmayın
✦ WireGuard Mimarisi

WireGuard, yaklaşık 4.000 satır kodla implemente edilen modern bir VPN protokolüdür (OpenVPN’in ~600.000 satırına kıyasla). Yalnızca ChaCha20-Poly1305 (şifreleme), Curve25519 (ECDH), BLAKE2s (hash) ve SipHash24 (hash table keys) kullanır. Bu statik algoritma seçimi, konfigürasyon hatalarını elimine eder ancak kriptografik çeviklik (agility) sunmaz.

WireGuard’ın “cryptokey routing” modeli, IP adreslerini doğrudan Curve25519 açık anahtarlarına bağlar. Bağlantısız (connectionless) ve sessiz (silent) yapısı, ağ değişimlerinde kesintisiz oturum sürdürmeye ve gelişmiş ağ tespitine karşı dirence katkı sağlar.


06

Saldırı Vektörleri:
Bilinen Tehdit Modelleri

DNS ve ağ protokollerine yönelik saldırılar, pasif dinlemeden aktif manipülasyona, protokol tasarım açıklarından uygulama hatalarına kadar geniş bir saldırı yüzeyini kapsar. Bu tehditleri anlamak, etkili savunma stratejilerinin tasarlanması için önkoşuldur.

DNS Cache Poisoning (Önbellek Zehirlenmesi)

Dan Kaminsky’nin 2008’de kamuoyuna duyurduğu ve bir ay içinde milyonlarca DNS resolver’ı etkileyen kritik güvenlik açığı, DNS önbellek zehirlenmesinin ne kadar tehlikeli olabileceğini gözler önüne serdi. Saldırgan, bir resolver’ın dışarıya gönderdiği DNS sorgusuna —doğru kaynak portu ve transaction ID’yi tahmin ederek— sahte bir yanıt enjekte eder. Resolver bu yanıtı gerçek sunucudan gelen yanıt olarak kabul ederse, sahte kayıt TTL süresi boyunca önbellekte kalır ve tüm kullanıcıları yanlış IP’ye yönlendirir.

🔴 Kritik Saldırı: Kaminsky Atağı

Kaminsky atağının özgünlüğü, klasik rekursif DNS mekanizmasını kullanarak transaction ID çarpışma ihtimalini dramatik biçimde artırmasındaydı. Saldırgan, sahte NXDOMAIN yanıtlarını art arda göndererek resolver’ı kendi kontrolündeki sahte yetkili sunucuya yönlendirmeye çalışırdı. Çözüm olarak DNSSEC implementasyonu, DNS kaynak portu randomizasyonu (0–65535 arası), 0x20 kodlaması (case randomization) ve EDNS cookie uzantısı (RFC 7873) önerildi ve geniş çapta benimsendi.

DNS Tünelleme

DNS tünelleme, DNS sorgularını ve yanıtlarını veri exfiltration veya komuta-kontrol (C2) kanalı olarak kötüye kullanır. Saldırgan, kendi kontrolündeki alan adına yönelik uzun TXT, NULL veya A kayıt sorguları içine veri kodlar. Güvenlik duvarları genellikle DNS trafiğini (UDP/53) izin listesinde tutar; bu durum, sıkı ağ kontrolleri bulunan ortamlarda bile veri sızdırmaya imkân tanır.

Tespit yöntemleri arasında anormal sorgu uzunluğu analizi, yüksek sıklıklı sorgu örüntüsü tespiti, entropik alan adı analizi (Base32/Base64 kodlamalı subdomainler) ve DNS yanıt veri boyutu anomali tespiti sayılabilir.

TLS/SSL Saldırıları

BEAST (2011): TLS 1.0’da CBC mod şifrelemesinin IV (Initialization Vector) tahmin edilebilirliğini istismar eden, tarayıcı üzerinden gerçekleştirilen MITM saldırısı. TLS 1.2 ve sonrasında CBC IV tamamen rastgele seçilir.

POODLE (2014): SSL 3.0’ın CBC padding doğrulama zaafiyetini hedefleyen ve protokol düşürme (downgrade) saldırısıyla SSL 3.0’a düşürmeyi gerektiren saldırı. TLS_FALLBACK_SCSV mekanizması ve SSL 3.0’ın tamamen devre dışı bırakılması ile çözüme kavuşturuldu.

DROWN (2016): SSLv2’nin hâlâ etkin olduğu sunuculara yapılan, RSA anahtar paylaşımını hedefleyen ve TLS oturumlarını SSLv2 handshake saldırıları ile çözmeye çalışan karmaşık bir saldırı. SSLv2 devre dışı bırakılmasıyla engellendi.

Renegotiation Saldırısı (2009): TLS renegotiation mekanizmasını kullanarak istemci kimlik doğrulaması yapılmış oturumlara veri enjekte eden saldırı. RFC 5746 ile güvenli renegotiation uzantısı standartlaştırıldı; TLS 1.3 renegotiation’ı tamamen kaldırdı.

🎭

BGP Hijacking

Saldırgan, yanlış BGP duyuruları yaparak IP bloklarının trafiğini kendi ağı üzerinden geçirir. 2018’deki MyEtherwallet olayında, Route53 DNS trafiği BGP hijacking ile kötü amaçlı sunuculara yönlendirildi.

🔌

DNS DDoS Amplification

ANY sorgu tipi veya büyük DNS yanıtları, küçük sorgulara karşılık büyük yanıtlar döndürür (amplification faktörü 50-100x). Sahte kaynak IP ile kurban hedefe yönlendirilir. Response Rate Limiting (RRL) savunma yöntemidir.

🔓

SSL Stripping

MITM konumundaki saldırgan, HTTPS bağlantılarını HTTP’ye düşürür. İstemci HTTP üzerinden sunucuyla iletişim kurar; saldırgan HTTPS kullanarak gerçek sunucuya bağlı kalır. HSTS ve HSTS Preloading ile engellenir.

🕵️

Typosquatting / Homograph

Görsel olarak benzer alan adları (bаnk.com — Kiril ‘а’ ile) veya yazım hatalı alan adları kullanılarak kullanıcılar kandırılır. Certificate Transparency izleme ve IDN homograph politikaları savunma katmanı oluşturur.


07

Modern Yaklaşımlar:
Gizlilik ve Post-Kuantum Güvenlik

Ağ güvenliği, durağan bir disiplin değildir. Kuantum hesaplama tehditleri, gizlilik gereksinimleri ve artan saldırı karmaşıklığı, protokollerin ve standartların sürekli evrimini zorunlu kılmaktadır. Günümüzde araştırma ve standardizasyon çalışmaları post-kuantum kriptografiye yoğunlaşmaktadır.

DNS-over-HTTPS (DoH) ve DNS-over-TLS (DoT)

Geleneksel DNS, UDP/53 üzerinden düz metin olarak iletilir. İSS’ler ve ağ ortadaki adamlar (MITM), sorgulanan alan adlarını kolaylıkla izleyebilir. DoH (RFC 8484) ve DoT (RFC 7858), DNS sorgularını TLS şifrelemesi altına alarak bu gizlilik açığını kapatır.

DoH, standart HTTPS trafiğiyle (443/tcp) karıştığı için ağ düzeyinde engellenmesi zordur; ancak DNS trafiğini web trafiğiyle harmanlayarak ağ yöneticilerinin görünürlüğünü azaltır. DoT, 853/tcp portunu kullanır; bu öngörülebilirlik, kurumsal ağlarda politika uygulamayı kolaylaştırır. DoQ (DNS-over-QUIC, RFC 9250), en yeni geliştirme olup QUIC’in düşük gecikme avantajlarını DNS’e taşır.

Post-Kuantum Kriptografi (PQC)

Shor algoritmasını çalıştırabilen yeterince güçlü bir kuantum bilgisayarı, mevcut RSA ve ECC tabanlı açık anahtar şifrelemesini kırabilir. Bu tehdit, “Harvest Now, Decrypt Later” (HNDL) saldırısı olarak somutlaşır: Saldırganlar şifreli trafiği depolayıp gelecekte kuantum bilgisayarlarla çözmeyi hedefler.

NIST, 2022’de PQC standart adaylarını seçti. ML-KEM (CRYSTALS-Kyber — FIPS 203) anahtar enkapsülasyonu için; ML-DSA (CRYSTALS-Dilithium — FIPS 204) ve SLH-DSA (SPHINCS+ — FIPS 205) dijital imzalar için standartlaştırıldı. TLS 1.3, hibrit anahtar değişimini (X25519 + ML-KEM768) desteklemek üzere genişletilmektedir.

Gizlilik Teknolojisi Koruma Alanı Standart Olgunluk
DoH (DNS-over-HTTPS) DNS sorgu gizliliği RFC 8484 Yaygın
DoT (DNS-over-TLS) DNS sorgu gizliliği RFC 7858 Yaygın
ESNI / ECH SNI gizliliği (hangi siteye bağlanıldığı) TLS WG Draft Gelişiyor
HSTS Preloading SSL Stripping önleme IETF Draft Yaygın
ML-KEM (Kyber) Post-kuantum anahtar değişimi NIST FIPS 203 Erken Benimseme
Hibrit KEM (X25519+Kyber) TLS geçiş dönemi PQC TLS WG Draft Pilot
Certificate Transparency Sahte sertifika tespiti RFC 6962 / 9162 Zorunlu

Encrypted Client Hello (ECH)

TLS 1.3’te Client Hello mesajı, sunucu sertifikası olmadan şifrelenemez; bu nedenle SNI (Server Name Indication) alanı —hangi domain’e bağlanıldığı bilgisi— açık metin olarak iletilir. Ağ izleme araçları ve İSS’ler bu bilgiyi görebilir. ECH, genel bir anahtar kullanarak içteki (inner) Client Hello’yu şifreler. Dış (outer) Client Hello yalnızca bir “kapı tutucu” sunucu adı içerir; gerçek hedef şifreli biçimde aktarılır. Bu mekanizma, TLS tabanlı gözetlemenin en kritik kör noktasını kapatmayı hedefler.

Zero Trust Ağ Mimarisi

Geleneksel “dışarı güvenme, içeri güven” modeli, bulut geçişi ve uzaktan çalışma paradigmasıyla işlevsiz hale gelmiştir. Zero Trust Architecture (NIST SP 800-207), her erişim isteğinin —kaynağından bağımsız olarak— kimlik doğrulama, yetkilendirme ve sürekli doğrulamaya tabi tutulmasını öngörür. DNS, Zero Trust uygulamalarında kritik bir enforsman noktası olarak öne çıkar: DNS sorguları, erişim politikalarını uygulamak ve anormal davranışları tespit etmek için analiz edilir.

🔬 Öneri: Güvenli DNS Altyapısı Kontrol Listesi

DNS: DNSSEC imzalama, CAA kaydı ekleme, DNS zone transfer erişim kısıtlaması (AXFR kontrolü), Response Rate Limiting (RRL), DoT/DoH resolver kullanımı, anycast tabanlı yetkili DNS altyapısı.

TLS: Yalnızca TLS 1.2 ve 1.3 izin ver; zayıf şifre paketlerini devre dışı bırak (RC4, 3DES, NULL); HSTS başlığı ve preloading; OCSP Stapling; CT zorunluluğu; PFS şifre paketi önceliklendirmesi (ECDHE önce).

Genel: BGP prefix filtreleme (RPKI implementasyonu), ağ segmentasyonu, DNS sink-holing, IDS/IPS kurallarında DNS anomali tespiti, güvenlik açığı tarama ve patch yönetimi süreçleri.

DNSSEC TLS 1.3 ECH DoH / DoT ML-KEM WireGuard IKEv2 X.509 OCSP Stapling Certificate Transparency Zero Trust BGP / RPKI HSTS Preloading Post-Quantum