DNS Nasıl Çalışır? Çözümleme, Resolver, DNSSEC ve DoH Rehberi

DNS sorgusu adım adım nasıl çözülür? Browser/OS/resolver cache, iterative vs recursive query, root + TLD + authoritative nameserver hiyerarşisi, UDP/TCP/EDNS0/DoH/DoT/DoQ protokolleri, DNSSEC zinciri, anycast resolver, public DNS karşılaştırması ve dig/nslookup ile troubleshoot — Buyukweb cPanel ve VDS perspektifiyle teknik referans.

Büyükweb Editör EkibiHosting, Sunucu ve Sistem Yönetimi Editörü16 Aralık 202434 dakika okumaGüncellendi · 11 Mayıs 2026

DNS Nasıl Çalışır? Çözümleme, Resolver, DNSSEC ve DoH Rehberi

buyukweb.com.tr yazıp Enter'a bastığınız andan sayfanın yüklenmeye başladığı ana kadar geçen sürede, arka planda en az yedi farklı önbellek katmanı, iki ila on arası farklı sunucuyla iletişim ve potansiyel olarak şifrelenmiş bir protokol değişimi gerçekleşir. Çoğu zaman bu sürecin tamamı 20-80 milisaniye içinde tamamlanır; bazen ise 2-3 saniyeye uzayabilir. Aradaki fark "DNS nasıl çalışır" sorusunun cevabını bilen ile bilmeyenin yaptığı kurulum farkıdır.

Bu rehber, sıradan bir "DNS internetin telefon rehberidir" cümlesinin ötesine geçiyor. Bir sistem yöneticisinin veya bilinçli bir hosting müşterisinin bilmesi gereken resolution mekaniğini adım adım, paket seviyesinde anlatıyor: stub resolver ile recursive resolver arasındaki fark, iterative ve recursive sorgu modları, UDP 53 - TCP 53 - EDNS0 - DoH - DoT - DoQ protokol stack'i, browser ve OS cache'inin TTL davranışı, kök sunucu (root) - TLD - authoritative hiyerarşisi, DNSSEC güven zinciri (KSK/ZSK/DS/RRSIG), anycast altyapı, public resolver karşılaştırması ve dig +trace ile sorgu izleme. Kayıt türleri (A/AAAA/CNAME/MX/TXT/SVCB/HTTPS) sadece akış için referans alınır; tüm detay için ayrı DNS kayıtları hub yazımız vardır.

Buyukweb perspektifi: Bursa Tier 3 veri merkezimizdeki cPanel hosting paketlerinde DNS Zone Editor ve ileri zone editor (TXT/SRV/CAA/HTTPS dahil) sunuyoruz; reseller müşterilerimize WHM DNS Zone Manager üzerinden tam authoritative DNS yönetimi açıyoruz. VDS sunucularımızda root erişim tam olduğu için Unbound, BIND, PowerDNS, Knot DNS gibi recursive veya authoritative çözümleri serbestçe kurabilirsiniz. 0850 302 60 70 destek hattımız 17+ yıl boyunca DNS taşıma, DNSSEC etkinleştirme, glue record yönetimi gibi konularda Türkçe teknik destek vermiştir.

DNS Nedir? Bir Cümlelik Ötesinde Doğru Tanım

DNS (Domain Name System) insan tarafından okunabilir alan adlarını (buyukweb.com.tr, mail.sirket.com.tr, api.uygulamam.com) makine tarafından kullanılabilir kaynak kayıtlarına (IPv4/IPv6 adresleri, mail sunucu hostname'leri, alias'lar, TLS sertifika yetkilileri vb.) dönüştüren, hiyerarşik, dağıtık, caching tabanlı bir adlandırma sistemidir.

RFC 1034 (kavramsal model, 1987) ve RFC 1035 (implementasyon detayı, 1987) ile tanımlanmıştır ve sonraki yıllarda 100'den fazla RFC ile genişletilmiştir: RFC 4033/4034/4035 (DNSSEC), RFC 6891 (EDNS0), RFC 7858 (DoT), RFC 8484 (DoH), RFC 9250 (DoQ), RFC 9460 (SVCB/HTTPS), RFC 8767 (serve-stale) ve daha niceleri.

DNS'i diğer adlandırma sistemlerinden ayıran üç temel özellik:

Hiyerarşik delegasyon — Hiçbir tek sunucu tüm internetin DNS'ini bilmek zorunda değildir; her zone yetkisini bir alt zone'a devreder.
Cache yoğun mimari — Her seviyede önbellek vardır (browser, OS, recursive resolver, ISP), TTL ile yaşam süresi belirlenir.
UDP-öncelikli, hafif protokol — Tipik bir sorgu 64-512 byte arası bir UDP paketi ile tek round-trip'te tamamlanır; sadece büyük yanıtlar veya zone transfer TCP kullanır.

DNS Hiyerarşisi: Nokta'dan Subdomain'e

DNS ağacı kök (root) olarak adlandırılan bir noktadan başlar. buyukweb.com.tr. yazımında sondaki nokta (genellikle yazılmaz ama her zaman vardır) kök zone'u temsil eder.

.                                  ← Kök zone (root)
├── tr                             ← TLD (Türkiye, ccTLD)
│   ├── com.tr                     ← SLD (kategorik subdomain)
│   │   ├── buyukweb               ← Customer domain (zone owner)
│   │   │   ├── www                ← Subdomain
│   │   │   ├── mail               ← Subdomain
│   │   │   └── api                ← Subdomain
│   │   └── ornek
│   ├── net.tr
│   ├── org.tr
│   └── edu.tr
├── com                            ← TLD (gTLD)
│   ├── google
│   └── example
├── net
├── org
└── arpa                           ← Reverse DNS özel TLD
    ├── in-addr.arpa               ← IPv4 reverse
    └── ip6.arpa                   ← IPv6 reverse

Hiyerarşinin her seviyesi delegasyon ile çalışır:

Kök sunucu (root) tüm TLD'lerin NS kayıtlarını tutar (com, tr, net, org, vb. için "şu authoritative server'lara sor" yanıtı verir).
TLD sunucusu o TLD altındaki tüm second-level domain'lerin NS kayıtlarını tutar (com için google.com'un NS'ini, tr için buyukweb.com.tr'nin NS'ini bilir).
Authoritative nameserver belirli bir zone'un tüm kayıtlarını (A, AAAA, MX, TXT, NS, SOA, vb.) yetkili olarak servis eder.

Türkiye için ccTLD (.tr) yönetimi TRABİS (Türkiye İnternet Alan Adları Birimi) tarafından yapılır. .com.tr, .net.tr, .org.tr, .gov.tr, .edu.tr gibi kategorik SLD'ler ayrı tutulur ve genelde ayrı kayıt şartları taşır.

Kök Sunucu Mimarisi: 13 İsim, Binlerce Instance

İnternet'in DNS kök zone'u sadece 13 NS kaydı ile temsil edilir: a.root-servers.net ile m.root-servers.net arası. Bu 13 isim, sınırlı olduğu yanılgısına yol açar; gerçekte her biri anycast ile dünya genelinde 100-300+ fiziksel sunucu instance'ına dağıtılmıştır. Toplam kök sunucu PoP (point of presence) sayısı 1.700'ü aşar.

Anycast'in pratik etkisi: Türkiye'den bir DNS resolver kök sorgu yaptığında, BGP üzerinden Istanbul, Frankfurt veya Bükreş'teki en yakın kök instance'a yönlendirilir. RTT (round-trip time) 5-30 ms arası kalır. Eğer tek bir lokasyon olsaydı, dünyanın diğer ucundan kök sorgusu için 200-300 ms beklemek gerekirdi.

Kök zone içeriği günde bir kez güncellenir ve IANA tarafından imzalanır. Her resolver bu zone'u priming query (RFC 8109) ile başlangıçta önbelleğine alır; her gün veya yeniden başlatmada tekrar doğrular.

DNS Çözümlemesi (Resolution): 8 Adım, Saniyenin Yüzde Biri

Bir tarayıcıda buyukweb.com.tr yazdığınızda ne olduğunu, paket seviyesinde adım adım inceleyelim. Aşağıdaki akış varsayım: önbellekler tamamen boş, ilk sorgu.

Adım 1: Browser DNS Cache

Modern tarayıcılar kendi içinde küçük bir DNS önbelleği tutar. Süre dakikalar ölçeğindedir (Chrome ~60 saniye, Firefox 60-3600 saniye yapılandırmaya göre). Aynı sekme veya yakın zaman aralığında ziyaret edilmiş alan adları için OS'a hiç gitmeden doğrudan IP döndürülür.

chrome://net-internals/#dns ile Chrome'un mevcut cache'ini incelersiniz; "Clear host cache" butonuyla manuel temizlersiniz. Firefox'ta about:networking#dns. Bu cache'ler tarayıcı içinde, OS'tan bağımsızdır.

Adım 2: İşletim Sistemi (OS) Cache

Cache'de yoksa, sıra OS'a gelir. İşletim sistemine göre farklı bileşenler devreye girer:

Windows — DNS Client servisi (Dnscache). ipconfig /displaydns ile görüntüleme, ipconfig /flushdns ile temizleme.
macOS — mDNSResponder + UnicastDNS önbelleği. sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder ile temizleme.
Linux (modern) — systemd-resolved. resolvectl flush-caches veya systemd-resolve --flush-caches (eski).
Linux (klasik) — nscd (Name Service Cache Daemon) veya dnsmasq. sudo systemctl restart nscd veya sudo systemctl restart dnsmasq.

OS önbelleği TTL'ye saygı gösterir; TTL süresi dolduğunda kayıt cache'ten düşer ve yeniden sorgu yapılır.

Adım 3: Hosts File Override

OS önbelleğine bakmadan hemen önce (veya bazı sistemlerde paralel olarak) hosts dosyası kontrol edilir:

Windows — C:\Windows\System32\drivers\etc\hosts
macOS / Linux — /etc/hosts

Hosts dosyasında manuel eşleştirme varsa, DNS'e hiç gidilmez. Geliştirme ortamında 127.0.0.1 dev.sirket.local gibi giriş yaparak local development server'ı domain ile temsil etmek için kullanılır. Ayrıca site engelleme (ad blocker hosts file mantığı) bu mekanizmayı kötüye kullanır.

Güvenlik notu: Hosts dosyası malware için klasik bir hedeftir; banka domain'lerini sahte IP'lere yönlendirmek için kullanılır. Şüpheli yönlendirme yaşıyorsanız hosts dosyanızı kontrol edin.

Adım 4: Stub Resolver → Recursive Resolver

OS önbelleğinde de yoksa, OS'un içindeki stub resolver devreye girer. Stub resolver "tam" bir DNS resolver değildir; sadece yapılandırılmış recursive resolver'a sorgu yollar ve cevabı uygulamaya iletir.

Recursive resolver listesi şu kaynaklardan gelir:

Linux — /etc/resolv.conf (nameserver 1.1.1.1 satırları)
Windows — Ağ adaptörü ayarlarında "Preferred DNS server" / "Alternate DNS server"
macOS — System Preferences → Network → Advanced → DNS
Router DHCP — Cihazınız genelde router'ınızdan ISP'nin önerdiği DNS'leri otomatik alır

Yaygın public recursive resolver seçenekleri:

Servis	IPv4	IPv6	Özellik
Cloudflare	1.1.1.1 / 1.0.0.1	2606:4700:4700::1111	Hızlı (~12 ms TR), gizlilik (24 saat log)
Google Public DNS	8.8.8.8 / 8.8.4.4	2001:4860:4860::8888	Yaygın, telemetri var
Quad9	9.9.9.9 / 149.112.112.112	2620:fe::fe	Malware/phishing IP'leri bloklar
OpenDNS (Cisco)	208.67.222.222 / 208.67.220.220	2620:119:35::35	Parental control, content filter
Yandex DNS	77.88.8.8 / 77.88.8.1	2a02:6b8::feed:0ff	Basic / Safe / Family modları
AdGuard DNS	94.140.14.14 / 94.140.15.15	2a10:50c0::ad1:ff	Reklam + tracker filtre

Stub resolver, yapılandırılmış birinci resolver'a sorgu gönderir; cevap gelmezse veya hata olursa ikinci/üçüncü resolver'a düşer (failover).

Adım 5: Recursive Resolver → Root NS

Stub resolver'dan gelen sorgu, recursive resolver'ın iteratif gezintisini başlatır. Cache'de buyukweb.com.tr için kayıt yoksa, recursive resolver önce kök zone'a sorgu yapar:

Recursive resolver → A root server (a.root-servers.net, 198.41.0.4)

Query: "buyukweb.com.tr A?"

Yanıt: AUTHORITY section:
  com.tr.   NS  ns1.nic.tr.
  com.tr.   NS  ns2.nic.tr.
  com.tr.   NS  ns3.nic.tr.
ADDITIONAL section:
  ns1.nic.tr.   A    194.27.7.21    ; glue
  ns2.nic.tr.   A    194.27.7.22    ; glue

Kök sunucu cevap vermez; "ben bilmiyorum ama com.tr TLD'sini şu sunuculara sor" der. Bu referral (yönlendirme) olarak adlandırılır.

Adım 6: Recursive Resolver → TLD NS

Recursive resolver kök sunucudan aldığı NS listesini cache'ler (TTL: 48 saat tipik) ve TLD sunucusuna geçer:

Recursive resolver → ns1.nic.tr (194.27.7.21)

Query: "buyukweb.com.tr A?"

Yanıt: AUTHORITY section:
  buyukweb.com.tr.   NS  ns1.buyukweb.com.tr.
  buyukweb.com.tr.   NS  ns2.buyukweb.com.tr.
ADDITIONAL section:
  ns1.buyukweb.com.tr.   A    195.85.100.10    ; glue record
  ns2.buyukweb.com.tr.   A    195.85.100.11    ; glue record

Yine cevap yok, sadece referral: "buyukweb.com.tr'nin authoritative NS'i şudur". Burada glue record kritik öneme sahip: NS hostname kendi domain'i içinde olduğu için (ns1.buyukweb.com.tr), parent zone (com.tr) bu hostname'in IP'sini ek olarak ADDITIONAL section'da sağlamalıdır. Yoksa sonsuz döngü olurdu (ns1.buyukweb.com.tr'yi çözmek için buyukweb.com.tr'ye sormak gerekir, o da ns1.buyukweb.com.tr'ye soracak...). Glue record konusu detaylı olarak nameserver yönetimi yazımıznda işlenir.

Adım 7: Recursive Resolver → Authoritative NS

Recursive resolver authoritative NS'in IP'sini glue'dan biliyor; doğrudan ona sorar:

Recursive resolver → ns1.buyukweb.com.tr (195.85.100.10)

Query: "buyukweb.com.tr A?"

Yanıt: ANSWER section:
  buyukweb.com.tr.   3600  IN  A   195.85.100.50

Bu sefer gerçek cevap: A kaydı + TTL (3600 saniye = 1 saat). AA (Authoritative Answer) bit'i set'li olarak gelir, recursive resolver bu cevabı yetkili kaynaktan aldığını bilir.

Adım 8: Cache + Stub'a İletme

Recursive resolver:

Gelen cevabı kendi cache'ine yazar (TTL kadar geçerli olacak)
Yol boyunca gelen referral'ları da cache'ler (NS kayıtları, glue'lar)
Stub resolver'a (yani client cihaza) cevabı yollar
Client'ın OS önbelleği ve browser önbelleği cevabı kendi seviyelerinde cache'ler

Toplamda 4 ayrı sunucuyla iletişim (root + TLD + authoritative + stub → resolver) ve 7 ayrı cache katmanı (browser + OS + stub + 4 sunucu cache'i) söz konusudur.

İkinci sorgu hızı: Bu yedi katmandan sadece biri bile cevabı cache'inde tutuyorsa, bir sonraki sorgu o seviyeden sonra durur. Çoğu pratik senaryoda ikinci sorgu 1-2 ms içinde tamamlanır.

Iterative vs Recursive Sorgu: Kim Kime Ne Sorar?

Yukarıdaki akışta iki farklı sorgu modu var, sık karıştırılır:

Recursive sorgu — Client → resolver: "Bana TAM CEVABI getir, ben aradaki referral'larla uğraşmak istemiyorum". Stub resolver → recursive resolver iletişimi recursive moddadır.
Iterative sorgu — Resolver → root/TLD/authoritative: "Sen ne biliyorsan onu söyle, bilmiyorsan kime sorabileceğimi söyle". Recursive resolver'ın gezintisi iterative moddadır.

Client                Recursive Resolver         Root/TLD/Auth
  │                         │                          │
  ├── RECURSIVE Q ─────────→│                          │
  │                         ├── ITERATIVE Q ──────────→│  (root)
  │                         │←── referral ─────────────┤
  │                         ├── ITERATIVE Q ──────────→│  (TLD)
  │                         │←── referral ─────────────┤
  │                         ├── ITERATIVE Q ──────────→│  (auth)
  │                         │←── answer ───────────────┤
  │←── final answer ────────┤                          │

Bir nameserver recursive sorguya cevap vermesi gerekip gerekmediğine kendisi karar verir:

Authoritative nameserver (BIND/PowerDNS/Knot) genellikle sadece authoritative sorgulara cevap verir, recursive isteği reddeder. Misuse açısı: open resolver olmak DDoS amplification saldırılarında kötüye kullanılır.
Recursive resolver (Unbound, dnsmasq, Cloudflare 1.1.1.1) recursive sorgulara cevap verir; iterative sorgularla gezinir.
Bazı yazılımlar her iki rolü üstlenir (BIND recursion yes + zone files) ama production'da iki rolü ayırmak (BIND auth + Unbound recursive) en iyi uygulamadır.

DNS Protokol Stack'i: UDP, TCP, EDNS0, DoH, DoT, DoQ

DNS sorgu/cevap iletişimi farklı taşıma protokolleri üzerinden yapılabilir. Her birinin amacı, güvenlik özellikleri ve performans karakteristiği farklıdır.

Klasik UDP 53

DNS'in varsayılan taşıma protokolü. Hafif, hızlı, connectionless. Sorgu ve cevap tek bir UDP paketinde gider/gelir.

Client (random port)  → resolver:53   UDP query
Client (random port)  ← resolver      UDP reply

Sınırlama: Orijinal DNS spesifikasyonunda UDP payload 512 byte ile sınırlı. Bu sınır bugün yetersiz; DNSSEC imzaları, EDNS0 OPT record, IPv6 AAAA artışı 512 byte'ı aşar.

TCP 53

Üç senaryoda TCP gerekir:

Truncation (TC bit) — UDP yanıt 512 byte'ı aşıyor ve EDNS0 yok. Sunucu TC bit set ile kısa bir cevap döner; client TCP üzerinde tekrar sorar.
AXFR / IXFR — Zone transfer (master → slave) her zaman TCP. Çünkü zone içeriği büyük (binlerce kayıt) ve güvenilir teslim gerekir.
Büyük yanıtlar (DNSSEC dahil) — EDNS0 olmadan veya orta yol cihazların büyük UDP'yi düşürdüğü ortamlar.

EDNS0 (Extension Mechanisms for DNS)

RFC 6891 ile tanımlı, UDP 512 byte sınırını otomatik aşmanın standart yolu. Sorguda bir OPT pseudo-record ile client kendisinin alabileceği maksimum UDP payload'ı bildirir (genelde 4096 byte). Modern resolver'lar EDNS0 aktif kullanır; DNSSEC zaten EDNS0'a bağımlıdır (DO bit "DNSSEC OK" flag'i de OPT record içinde).

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

DoT (DNS over TLS) — RFC 7858

DNS sorgularını TLS şifreli TCP üzerinden taşır. Port 853. Amaç: ISP veya ağ üstündeki ortak yol gözleyicilerinden DNS sorgularını gizlemek ve bütünlüğünü korumak.

Avantaj: Şifreli, basit (TCP + TLS), standart.
Dezavantaj: Port 853 bazı kurumsal ağlarda kapalı; "kullanıcı DNS şifreliyor" sinyali kolay tespit edilir.

DoH (DNS over HTTPS) — RFC 8484

DNS sorgularını HTTPS üzerinden, normal web trafiği gibi taşır. Port 443. Sorgu HTTP POST veya GET body'sinde DNS wire format olarak gönderilir.

Avantaj: Port 443 her yerde açık (web trafiği), DPI ile DNS'i ayırmak zor (gizlilik artar), tarayıcılar native destekler.
Dezavantaj: HTTPS overhead (TCP + TLS + HTTP), connection reuse olmadan yavaş.

Modern tarayıcılar DoH'u uygulama katmanında destekler:

Firefox — "Trusted Recursive Resolver" — Cloudflare 1.1.1.1 veya kullanıcı seçimi
Chrome — Secure DNS (chrome://settings/security)
Edge — Secure DNS (Privacy, search, and services)
Windows 11 — Settings → Network → Encrypted DNS (sistem geneli DoH/DoT)

Tarayıcı DoH aktif olduğunda, OS DNS ayarları bypass edilir; tarayıcı doğrudan kendi DoH endpoint'ine çıkar. Bu durum kurumsal DNS filtreleme politikaları için sorun yaratabilir; çözüm: kurumsal politikayla DoH'u devre dışı bırakmak veya kurum içi DoH resolver'ı tanıtmak.

DoQ (DNS over QUIC) — RFC 9250

DNS sorgularını QUIC üzerinden taşır. Port 853 (DoT ile aynı port, ALPN ile ayırılır). QUIC, UDP üzerinde TLS 1.3 sağlayan modern transport.

Avantaj: 0-RTT veya 1-RTT bağlantı (DoT/DoH'un TCP + TLS handshake yükü yok), şifreli, UDP'nin paket kaybı esnekliği.
Adoption: Henüz yaygın değil, AdGuard ve Cloudflare aktif kullanır.

ODoH (Oblivious DoH)

DoH'un gizlilik geliştirilmiş versiyonu. İki ayrı sunucu kullanılır: bir relay (sorgunun kimden geldiğini bilir, ne sorulduğunu bilmez) ve bir target (ne sorulduğunu bilir, kimden geldiğini bilmez). Hiçbiri tam profil çıkaramaz. Cloudflare deneysel olarak destekler.

Hangi Protokolü Ne Zaman Kullanmalı?

Senaryo	Önerilen	Sebep
Genel internet kullanımı	UDP + EDNS0 (klasik)	Hızlı, OS varsayılan
Kafe / public WiFi	DoH veya DoT	ISP/AP DNS log'u kapatır
Mobil sürekli	DoT	Tutarlı şifreli
Tarayıcı bazlı	DoH (browser ayarı)	Native, kolay
VDS sunucu (recursive Unbound)	DoT upstream	Sunucu-sunucu şifreli
Anonimlik kritik	ODoH veya Tor	Maks gizlilik

Kaynak Kayıtları (Resource Records): Kısa Hatırlatma

DNS sorgu yanıtları Resource Record (RR) formatındadır. Bir RR şu alanları içerir:

NAME              TTL    CLASS   TYPE    RDATA
buyukweb.com.tr.  3600   IN      A       195.85.100.50

En sık karşılaşılan kayıt türleri:

A — IPv4 adresi (195.85.100.50)
AAAA — IPv6 adresi (2a01:4f8:abcd::1)
CNAME — Canonical name (alias); hedef hostname'i çözmek için yeni sorgu
MX — Mail exchanger (priority + hostname)
TXT — Serbest metin (SPF, DKIM, DMARC, domain verification için)
NS — Authoritative nameserver delegasyon
SOA — Start of Authority (zone meta: serial, refresh, retry, expire, minimum)
SRV — Service record (port + hostname, SIP/XMPP/autodiscover için)
CAA — Certificate Authority Authorization (hangi CA bu domain'e SSL verebilir)
PTR — Pointer (reverse DNS, IP → hostname)
HTTPS / SVCB — RFC 9460 ile tanımlı modern hostname-to-service binding (ALPN, ECH, IPv4/6 hint)
TLSA — DANE (DNS-based Authentication of Named Entities), TLS cert pinning

Detaylı her kayıt türü kullanımı için DNS kayıtları rehberimiznde her birinin formatı, RDATA yapısı ve yapılandırma örnekleri vardır. Burada amacımız resolution mekaniğine odaklanmak.

TTL Stratejisi: Cache Ömrünü Yönetmek

TTL (Time To Live) her RR'nin yanında saniye cinsinden bir sayıdır. Resolver bu sayı kadar süre boyunca cevabı cache'inde saklar; süre dolduğunda kayıt geçersizleşir ve sıfırdan sorgulanır.

www.sirket.com.tr.   300    IN  A   195.85.100.50    ← 5 dakika
sirket.com.tr.       86400  IN  NS  ns1.buyukweb...  ← 24 saat
sirket.com.tr.       3600   IN  MX  10 mail...       ← 1 saat

TTL seçimi stratejik bir karardır:

Düşük TTL (60-300 saniye)

Avantaj: Hızlı değişim. Sunucu IP'si değiştiğinde 1-5 dakika içinde tüm dünyaya yansır.
Dezavantaj: Her resolver daha sık sorgu yapar → authoritative NS'ye yük artar, ek RTT ile sayfa yükü artar.

Ne zaman kullanılır:

Migration öncesi (T-48h önce TTL'yi 86400'den 300'e düşür, migrasyon sonrası tekrar yükselt)
Failover/sağlık kontrolü ile dinamik IP değiştiren servisler
Dev/test ortamları (sık IP değişimi)
Mail sunucu MX (mail server taşıma esnek olsun)

Yüksek TTL (3600-86400 saniye)

Avantaj: Cache hit oranı yüksek → authoritative NS'ye yük az, son kullanıcı için DNS lookup süresi düşük.
Dezavantaj: Hızlı değişim mümkün değil; eski IP 24 saate kadar cache'lerde kalır.

Ne zaman kullanılır:

Sabit production IP'ler (root domain, ana web)
NS kayıtları (zaten 48 saat tipik)
Sürekli erişim gerektiren API endpoint'leri

Migration Öncesi TTL Düşürme Akışı

Tipik bir IP değişikliği veya hosting geçişi senaryosu:

T-48h:  TTL = 86400 → TTL = 300 (cache temizlenmesi için 24h bekle)
T-24h:  Eski TTL süresi dolar, yeni TTL = 300 dünyaya yayılır
T-0:    IP değişikliğini yap; 5 dakika içinde dünya genelinde geçer
T+2h:   Migration başarılı doğrulanır
T+24h:  TTL'yi tekrar 86400'e yükselt (cache verimini geri al)

Bu TTL stratejisi, DNS propagasyon rehberimiznde detaylı işlenir; orada CNAME flattening, anycast hızlandırma ve yerel cache flush komutları da var.

Cache Katmanları: Her Seviyenin Karakteri

DNS performansını anlamak için cache hiyerarşisini ve her seviyenin TTL davranışını bilmek şart:

Katman	Tipik TTL	Kontrol Eden	Temizleme
Browser cache	60-3600 s (browser-specific)	Tarayıcı	`chrome://net-internals/#dns` "Clear host cache"
OS cache	TTL'ye saygı (RR'den gelen)	İşletim sistemi	`ipconfig /flushdns`, `dscacheutil -flushcache`, `resolvectl flush-caches`
Stub resolver cache	Genelde yok	OS dahilinde	OS flush ile beraber
Recursive resolver cache	TTL'ye saygı (en uzun süre burada)	Resolver operatörü (ISP, public DNS)	Operatör kontrolünde — kullanıcı temizleyemez
CDN edge cache	CDN-specific	CDN sağlayıcı	CDN dashboard veya API
Authoritative NS	(kaynak, cache değil)	Domain sahibi	Direkt değişiklik

Önemli içgörü: TTL'ye saygı en güvenilir olarak authoritative NS ve disiplinli recursive resolver'larda gerçekleşir. ISP resolver'ları bazen kendi politika ile TTL'yi artırır veya azaltır (TTL clamping); özellikle çok düşük TTL'leri (60 saniye) "minimum 5 dakika" gibi politikalarla yuvarlarlar. Bu davranış bazı failover senaryolarında problem yaratabilir.

Pratik Cache Temizleme Komutları

# Windows
ipconfig /flushdns

# macOS (Big Sur+)
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches
# eski sistemler
sudo systemd-resolve --flush-caches

# Linux (nscd)
sudo systemctl restart nscd

# Linux (dnsmasq)
sudo systemctl restart dnsmasq

# Chrome
chrome://net-internals/#dns  → "Clear host cache"

# Firefox
about:networking#dns  → "Clear DNS Cache"

Negatif Cache (NXDOMAIN)

Bir alan adı mevcut değilse (NXDOMAIN cevabı), bu durum da cache'lenir. Negatif cache TTL'si SOA kaydındaki minimum alanı (modern SOA'da "negative caching TTL") tarafından belirlenir; tipik olarak 3600 saniye (1 saat).

Sonuç: yanlış silinen ve hemen sonra geri eklenen bir alt domain, 1 saat boyunca bazı resolver'larda "yok" olarak görünebilir. Bu nedenle DNS değişiklikleri eklemek silmekten daha hızlı uygulanır.

Authoritative vs Recursive Nameserver: İki Farklı Rol

DNS dünyasında en sık karıştırılan kavramlar bunlardır. Ayrımı netleştirelim.

Authoritative Nameserver

Bir veya daha fazla zone'un kaynak verisini tutan sunucudur. buyukweb.com.tr zone'unun authoritative NS'i, bu zone'un tüm A/AAAA/MX/TXT/NS/SOA kayıtlarını yetkili olarak servis eder. Cevabında AA (Authoritative Answer) bit'i set'li gelir.

Yazılım örnekleri:

BIND — De facto standart, RFC referans implementasyonu
PowerDNS Authoritative — MySQL/PostgreSQL/SQLite backend, dinamik zone'lar
NSD — Hafif, sadece authoritative (recursive yok), DNSSEC odaklı
Knot DNS — Modern, performanslı, CZ.NIC tarafından
djbdns / tinydns — Minimalist, az kullanılıyor

Authoritative NS recursive sorguları reddetmelidir — sadece kendi zone'larındaki kayıtları döndürür. Detaylı BIND ve PowerDNS kurulumu için özel DNS sunucu rehberimiznde adım adım örnekler var.

Recursive Resolver

Client adına DNS sorgu döngüsünü yürüten sunucudur. Kendi zone verisi yoktur; cache + iteratif sorgu ile çalışır.

Yazılım örnekleri:

Unbound — De facto modern recursive resolver, NLnet Labs tarafından
BIND (recursion yes ile) — Eski tercih, modern Unbound önerilir
dnsmasq — Hafif, küçük ağlar için (router/Raspberry Pi)
Knot Resolver — Performans odaklı modern alternatif
Cloudflare 1.1.1.1 — Public anycast servis (kendi içinde Knot Resolver kullanır)
Google Public DNS 8.8.8.8 — Custom in-house resolver

Aynı Sunucuda İki Rol?

Bazı yazılımlar (özellikle BIND) iki rolü aynı anda üstlenebilir. Production'da iki rolü ayırmak en iyi uygulamadır:

Authoritative NS'i recursion açık tutmak → "open resolver" yapar; DDoS amplification saldırılarında kötüye kullanılır.
Recursive resolver'ı authoritative zone'larla yüklemek → güvenlik ve performans karışıklığı.

Buyukweb altyapısında authoritative NS'ler (white-label ns1.musteri.com.tr) sadece authoritative çalışır; müşterilerin recursive ihtiyacı için public resolver (1.1.1.1, 8.8.8.8) önerilir veya VDS üzerinde Unbound kurulur.

Public DNS Resolver Karşılaştırması

Hangi public resolver'ı kullanmalısınız? Karar matrisi:

Cloudflare 1.1.1.1

Lansman: 2018
Hız: Türkiye'den ~10-20 ms ortalama (en hızlı sınıfında)
Gizlilik: 24 saat log retention politikası, KPMG denetlemesi
DoH/DoT: Native destek (https://cloudflare-dns.com/dns-query, port 853)
Filtre: Standart 1.1.1.1 filtresiz; 1.1.1.2 (malware blok), 1.1.1.3 (malware + adult)
Tercih sebebi: Hız + gizlilik fokusu; KOBİ ve geliştirici için ideal

Google Public DNS 8.8.8.8

Lansman: 2009
Hız: Türkiye'den ~15-30 ms
Gizlilik: Telemetri ve loglama Google ekosistemi içinde
DoH/DoT: Native destek (https://dns.google/dns-query, port 853)
Filtre: Yok (saf resolver)
Tercih sebebi: Yaygın bilinirlik, basit konfigürasyon

Quad9 9.9.9.9

Lansman: 2017 (IBM, Packet Clearing House, Global Cyber Alliance ortaklığı)
Hız: Türkiye'den ~20-40 ms
Gizlilik: Loglar IP tutmaz, kar amacı gütmeyen
DoH/DoT: Native destek
Filtre: Bilinen malware/phishing domain'leri blokar (threat intelligence kaynaklı)
Tercih sebebi: Güvenlik fokusu; kurumsal default için iyi

OpenDNS 208.67.222.222

Lansman: 2006 (Cisco tarafından satın alındı 2015)
Hız: Türkiye'den ~30-50 ms
Filtre: OpenDNS Home dashboard ile aile/parental control filtreleme
Tercih sebebi: Aile/okul ortamı için content filter

AdGuard DNS

Lansman: 2018
Hız: Türkiye'den ~25-45 ms
Filtre: Default mod reklam + tracker blok, Family mode + adult filter
DoH/DoT/DoQ: Tamamı native destek
Tercih sebebi: Ağ seviyesi reklam engelleme (uygulama bazlı değil)

Karar Önerisi

Genel hızlı + gizlilik → Cloudflare 1.1.1.1
Malware koruması istiyorum → Quad9 9.9.9.9
Reklam engelleme → AdGuard
Aile/okul → OpenDNS veya Cloudflare 1.1.1.3
Maks gizlilik → Self-host Unbound (VDS üzerinde)

DNSSEC: Güven Zinciri ile Bütünlük

DNS protokolünün orijinal tasarımında kimlik doğrulama yok: bir saldırgan DNS cevabını sahte üretirse, resolver bunu meşru kabul eder. Kaminsky cache poisoning saldırısı (2008) bu zaafı gösteren ünlü bir örnektir.

DNSSEC (DNS Security Extensions) RFC 4033/4034/4035 ile bu boşluğu doldurur: her DNS cevabını kriptografik imza ile doğrular.

Çekirdek Kayıt Türleri

RRSIG (Resource Record Signature) — Bir RRset'in (örn. tüm A kayıtları) imzası
DNSKEY — Zone'un public anahtarı (KSK + ZSK)
DS (Delegation Signer) — Parent zone'da bulunur, child zone'un KSK hash'i
NSEC / NSEC3 — "Bu kayıt yoktur" iddiasının kanıtı (negatif yanıtların imzalanması)

KSK ve ZSK: İki Anahtar Modeli

DNSSEC'te iki anahtar çifti kullanılır:

KSK (Key Signing Key) — Sadece DNSKEY RRset'ini imzalar. Uzun ömürlü (1-2 yıl), parent zone'daki DS kaydıyla zincirlenir. Rotation karmaşıktır (parent zone değişikliği gerekir).
ZSK (Zone Signing Key) — Diğer tüm RRset'leri (A, AAAA, MX, TXT) imzalar. Kısa ömürlü (1-3 ay), sık rotation kolay (sadece zone içinde).

İki anahtar ayrımı: KSK seyrek rotate edildiği için key compromise riskinden korunur; ZSK sık rotate edildiği için günlük operasyonu hızlandırır.

Güven Zinciri (Chain of Trust)

. (root)
  ├── DS record    →  Root zone, kendi KSK'sini imzalar; ICANN tarafından yönetilir
  │
  └── tr (TLD)
        ├── DS record (root içinde)  →  tr'nin KSK'sini doğrular
        │
        └── com.tr
              ├── DS record (tr içinde)  →  com.tr KSK'sini doğrular
              │
              └── buyukweb.com.tr
                    ├── DS record (com.tr içinde)  →  buyukweb KSK
                    ├── DNSKEY (KSK + ZSK)
                    └── RRSIG (her RRset için)

Resolver bu zinciri kökten yapraklara doğru takip eder. Herhangi bir halkadaki imza başarısız olursa, resolver SERVFAIL döner (yanlış cevaptansa hiç cevap vermemek prensibi). Bu davranış DNSSEC'in fail-secure yapısıdır.

DNSSEC Aktifleştirme: Buyukweb Müşterileri İçin

cPanel hosting paketlerimizde DNSSEC zone editor üzerinden otomatik destekli olarak aktive edilir; reseller müşterilerimiz WHM içinden zone'larını imzalayabilir. Detaylı adımlar için DNS kayıtları rehberimiznde DNSSEC alt bölümüne bakın.

Self-host VDS senaryosunda BIND auto-dnssec maintain veya PowerDNS pdnsutil secure-zone komutları ile zone'unuzu kolayca DNSSEC ile imzalayabilirsiniz. Domain registrar'ında DS kaydını girmeniz ayrıca gerekir; bu adım atılmazsa zincir parent'tan kopuk olur (zone imzalı ama doğrulanamaz).

DNSSEC'in Faydaları ve Sınırları

Faydaları:

Cache poisoning saldırılarına karşı koruma
DANE (TLSA kayıtları) ile TLS sertifika pinning mümkün
Mail authentication ekosisteminde (DKIM key publishing) güven artırır

Sınırları:

Şifreleme sağlamaz — Sorgu/cevap düz metindir; gizlilik için DoH/DoT/DoQ gerekir
Hata payı yüksek — Yanlış yapılandırılmış DNSSEC zone'u domain'i tamamen erişilmez yapar (SERVFAIL)
Resolver tarafı doğrulama gerekir — Validating resolver kullanmayan client'lar fayda görmez
Operasyonel yük — Anahtar rotation, KSK rollover, parent DS güncelleme süreci dikkat ister

DNS Güvenlik Tehditleri

Cache Poisoning (Kaminsky 2008)

Bir saldırgan, resolver'a sahte DNS cevap paketleri göndererek cache'i zehirlemeyi dener. Modern korumalar:

DNS transaction ID randomization (16 bit)
Source port randomization (16 bit) → toplam 32 bit entropy
0x20 case encoding (case bit'leriyle ek entropy)
DNSSEC (kriptografik kanıt; deterministik koruma)

DDoS Amplification (DNS Reflection)

Saldırgan, kurban IP'sini source olarak gösteren küçük DNS sorguları gönderir; sorgu büyük yanıt üretir (özellikle ANY veya DNSSEC ile imzalı yanıt); büyük yanıtlar kurbana akar. 50-100x amplification mümkün.

Koruma:

Open resolver olmayın — Authoritative NS recursive isteği reddetmeli
Response Rate Limiting (RRL) — BIND/Knot/PowerDNS aynı kaynaktan tekrarlanan büyük yanıtları sınırlar
BCP 38 (kaynak adresi filtreleme) — ISP seviyesinde spoofed paket önleme

NXDOMAIN Random Subdomain Attack

Saldırgan, hiç var olmayan rastgele alt domain'leri sorgular: asdf123.example.com, xyz456.example.com... Resolver her seferinde authoritative NS'e gider (negatif cache her birini ayrı saklamak zorunda); authoritative NS yük altına girer.

Koruma:

Aggressive NSEC caching (RFC 8198) — NSEC kayıtları ile resolver "bu range'de hiçbir şey yok" sonucunu çıkarır, her sorgu için authoritative'e gitmez
NXDOMAIN cutting — Bir prefix altında çok fazla NXDOMAIN gören resolver, prefix bazlı blok uygular
RRL (Response Rate Limiting) authoritative NS'te

DoH/DoT/DoQ ile Gizlilik

Yukarıda detaylı işlediğimiz şifreli DNS protokolleri, ortam üstündeki gözleyicilerden DNS sorgularını gizler. Saldırganın MitM olarak DNS'i değiştirmesini de zorlaştırır (TLS sertifika doğrulaması gerektirdiğinden).

DNS Sorgulama Araçları: Pratik Komut Hatti

DNS troubleshoot için her sistem yöneticisinin bilmesi gereken araçlar:

dig (Domain Information Groper)

BIND'in tools paketinde gelir; modern standart araç. apt install dnsutils veya yum install bind-utils.

# Temel A kaydı sorgu
dig buyukweb.com.tr

# Belirli resolver kullan
dig @1.1.1.1 buyukweb.com.tr

# Belirli tür
dig buyukweb.com.tr MX
dig buyukweb.com.tr TXT
dig buyukweb.com.tr NS

# Iterative trace (köke kadar her adımı göster)
dig +trace buyukweb.com.tr

# DNSSEC doğrulama
dig +dnssec buyukweb.com.tr
dig +sigchase buyukweb.com.tr

# Kısa cevap (sadece IP)
dig +short buyukweb.com.tr

# Reverse DNS
dig -x 195.85.100.50

# Authoritative NS'lerden sırayla sorgu
for ns in $(dig +short buyukweb.com.tr NS); do
  echo "=== ${ns} ==="
  dig @${ns} buyukweb.com.tr +short
done

nslookup

Daha basit, etkileşimli mod desteklemesiyle Windows'ta varsayılan. Modern troubleshoot için dig tercih edilir.

nslookup buyukweb.com.tr
nslookup buyukweb.com.tr 1.1.1.1
nslookup -type=MX buyukweb.com.tr

host

dig'in kısa formatlı muadili.

host buyukweb.com.tr
host -t MX buyukweb.com.tr
host -a buyukweb.com.tr   # tüm türler

drill

BIND alternatifi. drill LDNS paketinin parçasıdır; bazı dağıtımlarda dig'e benzer kullanım.

kdig

Knot DNS'in tools paketinin parçası. dig'e çok benzer ama DoH/DoT/DoQ desteği daha gelişmiş.

# DoT ile sorgu
kdig +tls @1.1.1.1 buyukweb.com.tr

# DoH ile sorgu
kdig +https @1.1.1.1 buyukweb.com.tr

# DoQ ile sorgu
kdig +quic @1.1.1.1 buyukweb.com.tr

Online Araçlar

whatsmydns.net — Dünya genelinde 25+ lokasyondan eşzamanlı DNS sorgu (propagasyon görselleştirme)
dnschecker.org — Benzer global propagasyon kontrol
dnssec-analyzer.verisignlabs.com — DNSSEC zincir doğrulama
mxtoolbox.com — MX, SPF, DKIM, DMARC analiz + blacklist kontrol
intodns.com — Genel DNS sağlık kontrolü, eski tarz raporlar

Anycast vs Unicast DNS

Modern DNS altyapısının vazgeçilmez parçası anycast yönlendirmedir. Klasik unicast'tan farkı:

Unicast DNS

Tek IP, tek lokasyon, tek fiziksel sunucu. 195.85.100.10 IP'si sadece Bursa Tier 3 datacenter'ında bir sunucu.

Avantajlar: Basit, ucuz, küçük operasyonlar için yeterli.
Dezavantajlar: Tek nokta arıza, coğrafi uzaklığa bağlı RTT (Istanbul'dan 10 ms ama San Francisco'dan 200 ms).

Anycast DNS

Aynı IP, birden çok lokasyonda, BGP routing ile en yakın PoP'a otomatik yönlendirilir. 1.1.1.1 Cloudflare'in dünya genelinde 300+ datacenter'ında aynı IP olarak anons edilir; istemci paketi, BGP'nin ona en yakın gördüğü Cloudflare PoP'una gider.

Avantajlar:

Düşük RTT (her zaman en yakın lokasyon)
DDoS dağıtılır (saldırı yükü tek lokasyona yığılmaz)
Failover transparent (bir PoP düşerse BGP başka PoP'a yönlendirir)

Dezavantajlar:

AS sahibi olmak + IP bloğu + BGP peering gerektirir
Tek başına küçük operatör için pahalı
TCP bağlantı yarıda yön değiştirirse koparılabilir (kısa UDP sorgularında problem değil)

Pratik: Modern public resolver'ların hemen hepsi anycast: 1.1.1.1, 8.8.8.8, 9.9.9.9. Yöneten DNS hizmetleri ve büyük CDN'lerin authoritative DNS altyapıları da anycast. Buyukweb müşterileri için Cloudflare DNS kullanımı pratik bir anycast authoritative çözümdür; detayı Cloudflare DNS rehberimiznde.

IPv6 ve DNS: Dual Stack Akışı

Modern bir hostname tipik olarak hem A kaydı (IPv4) hem AAAA kaydı (IPv6) içerir. Dual-stack istemci (IPv4 + IPv6 destekli OS) iki sorgu yapar — A ve AAAA — paralel olarak.

buyukweb.com.tr.   3600  IN  A     195.85.100.50
buyukweb.com.tr.   3600  IN  AAAA  2a01:4f8:1c0c:abcd::1

Happy Eyeballs (RFC 8305) algoritması: Tarayıcı/uygulama her iki adrese paralel TCP bağlantı dener; hangisi önce SYN-ACK döndürürse onu kullanır. Tipik tercih IPv6 (varsa) ile başlar, IPv4 fallback. Bu sayede IPv6 sağlıklı çalıştığında native kullanılır; IPv6 broken ise transparent IPv4 fallback olur.

DNS sorguları kendisi de IPv4 veya IPv6 üzerinde taşınabilir. Modern resolver'lar IPv6 üzerinden de aktiftir (Cloudflare 2606:4700:4700::1111, Google 2001:4860:4860::8888). Stub resolver'ın hangi protokolü tercih ettiği yapılandırmaya bağlı.

WHOIS vs DNS: Karıştırılan İki Sistem

DNS ile WHOIS, ikisi de domain'lerle ilgili olduğu için sık karıştırılır:

Kavram	DNS	WHOIS
Amaç	Hostname → IP / mail / vb. eşleştirme	Domain sahibi, kayıt tarihi, kayıt firması bilgisi
Protokol	DNS (RFC 1034/1035)	WHOIS (RFC 3912), RDAP (RFC 7480)
Port	UDP/TCP 53, 443/853 (DoH/DoT)	TCP 43 (WHOIS), HTTPS (RDAP)
Cevap	Resource record (A, MX, vb.)	Yapılandırılmamış metin (klasik) / JSON (RDAP)
Cache	Yoğun (TTL bazlı)	Genelde yok, query-time alır
Sorgu	dig, nslookup, host	whois, RDAP API
Güncellik	Yüksek (TTL ile değişim hızlı yansır)	Daha statik (yıllık kayıt yenileme)

Pratik: "Sitenin sahibi kim?" → WHOIS. "Sitenin IP'si nedir?" → DNS.

Buyukweb Altyapısında DNS Yönetimi

Buyukweb müşterileri için DNS yönetim seçenekleri:

1. Buyukweb Authoritative NS (Default — cPanel Müşteri)

cPanel hosting paketi aldığınızda, domain'inizin nameserver'ı Buyukweb authoritative NS'lerine yöneltilir. Tüm DNS kayıtlarınız cPanel Zone Editor (Buyukweb cPanel paketlerinde standart) üzerinden yönetilir.

Özellikler:

Buyukweb anycast benzeri TR-odaklı DNS altyapısı
DNSSEC desteği (zone editor ile aktif edilir)
A, AAAA, CNAME, MX, TXT (SPF/DKIM/DMARC), SRV, CAA, NS, PTR (ayrı talep), HTTPS/SVCB kayıt desteği
Otomatik SOA serial number artışı

2. WHM DNS Zone Manager (Reseller Müşteri)

Reseller hosting müşterilerimiz WHM DNS Zone Manager üzerinden tam authoritative DNS yönetimi yapar; alt müşterileri için zone oluşturma, DNSSEC etkinleştirme, cluster yönetimi.

3. Cloudflare DNS (Hibrit Kurulum)

Domain'in NS'lerini Cloudflare'a yönlendirip Buyukweb'i origin hosting olarak kullanma. CDN + DDoS + edge caching avantajı. Detay: Cloudflare DNS rehberi.

4. Self-Host VDS (BIND/PowerDNS)

VDS sunucu üzerinde tam kontrolünüzde authoritative DNS. Birden fazla domain'inizin tek panelden yönetimi, custom zone'lar, dinamik DNS, özel TTL stratejileri. Kurulum rehberi: BIND ve PowerDNS yazımız.

5. White-Label Nameserver (Reseller)

ns1.firmaniz.com.tr ve ns2.firmaniz.com.tr ile kendi markanız altında authoritative NS sunma. Glue record yapılandırması + IP delegasyonu detayları: Nameserver yönetimi rehberi.

DNS Troubleshooting: Tipik Senaryolar

"Site açılmıyor ama IP açılıyor"

Belirtiler: curl http://buyukweb.com.tr connection timeout, ancak curl http://195.85.100.50 (IP) çalışıyor.

Tanı:

dig buyukweb.com.tr — A kaydı dönüyor mu?
dig @1.1.1.1 buyukweb.com.tr — public resolver de aynı mı diyor?
nslookup buyukweb.com.tr — yerel resolver mi yanlış cache'liyor?
ipconfig /flushdns (Windows) veya resolvectl flush-caches (Linux) — yerel cache temizle

Olası nedenler: Yerel hosts dosyasında yanlış kayıt, OS DNS cache eski, kötü resolver tercih edilmiş.

"Bazı kullanıcılar görüyor, bazıları görmüyor"

Belirtiler: IP/NS değişikliği sonrası bazı kullanıcılar yeni siteyi görüyor, bazıları eski IP'ye gidip "404" veya "down" görüyor.

Tanı: DNS propagasyon devam ediyor. Resolver bazlı TTL süresine bağlı; eski TTL = 86400 ise 24 saate kadar normaldir.

Çözüm: Beklemek. Hızlandırma için:

whatsmydns.net'te global durum görselleştir
Etkilenen kullanıcılara flushdns komutu öner
Sonraki migration öncesi TTL'yi T-48h önce düşür (DNS propagasyon rehberi)

"MX kaydı doğru ama mail gelmiyor"

Belirtiler: dig MX domain doğru sunucuyu gösteriyor, ama mail gönderici tarafında bounce alıyor.

Tanı:

dig MX domain — primary + secondary MX listesi mantıklı mı?
dig A mail.domain — MX hedef hostname'in A kaydı var mı?
dig -x ip — Reverse DNS (PTR) doğru hostname'i gösteriyor mu? Mail için kritik. Detay: Reverse DNS rehberi
dig TXT domain — SPF kaydı var mı?
dig TXT selector._domainkey.domain — DKIM kaydı var mı?

Olası nedenler: PTR eksik veya yanlış, SPF/DKIM yapılandırması bozuk, DNSBL'e düşmüş IP.

"DNSSEC doğrulama hatası (SERVFAIL)"

Belirtiler: dig domain SERVFAIL döner; dig +cd domain (checking disabled) çalışır.

Tanı:

dig +dnssec domain — RRSIG var mı?
dnssec-analyzer.verisignlabs.com — Tam zincir analizi
KSK rollover sırasında parent DS güncellemesi atlanmış mı?
Zone serial number arttı ama imzalar güncellenmedi mi?

Olası nedenler: DS kaydı parent zone'da güncel değil, KSK/ZSK rotation yarıda kalmış, zone serial+RRSIG senkronizasyon problemi.

"DNS sorgu yavaş (saniyeler sürüyor)"

Belirtiler: Sayfa açılırken belirgin DNS bekleme; dig ile sorgu 500-3000 ms.

Tanı:

dig @1.1.1.1 domain — public resolver hızlı mı? Evet → yerel resolver yavaş
dig @8.8.8.8 domain — alternatif public hızlı mı?
dig +trace domain — hangi adım uzun sürüyor?
Yerel OS cache'inde negatif cache var mı?

Olası nedenler: ISP DNS yoğun, IPv6 broken (AAAA timeout), authoritative NS yavaş, resolver başka problem.

Çözüm: Public resolver'a geçiş (1.1.1.1 veya 8.8.8.8); kalıcı yavaşlık için VDS üzerinde self-host Unbound.

DNS Hosting Türleri: Karar Matrisi

Hangi DNS hosting modeli sizin için?

Senaryo	Önerilen	Buyukweb
Standart KOBİ web sitesi	cPanel paket dahil DNS	Tüm cPanel paketlerinde standart
KOBİ + CDN/DDoS ihtiyacı	Cloudflare DNS (free) + Buyukweb hosting	Hibrit, dokümante
Reseller / ajans	WHM DNS cluster	Reseller paketleri
Çoklu domain (10+) + özel kurallar	VDS + PowerDNS + MySQL backend	VDS sunucu
Coğrafi yönlendirme	GeoDNS çözümleri (Cloudflare, vb.)	GeoDNS rehberi
Kurumsal white-label NS	`ns1.firmaniz.com.tr` glue + delegasyon	Nameserver rehberi
Yüksek erişilebilirlik (4xN9)	Anycast (genelde external) + on-prem authoritative	Hibrit kurulum

Sık Sorulan Sorular (SSS)

"DNS değişikliği gerçekten 48 saat mı sürer?"

Eski kuralı verir: "TTL = 86400 → 24 saate kadar normal, güvenlik payı için 48 saat de". Modern gerçek: Çoğu pratik senaryoda 5 dakika - 4 saat içinde dünya genelinde yayılır. TTL süreniz neyse, en geç o kadar süre içinde tüm cache'ler yenilenir. Strategy: T-48h önce TTL'yi 86400'den 300'e indirin; değişiklik sonrası 5 dakika içinde küresel etki. Detaylı: DNS propagasyon rehberi.

"1.1.1.1 mi, 8.8.8.8 mi daha iyi?"

İkisi de hızlı, ikisi de güvenilir. Cloudflare 1.1.1.1 gizlilik konusunda daha agresif politika izler (24 saat retention, KPMG denetim); Türkiye'den ortalama 5-10 ms daha hızlı. Google 8.8.8.8 yaygın bilinirlik ve telemetri ekosistemi içinde. KOBİ ve geliştirici için 1.1.1.1 önerimiz; kurum default'u için 9.9.9.9 (Quad9) malware blok özelliği nedeniyle iyi alternatif.

"DNSSEC zorunlu mu? Açmasam ne olur?"

Zorunlu değil, ama yüksek değere sahip domain'ler için (banka, e-ticaret, kurumsal) şiddetle önerilir. Açmazsanız cache poisoning saldırılarına potansiyel olarak savunmasızsınız (modern korumalar çoğunu engelliyor ama kesin değil). DNSSEC açtığınızda dikkat: yanlış yapılandırma domain'i tamamen offline yapar (SERVFAIL). Buyukweb cPanel'de tek-tıkla aktivasyon riski azaltır.

"DoH gerçekten gizlilik sağlar mı?"

Kısmen evet. DoH ortam üstündeki gözleyicilerden (ISP, kafe WiFi, ağ admin) DNS sorgularını gizler. Ama:

DoH operatörü (Cloudflare, Google) sorgularınızı görür (gizlilik politikalarına bağlı)
Sitenin IP'sine bağlandığınızda hedef IP yine görülür (sadece "hangi domain" gizlenir, "hangi IP" gizlenmez)
SNI (TLS sunucu adı) henüz çoğunlukla düz metin → ECH (Encrypted Client Hello) yaygınlaştığında bu da çözülür

Tam gizlilik için: ODoH (Oblivious DoH) + ECH + VPN/Tor kombinasyonu. Sıradan kullanıcı için DoH iyi bir başlangıç.

"Hangi tarayıcı DoH'u nasıl etkinleştirir?"

Firefox: Settings → Privacy & Security → DNS over HTTPS → "Enable DNS over HTTPS" + provider seçimi
Chrome: chrome://settings/security → "Use secure DNS" → provider seçimi veya custom
Edge: edge://settings/privacy → "Use secure DNS"
Windows 11: Settings → Network & Internet → adaptör → DNS server assignment → DNS over HTTPS aç

"Şirkette tüm bilgisayarların DNS'ini değiştirmek istiyorum"

İki yol:

DHCP üzerinden — Router/DHCP server'da "DNS servers" parametresini 1.1.1.1, 1.0.0.1 olarak ayarlayın. Tüm istemciler otomatik alır.
GPO (Group Policy) — Windows AD — Domain controller'da "DNS Suffix Search List" + manuel DNS settings push.

Kurumsal seviye için DoH/DoT zorunluluğunu (Encrypted DNS) GPO ile şart koşmak, kullanıcı tarayıcı seviyesi DoH override'ını engellemek de iyi uygulamadır.

"Authoritative NS değişikliği yaptım, ne kadar sürer?"

NS kayıtlarının TTL'si parent zone'da (.com, .tr, .com.tr) tipik olarak 48 saat'tir. Yani eski NS'leri 48 saate kadar cache'lerde görebilirsiniz. Bu süre boyunca eski NS aktif kalmalı (mümkünse paralel olarak yeni NS'le aynı zone'u servis etsin). Domain registrar'ında NS değişikliği yapıldığında parent zone DS/glue güncellenir; küresel propagasyon süresi 4-48 saat. Detay: Nameserver yönetimi.

"Buyukweb'de DNS değişikliği nasıl yapılır?"

cPanel müşterileri için:

cPanel paneline giriş
Domains → Zone Editor (veya "DNS Zone Editor")
İlgili domain için "+ Add Record" veya mevcut kaydı "Edit"
Tip, hostname, TTL, RDATA gir → Kaydet
SOA serial number otomatik artar
5 dakika - 1 saat içinde değişiklik küresel cache'lere yayılır

WHM reseller müşterileri için WHM → DNS Functions → Edit DNS Zone. VDS müşterileri için kendi authoritative server'ında zone file edit (BIND reload veya PowerDNS pdns_control reload).

Sonuç ve Sonraki Adımlar

DNS, internetin görünmez ama kritik altyapısıdır. buyukweb.com.tr yazıp Enter'a bastığınız anda devreye giren 8 adımlı çözümleme, 7 cache katmanı, en az 4 sunucu iletişimi ve potansiyel olarak şifreli protokol katmanları; bu yapının her parçasını anlamak hem performans hem güvenlik kararlarınızı doğru almanızı sağlar.

Bu rehberde işlediğimiz ana noktalar:

Hiyerarşi — kök (.) → TLD (.tr) → SLD (buyukweb) → subdomain; her seviye delegasyon ile çalışır.
Resolution — Browser → OS → hosts → stub resolver → recursive resolver → iteratif gezinti (root → TLD → authoritative) → cevap → cache.
Sorgu modu — Client'a recursive, sunucular arasında iterative.
Protokol stack — UDP 53 default, TCP 53 fallback/transfer, EDNS0 büyük yanıt, DoH/DoT/DoQ şifreli.
TTL — Cache ömrü kontrolü; migration öncesi düşür, sonrası yükselt.
DNSSEC — Kriptografik imza ile bütünlük; KSK + ZSK + DS güven zinciri.
Anycast — Aynı IP, dünya genelinde; modern public resolver'ların standart yöntemi.
Public resolver karşılaştırması — Cloudflare 1.1.1.1 (hız + gizlilik), Quad9 9.9.9.9 (güvenlik), Google 8.8.8.8 (yaygın).
Araçlar — dig, nslookup, host, kdig, whatsmydns.net.
Buyukweb seçenekleri — cPanel zone editor, WHM DNS, Cloudflare hibrit, VDS self-host (BIND/PowerDNS), white-label NS.

DNS değişikliği yapmadan önce TTL'yi düşürmeyi, DNSSEC açarken parent zone DS kaydını unutmamayı, mail sunucularda PTR + SPF + DKIM + DMARC çiftliğini bütün olarak kurmayı, ve hassas trafik için DoH/DoT geçişini hatırlayın.

İlgili Büyükweb Hizmetleri

cPanel Web Hosting — Zone Editor + DNSSEC dahil paketler
VDS Sunucu — Self-host BIND, PowerDNS, Unbound platformu
Reseller Hosting — WHM DNS Zone Manager + alt müşteri yönetimi
DNS Kayıtları Hub Yazısı — A/AAAA/CNAME/MX/TXT/NS/SOA/SRV/CAA/PTR/HTTPS/SVCB/TLSA detaylı kayıt türleri
BIND ve PowerDNS Kurulumu — Self-host authoritative DNS + DNSSEC
Nameserver Yönetimi — White-label NS, glue record, hidden master mimari
DNS Propagasyon Rehberi — TTL stratejisi, cache invalidation, küresel yayılma
Reverse DNS / PTR Rehberi — Mail deliverability için PTR + FCrDNS
Cloudflare DNS Yönetimi — Anycast + CDN + DDoS hibrit
GeoDNS Yapılandırması — Coğrafi yönlendirme stratejileri
SPF, DKIM, DMARC Rehberi — DNS bazlı mail kimlik doğrulama

DNS taşıma, DNSSEC etkinleştirme, white-label NS yapılandırması, glue record talepleri veya self-host PowerDNS/BIND kurulum desteği için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezimizden 17+ yıllık DNS operasyon tecrübemizle yanınızdayız.