DNS over HTTPS (DoH) ve DNS over TLS (DoT) Nedir? Gizlilik, Güvenlik ve Hosting Altyapısına Etkileri

DNS Trafiği Neden Bu Kadar Önemli Hale Geldi?

Son yıllarda herkes HTTPS’e, güçlü şifrelere ve iki adımlı doğrulamaya odaklandı; ama çoğu projede gözden kaçan kritik bir katman var: DNS. Tarayıcı çubuğuna bir alan adı yazdığınız anda ilk giden istek DNS sorgusu ve bu istek, varsayılan hâliyle şifrelenmemiş bir şekilde ağınızda dolaşıyor. Dolayısıyla biri DNS trafiğinizi okuyabiliyorsa, hangi sitelere gittiğinizi, hangi API’leri kullandığınızı ve kimi zaman hangi hizmetlere bağlandığınızı net biçimde görebiliyor.

DCHost tarafında yaptığımız güvenlik denetimlerinde şunu sık görüyoruz: Web uygulaması tarafında HSTS, güçlü TLS ayarları, WAF ve rate limiting gibi pek çok önlem alınmış oluyor ama DNS hala klasik, düz UDP/53 trafiğiyle işliyor. Bu, hem gizlilik hem de bütünlük açısından ciddi bir açık kapı. DNS over HTTPS (DoH) ve DNS over TLS (DoT) tam da bu noktada devreye giriyor. Bu iki teknoloji, DNS trafiğini TLS tüneli içine alarak sorgu içeriklerini gizliyor ve araya girme (MITM) saldırılarını zorlaştırıyor.

Bu yazıda DoH ve DoT’un ne olduğunu, nasıl çalıştığını, hangi saldırılara karşı koruma sağladığını ve DCHost üzerinde yönettiğiniz hosting, VPS, dedicated sunucu veya colocation altyapınıza pratikte ne ifade ettiğini adım adım konuşacağız. Ayrıca kendi DoH/DoT resolver’ınızı kurmak istediğinizde dikkat etmeniz gereken mimari ayrıntılara da değineceğiz.

DNS Temelleri: Üstüne Ne Eklediğimizi Bilmek

DoH ve DoT’u anlamak için önce klasik DNS’in nasıl çalıştığını kafada netleştirmek gerekiyor. DNS’i zaten kullanıyorsunuz ancak çoğu zaman farkında olmadan.

Detaylı bir hatırlatma isteyenler için şu rehber iyi bir temel sunuyor: A, AAAA, CNAME, MX, TXT ve SRV kayıtlarının ne işe yaradığını anlattığımız DNS kayıtları rehberi. Buradaki mekanizma özetle şöyle işler:

• İstemci (tarayıcı, sunucu, uygulama) bir alan adı için DNS sorgusu üretir.
• Bu sorgu genellikle UDP/53 veya TCP/53 üzerinden çözümleyici DNS sunucuya gider.
• Çözümleyici gereken yerleri (root, TLD, authoritative) sorarak IP adresini bulur ve size döner.

Bu sürecin tamamı düz metin şeklinde ilerler; yani ağdaki biri, ISS’niz, açık Wi‑Fi yöneticisi veya saldırgan, bu paketleri okuyup üzerinde oynayabilir. DNSSEC gibi teknolojiler, yanıtın yetkili kaynaktan gelip gelmediğini kriptografik olarak doğrulamaya odaklanır; ancak sorgunun kendisi hâlâ şifresiz taşınır. DNSSEC’i detaylı incelemek isterseniz DNSSEC nedir ve alan adınız için nasıl etkinleştirilir rehberimize göz atabilirsiniz.

DoH ve DoT tam bu noktaya ek bir katman getiriyor: DNS trafiğini de TLS ile sarmalamak.

DNS over HTTPS (DoH) Nedir?

DNS over HTTPS, adından da anlaşılacağı üzere, DNS sorgularını klasik UDP/53 yerine HTTPS üzerinden taşıyan bir protokoldür. Yani tarayıcınız veya işletim sisteminiz, DNS sorgusunu alıp bir HTTPS isteğinin gövdesine koyar, TLS oturumu içinde sunucuya gönderir, yanıtı yine HTTPS üzerinden alır. Dışarıdan bakıldığında bu trafik, sıradan bir HTTPS isteği gibi görünür.

DoH’un Çalışma Mantığı

Tipik bir DoH akışını sadeleştirirsek:

1. İstemci, DoH kullanan bir DNS çözümleyici adresi (örn. https://resolver.ornek.net/dns-query) bilir.
2. Tarayıcı veya işletim sistemi, DNS sorgusunu ya JSON ya da ikili DNS wire formatında HTTP isteğinin içine gömer.
3. Bu istek, TLS ile şifrelenmiş HTTPS bağlantısı üzerinden, genellikle 443 numaralı porttan gider.
4. DoH sunucusu isteği çözer, DNS yanıtını yine HTTPS gövdesi içinde geri yollar.

Buradaki kritik nokta, tüm DNS içeriğinin (sorgu ve yanıt) TLS tüneli içinde gizlenmesidir. Aradaki yönlendiriciler, ISS, Wi‑Fi noktası veya yerel saldırgan, bu paketin sadece “HTTPS trafiği” olduğunu görür; hangi alan adını sorduğunuzu göremez.

DoH’un Avantajları

• Gizlilik: Açık Wi‑Fi veya kurumsal ağda DNS sorgularınızın okunmasını zorlaştırır.
• Sansür ve manipülasyona direnç: DNS sorgularının içerik temelli filtrelenmesini zorlaştırır, sahte cevap enjekte etmeyi güçleştirir.
• HTTPS altyapısından yararlanma: HTTP/2, HTTP/3 ve mevcut TLS optimizasyonları (ALPN, multiplexing vb.) ile iyi performans verebilir.
• Firewall’lar için ayırt edilmesi zor trafik: Çoğu ağ cihazı 443 portundan geçen DoH trafiğini “normal web” trafiğinden kolayca ayıramaz.

DoH’un Sınırlamaları

• Merkeziyet riski: Tüm DNS trafiğinizi tek bir harici DoH sunucusunda toplarsanız, gizliliği ISS’den alıp bu sağlayıcıya devretmiş olursunuz.
• Kurumsal politika zorlukları: Kurumsal ağlar, iç DNS bölgeleri ve loglama politikalarını yönetmekte zorlanabilir; çünkü istemciler kendileri dışarıdaki bir DoH sunucusuna çıkabilir.
• Gecikme: Kötü yapılandırılmış bir DoH altyapısı, her sorgu için fazladan TLS el sıkışması ve HTTP katmanı ekleyerek TTFB’yi artırabilir.

DNS over TLS (DoT) Nedir?

DNS over TLS, DNS trafiğini doğrudan TLS tüneli içine alan bir başka şifreli DNS yöntemidir. DoH’tan farkı, HTTP katmanını kullanmamasıdır. DNS protokolünün kendisi, TCP veya QUIC yerine TLS ile sarılır ve genellikle 853 numaralı port üzerinden çalışır.

DoT’un Çalışma Mantığı

Basitleştirirsek:

1. İstemci, DoT destekleyen bir çözümleyici DNS sunucusunun IP adresini ve portunu (çoğunlukla 853) bilir.
2. Arada TLS el sıkışması yapılır, güvenli bir kanal kurulur.
3. İstemci DNS sorgularını bu TLS tüneli üzerinden klasik DNS wire formatıyla gönderir.
4. Sunucu yanıtı yine aynı tünelden geri yollar.

DoT, özellikle işletim sistemi seviyesinde veya ağ geçidi seviyesinde (örneğin router’larda) tercih edilen bir yöntemdir; çünkü HTTP katmanı olmadan, doğrudan DNS protokolü üzerinde çalışır ve yönetmesi bazı senaryolarda daha nettir.

DoH ve DoT Arasındaki Farklar

Özetle, DoH daha çok uygulama seviyesinde gizlilik ve engel aşma senaryolarında, DoT ise ağ ve işletim sistemi seviyesinde güvenli DNS altyapısı kurmak için tercih ediliyor.

Gizlilik Perspektifi: Kim Ne Görebiliyor?

Şifreli DNS konuşurken en çok karıştırılan noktalardan biri, kimin neyi görebildiği. DoH/DoT kullandığınızda nelerin gizlendiğini ve nelerin hâlâ görünür kaldığını netleştirelim.

• Gizlenen: Hangi alan adları için DNS sorgusu yaptığınız, aldığınız DNS yanıtları, TTL gibi detaylar.
• Gizlenmeyen: Hangi IP adresine TCP/TLS bağlantısı kurduğunuz, paket boyutları, zamanlama bilgisi ve çoğu durumda SNI / ECH durumu.

Yani ISS veya ağ yöneticisi, hangi DoH/DoT sunucusuna bağlandığınızı görmeye devam eder; ancak bu sunucuya sorduğunuz alan adlarını doğrudan okuyamaz. Öte yandan, sonrasında bağlandığınız web sitelerinin IP adresleri yine trafiğe yansır. TLS 1.3 ve Encrypted Client Hello (ECH) gibi teknolojiler gelişse de henüz her yerde zorunlu değil.

KVKK ve GDPR gibi düzenlemeler açısından bakarsak, DNS logları genellikle kişisel veri kapsamında değerlendirilmeye başlandı. DCHost tarafında hosting ve e-posta altyapısında log saklama süreleri ile KVKK ve GDPR uyumlu hosting stratejisi yazılarında detaylandırdığımız gibi, hangi logu ne kadar tuttuğunuz, kimin erişebildiği, nerede sakladığınız hukuki olarak önemli. DoH/DoT, bu logların bir kısmını yerel ağdan alıp seçtiğiniz DNS sağlayıcısına taşır; dolayısıyla gizlilik dengesini yeniden kurmanız gerekir.

Güvenlik Perspektifi: Hangi Problemi Çözer, Hangisini Çözmez?

DoH/DoT çoğu zaman “DNS güvenliği” başlığı altında anlatılır; ama hangi riskleri azalttığı, hangilerine dokunmadığı net olmalı.

Çözdüğü veya Azalttığı Riskler

• Pasif izleme: Aynı ağa bağlı bir saldırgan, DNS sorgularınızı koklayarak hangi sitelere gittiğinizi öğrenemez.
• DNS spoofing / poisoning (bazı senaryolar): ISS tarafında veya aradaki bir cihazda DNS yanıtına müdahale etmek, TLS doğrulaması nedeniyle zorlaşır; kayıtları manipüle etmek için çözümleyici seviyesine sızmak gerekir.
• Captive portal dışı manipülasyonlar: Bazı ağlar, belirli alan adlarını sahte IP’ye yönlendirme yöntemleri kullanıyordu; bu tür müdahaleler DoH/DoT ile daha zor hâle gelir.

Çözmediği Riskler

• Zararlı sitenin kendisi: DNS trafiği şifreli olsa da, ziyaret ettiğiniz sitenin zararlı olup olmadığı değişmez. WAF, antivirüs, tarayıcı korumaları hâlâ gerekli.
• İçerik filtreleme: Aile profilleri, kurumsal URL filtreleri gibi mekanizmalar DoH kullanan istemciler tarafından atlatılabilir. Bu, hem avantaj hem risk.
• Yetkili DNS sunucusuna saldırı: DoH/DoT, authoritative DNS sunucunuzu DDoS’a veya zone transfer sızıntılarına karşı korumaz; bunlar için ayrı tedbirler gerekir.

Buradan önemli bir sonuç çıkıyor: DoH/DoT, DNSSEC’in alternatifi değil, tamamlayıcısıdır. DNSSEC yanıtın doğruluğunu ve kaynağını imzalar; DoH/DoT ise bu trafiğin ağ üzerinde gizlenmesini sağlar. Güçlü bir DNS güvenlik mimarisinde ikisini birlikte düşünmek mantıklıdır.

Hosting ve Sunucu Altyapısına Etkileri

Gelelim DCHost perspektifinde bizi en çok ilgilendiren kısma: DoH/DoT’un hosting, VPS, dedicated sunucu ve colocation altyapılarına etkisi.

1. paylaşımlı hosting ve Web Siteleri Açısından

Paylaşımlı hosting kullanan tipik bir web sitesi sahibi için DoH/DoT, ilk bakışta “istemci tarafı”nda gerçekleşen bir yenilik gibi görünebilir. Fakat dolaylı etkileri var:

• CDN ve coğrafi yönlendirme: Bazı DNS sağlayıcıları, IP tabanlı coğrafi yönlendirme için EDNS Client Subnet gibi mekanizmalar kullanır. DoH/DoT kullanan bazı çözümleyiciler, gizlilik amacıyla bu bilgiyi göndermeyebilir. Bu da ziyaretçinin en yakın CDNe yönlendirilmesini zorlaştırabilir. Bu durum, DNS yayılımı ve coğrafi yönlendirme davranışını anlattığımız yazıyla birlikte değerlendirilmelidir.
• Hata teşhisi: DNS kaynaklı bir sorun yaşandığında, kullanıcının tarayıcısı veya işletim sistemi harici bir DoH sağlayıcısına gidiyorsa, siz hosting tarafında nameserver’larınızı doğru görseniz bile, kullanıcı farklı bir kaynaktan sorun yaşıyor olabilir. Destek süreçlerinde “hangi DNS’i kullanıyorsunuz?” sorusu daha kritik hâle gelir.

2. VPS ve Dedicated Sunucularda DNS Mimarisi

VPS veya dedicated sunucu kullandığınızda, elinizde çok daha esnek bir alan olur. Kendi DNS çözümleyicinizi kurabilir, DoT/DoH destekleyen bir DNS cache sunucusu ayağa kaldırabilir ve tüm iç trafiğinizi bu sunucu üzerinden koşturabilirsiniz.

DCHost üzerinde yönettiğiniz bir VPS/dedicated sunucuda tipik bir senaryo şöyle olabilir:

• Sunucu üzerinde yerel bir caching resolver çalıştırırsınız.
• Bu resolver, dış dünyaya DoT üzerinden bağlanır ve DNS trafiği tamamen şifreli çıkar.
• Uygulamalarınız (web sunucuları, API’ler, arka plan işler) bu yerel resolver’i kullanır; hem gecikme azalır hem de DNS trafiği ağ dışına çıkarken güvenlik kazanır.

Böylece hem DoT/DoH’un gizlilik avantajından yararlanır, hem de DNS çözümleme performansını kontrol altına almış olursunuz. Özellikle mikrosaniye seviyesinde dahi gecikmenin kritik olduğu yüksek trafikli projelerde, TTFB ve genel sayfa hızını doğru ölçmeyi anlattığımız rehberle birlikte bu DNS katmanını da izlemeniz önemlidir.

3. Kurumsal Ağlar, Ajanslar ve Çoklu Müşteri Mimarileri

Ajanslar, SaaS sağlayıcıları veya çok kiracılı yapılar için DNS, sadece “alan adını IP’ye çeviren mekanizma” değil; aynı zamanda erişim politikalarını, iç/dış bölge ayrımını ve loglamayı yönettikleri kritik bir katmandır. DoH/DoT burada iki ucu keskin bıçak olabilir:

• Artı: Müşteri tarafında, özellikle uzaktan çalışan ekipler ve ev-ofis bağlantıları için gizli DNS trafiği, müşteri verilerinin ISS veya misafir Wi‑Fi üzerinden sızmasını zorlaştırır.
• Eksi: Kurumsal ağ içinde istemciler kendi başlarına dış DoH hizmetlerine giderse, iç DNS kayıtlarınız (ör. intranet.local) ve split-horizon mimarileriniz bozulabilir; aynı zamanda URL filtreleme ve denetim loglarınız seyrekleşir.

Bu nedenle, DCHost olarak önerimiz, kurumsal yapılarda merkezî, kurumsal bir DoT/DoH çözümleyici ayarlayıp istemcileri buna yönlendirmek; rastgele harici DoH kullanımını ise politika düzeyinde kontrol etmektir.

Gerçek Senaryolar: Hangi Durumda DoH/DoT Mantıklı?

Senaryo 1: Freelance Geliştirici ve Kamusal Wi‑Fi

Birçok freelance geliştirici, müşterisiyle toplantıdan toplantıya koşarken kafelerde veya paylaşımlı ofislerde çalışıyor. Bu ortamlarda Wi‑Fi ağının kim tarafından nasıl yönetildiğini bilemezsiniz. Şifreli DNS kullanmak, özellikle müşteri projelerinin panel adresleri, staging alan adları veya özel API uç noktalarının ağ yöneticisi tarafından görülmesini zorlaştırır. DoH/DoT, VPN ile birlikte kullanıldığında bu gizlilik katmanını daha da güçlendirir.

Senaryo 2: E‑Ticaret Sitesi ve Çoklu Sunucu Mimarisi

Orta ölçekli bir e‑ticaret sitesini, DCHost üzerinde birkaç VPS ve/veya dedicated sunucu ile çalıştırdığınızı düşünün. Uygulama sunucuları, veritabanı replikaları, cache katmanı ve harici servislerle konuşan cron job’larınız var. Burada, tüm sunucuların merkezî bir DoT destekli resolver kullanması:

• DNS sorgularının dışarı çıkarken gizli ve bütünlüklü olmasını sağlar,
• DNS tabanlı MITM risklerini azaltır,
• Tek bir noktada DNS loglarını izleyip anomali tespiti yapmanızı kolaylaştırır.

Böylece hem güvenliği artırır hem de olası bir DNS sorunu olduğunda hangi katmanda aksama yaşandığını daha rahat teşhis edersiniz.

Senaryo 3: Ajans ve Onlarca Müşteri Sitesi

Bir ajans olarak DCHost üzerinde onlarca WordPress ve e‑ticaret sitesini yönetiyorsanız, müşterilerinizin kendi lokal ağlarında ne tür DNS politikaları olduğuna hâkim olmayabilirsiniz. Bazı müşteriler kurumsal filtreler, bazıları ise agresif antivirus yazılımları kullanıyor olabilir. Bu durumda, kendi tarafınızda DNS’i sağlam kurmak kadar, ajanslar için DNS ve alan adı erişim yönetimi rehberimizde anlattığımız gibi, alan adlarını ve nameserver’ları da kontrollü yönetmek önemlidir. DoH/DoT burada, özellikle ajans içi ofis ağınızda çalışan ekipler için ek bir gizlilik katmanı sunabilir.

DoH/DoT Kullanırken Dikkat Etmeniz Gereken Noktalar

1. Gözlemlenebilirlik ve Loglama

DoH/DoT devreye girdiğinde, ağ cihazlarınızın (firewall, IDS/IPS, proxy) gördüğü DNS verisi azalır. Bu, gizlilik için güzel; fakat güvenlik izleme için zorlayıcı olabilir. Eğer kendi DoH/DoT resolver’ınızı kuruyorsanız:

• DNS sorgu loglarını KVKK/GDPR uyumlu şekilde, sınırlı sürelerle saklayın.
• Loglara sadece yetkili kişilerin erişebildiğinden emin olun.
• Anomali tespiti (çok sayıda NXDOMAIN, şüpheli domain’ler) için temel alarmlar kurun.

2. Performans ve Önbellek Kullanımı

Her DNS sorgusu için ayrı TLS el sıkışması yapıp HTTP bağlantısı açarsanız, özellikle yüksek trafiğe sahip uygulamalarda performans kaybı yaşarsınız. Burada üç kritik nokta var:

• Keep‑alive: Hem DoH hem DoT için uzun ömürlü bağlantılar kullanmaya çalışın.
• Önbellekleme: Resolver tarafında agresif ama RFC’lere uygun cache ayarları yapın; TTL’lere saygı duyun.
• Yerel resolver: Uygulamalarınızın, OS seviyesinde yerel bir resolver’a (ör. 127.0.0.1) soru sorması, DNS gecikmesini ciddi şekilde azaltır.

3. Kurumsal Politikalar ve Harici DoH Engelleme

Kurumsal ağlarda çoğu zaman içerik filtreleme, loglama ve yasal yükümlülükler nedeniyle DNS trafiğinin belirli bir yerden geçmesi istenir. Harici DoH servislerine doğrudan giden istemciler, bu politikayı by‑pass etmiş olur. Böyle durumlarda:

• Ağ seviyesinde sadece kendi DoH/DoT sunucularınıza giden trafiğe izin vermek,
• Tarayıcılarda ve işletim sistemlerinde kurumsal DoH/DoT endpoint’lerini policy ile dağıtmak,
• Gerekirse 443 portunda bilinen DoH host’larına giden trafiği incelemek

gibi tedbirler alınabilir. Özetle amaç, şifreli DNS’i yasaklamak değil, yönetilebilir hâle getirmektir.

Kendi DoH/DoT Resolver’ınızı Kurmak: Yüksek Seviyeli Yol Haritası

DCHost müşterilerinin sık sorduğu sorulardan biri şu: “Kendi DoH/DoT resolver’ımızı DCHost’ta çalıştırabilir miyiz?” Teknik olarak evet; hatta birçok senaryoda oldukça mantıklı. Yüksek seviyede izlenecek adımlar şöyle:

1. Uygun bir VPS veya dedicated sunucu seçin: DNS resolver işlemleri CPU açısından hafif, fakat bellek ve ağ açısından yoğun olabilir. Orta seviye bir DCHost VPS çoğu kurum için fazlasıyla yeterli olur.
2. DNS çözümleyici yazılımı kurun: Açık kaynak ve ticari pek çok DNS cache/recursive sunucu mevcut. Seçiminizde DNSSEC doğrulama, DoT/DoH desteği ve loglama seçeneklerini dikkate alın.
3. TLS sertifikası alın: Klasik ns.example.com gibi bir host adına Let’s Encrypt veya kurumsal CA üzerinden sertifika çıkarın. Bu konuda Let’s Encrypt ile ücretsiz SSL sertifikası kurulum rehberimiz size iyi bir temel verecektir.
4. DoT ve DoH endpoint’lerini yapılandırın: DoT için genellikle 853 portunu, DoH için ise /dns-query gibi bir endpoint’i kullanırsınız. HTTP/2 ve HTTP/3 desteğini mümkünse aktif edin.
5. İstemcileri bu resolver’a yönlendirin: Sunucularınızın /etc/resolv.conf ayarlarını, istemci cihaz DNS ayarlarını ve tarayıcı DoH konfigürasyonlarını bu yeni resolver’a işaret edecek şekilde güncelleyin.

Bu yaklaşım, ISS veya üçüncü taraf sağlayıcıların görebildiği DNS verisini minimuma indirir; trafiği kontrol edebildiğiniz bir DCHost sunucusuna taşımış olursunuz.

Tarayıcı ve İşletim Sistemlerinde DoH/DoT Nasıl Aktif Edilir?

Her tarayıcının ve işletim sisteminin arayüzü farklı olduğu için tek tek ekran görüntüsü yerine, prensipleri anlatmak daha doğru olacak.

Modern Tarayıcılarda

• Ayarlar / Gizlilik ve Güvenlik / DNS veya Güvenli DNS bölümlerinde “HTTPS üzerinden DNS” gibi seçenekler bulunur.
• Çoğu tarayıcı iki mod sunar: “Otomatik” (support eden ISS veya OS resolver’ı DoH kullanıyorsa ona uyar) ve “Özel sağlayıcı” (elle DoH URL’si girersiniz).
• Kurumsal ortamlarda, bu ayarlar genellikle policy (group policy, enterprise policy) ile merkezi olarak yönetilebilir.

İşletim Sistemlerinde

• Masaüstü işletim sistemleri: Yeni nesil sürümlerde “şifreli DNS” veya “güvenli DNS” seçenekleri gömülü hâle geldi. Genelde ağ adaptörü veya DNS ayarlarında bu tercih yapılabiliyor.
• Mobil işletim sistemleri: Özel DNS (Private DNS) alanında DoT hostname’i yazarak tüm cihaz trafiğini şifreli DNS üzerinden geçirebiliyorsunuz.
• Router ve gateway’ler: Bazı modern router’lar doğrudan DoT/DoH destekliyor; yoksa router üzerinde çalışan küçük bir VPS veya container ile bu görev üstlenilebilir.

DNS, Nameserver ve Taşıma Stratejileriyle Birlikte Düşünmek

DoH/DoT tek başına ele alınmamalı; alan adı, nameserver ve TTL stratejinizle birlikte planlanmalı. Örneğin Cloudflare DNS mi, hosting DNS’i mi kullanmanız gerektiğini tartıştığımız yazıda da anlattığımız gibi, hangi katmanda kontrol istediğiniz çok önemli.

Aynı şekilde, uygulama veya altyapı taşıması yaparken, DoH/DoT’u aktif kullanmanız TTL stratejileriyle zero‑downtime taşıma planlarınızı etkilemez; çünkü authoritative DNS tarafı aynı kalır. Ancak son kullanıcı tarafında kullanılan çözümleyicilerin önbellek davranışı ve DoH/DoT destekleri, fiili yayılım süresini etkileyebilir.

DCHost Perspektifi: Nasıl Bir Yol Haritası Öneriyoruz?

DCHost ekibi olarak, DNS güvenliğini katmanlı bir yaklaşım olarak ele alıyoruz. Pratikte önerdiğimiz yol haritası şöyle:

• Alan adınız için DNSSEC etkinleştirin: Böylece DNS kayıtlarınızın yetkili kaynaktan geldiğini kriptografik olarak ispatlarsınız.
• Nameserver ve TTL stratejinizi netleştirin: Taşıma, failover ve bakım süreçlerinde nasıl davranacağınıza baştan karar verin.
• Sunucu tarafında güvenli bir resolver kullanın: VPS veya dedicated sunucularınızda, en azından DoT ile dış dünyaya çıkan bir cache resolver tercih edin.
• Geliştirici ve yöneticiler için DoH/DoT profilini standardize edin: Özellikle yönetim panelleri ve SSH erişimi gibi kritik noktalarda kullanılan istemcilerin DNS gizliliği ve bütünlüğünü artırın.
• Loglama ve KVKK/GDPR uyumunu birlikte düşünün: DNS loglarını nerede tuttuğunuzu, kimlerin eriştiğini ve ne kadar süre sakladığınızı yazılı hâle getirin.

DCHost üzerinde barındırdığınız projelerde, ister paylaşımlı hosting, ister NVMe destekli VPS, ister yüksek kaynaklı dedicated sunucu veya colocation kullanın; DNS katmanını güçlendirmek, toplam güvenlik modelinizin çok maliyeti düşük ama getirisi yüksek bir parçası olacak.

Özet ve Sonraki Adımlar

DNS over HTTPS (DoH) ve DNS over TLS (DoT), son yıllarda “gizlilik ve güvenlik” başlığı altında en çok konuşulan iki teknoloji hâline geldi. Temel farkı netleştirecek olursak: DoH, DNS sorgularını HTTP/2 veya HTTP/3 üzerinden, klasik web trafiği gibi taşıyor; DoT ise doğrudan TLS tünelinde, DNS’e özel bir port üzerinden iletişim kuruyor. İkisi de DNS sorgu ve yanıtlarını ağ üzerindeki meraklı gözlerden gizliyor, araya girme saldırılarını zorlaştırıyor.

Ancak hiçbirisi tek başına mucize çözüm değil. DNSSEC, güçlü TLS ayarları, WAF, loglama, yedekleme ve izleme olmadan sadece DoH/DoT kullanmak, resmin küçük bir parçasına odaklanmak anlamına gelir. DCHost tarafında biz, bu teknolojileri; alan adı yönetimi, nameserver stratejisi, TT L planlaması ve güvenlik politikalarıyla birlikte ele almayı tercih ediyoruz.

Eğer siz de:

• Kendi DoH/DoT resolver’ınızı DCHost VPS veya dedicated sunucuda ayağa kaldırmak,
• Mevcut hosting altyapınızda DNS güvenliğini katmanlı şekilde güçlendirmek,
• KVKK/GDPR uyumlu log saklama ve DNS mimarisi tasarlamak

istiyorsanız, teknik ekibimizle birlikte mimarinizi gözden geçirebiliriz. Alan adı, DNS, hosting, VPS, dedicated sunucu ve colocation ihtiyaçlarınızı; şifreli DNS, DNSSEC, HTTP/2/3 ve modern güvenlik standartlarıyla uyumlu, sürdürülebilir bir bütün olarak tasarlamak mümkün. Bir sonraki adım olarak DNS kayıtlarınızı ve mevcut nameserver yapınızı inceleyerek başlanabilir; sonrasında DoH/DoT stratejinizi buna göre şekillendirirsiniz.