DNS Ne Yapar ve Nasıl Çalışır?

DNS (Domain Name System), insanlar tarafından okunabilir alan adlarını — örneğin example.com — 93.184.216.34 gibi makineler tarafından okunabilir IP adreslerine çeviren internetin dağıtık adlandırma altyapısıdır. DNS olmadan, her tarayıcı isteği, API çağrısı ve e-posta iletimi; kullanıcıların ve uygulamaların her uzak sunucunun tam sayısal adresini bilmesini gerektirirdi; bu da modern internetin geniş ölçekte işletilmesini imkânsız kılardı.

DNS, özünde küresel olarak dağıtılmış, hiyerarşik bir veritabanıdır. Tek bir sunucu ya da merkezi bir kayıt sistemi değildir — dünya genelinde yüz binlerce yetkili ad sunucusuna yayılan, küçük bir kök sunucu kümesi aracılığıyla koordine edilen ve RFC 1034 ile RFC 1035’te tanımlanan standartlarla yönetilen bir yetki devri ağacıdır.

DNS Neden Sadece Bir “Telefon Rehberi”nden Fazlasıdır

Telefon rehberi benzetmesi yeni başlayanlar için kullanışlıdır, ancak DNS’in gerçekte ne yaptığını büyük ölçüde küçümsemektedir. DNS; aynı zamanda şunları da yöneten gerçek zamanlı, hata toleranslı, küresel olarak çoğaltılmış bir arama sistemidir:

• E-postayı doğru posta sunucularına yönlendiren MX kayıtları aracılığıyla posta yönlendirme
• SIP, XMPP ve Kubernetes iç ağı gibi protokoller tarafından kullanılan SRV kayıtları aracılığıyla hizmet keşfi
• SPF, DKIM, DMARC ve Google Search Console için kullanılan TXT kayıtları aracılığıyla alan adı sahipliği doğrulama
• CDN entegrasyonu ve yük dengelemeyi mümkün kılan CNAME kayıtları aracılığıyla kanonik adlandırma
• AAAA kayıtları aracılığıyla IPv6 adresleme
• Posta sunucusu itibarı ve güvenlik denetimi için kritik olan in-addr.arpa bölgesindeki PTR kayıtları aracılığıyla ters aramalar
• DNS yanıtlarına önbellek zehirlenmesini önlemek için kriptografik imzalar ekleyen DNSSEC doğrulama

Her e-posta gönderdiğinizde, VPN’e bağlandığınızda veya bir web uygulaması yüklediğinizde, DNS arka planda birden fazla kayıt türünü çözümler — genellikle sayfa yüklemesi başına düzinelerce sorgu.

DNS Hiyerarşisi: Ad Alanı Nasıl Yapılandırılmıştır

DNS, ters çevrilmiş bir ağaç olarak düzenlenmiştir. Bu yapıyı anlamak, çözümlemenin neden bu şekilde çalıştığını anlamak için temel öneme sahiptir.

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• Kök Bölge (.): IANA tarafından yönetilmektedir. Verisign, NASA ve ICANN gibi kuruluşlar tarafından işletilen 13 mantıksal kök sunucu adresi (A’dan M’ye) bulunmaktadır. Pratikte bunlar, anycast yönlendirme aracılığıyla yüzlerce fiziksel makine tarafından sunulmaktadır.
• Üst Düzey Alan Adları (TLD’ler): .com, .net, .org gibi genel TLD’ler ve .uk, .de, .md gibi ülke kodu TLD’leri. Her TLD’nin kendi yetkili ad sunucuları kümesi vardır.
• İkinci Düzey Alan Adları (SLD’ler): Kayıt ettirdiğiniz alan adı — example.com. Bu bölgenin yetkili DNS’i, alan adını kayıt ettiren kişi tarafından kontrol edilir.
• Alt Alan Adları: www, mail, api, staging — bunlar SLD bölgesindeki kayıtlardır ve tamamen alan adı sahibi tarafından kontrol edilir.

Adım Adım: Bir DNS Sorgusu Nasıl Çözümlenir

Tam bir özyinelemeli DNS çözümlemesi, yedi farklı ağ alışverişine kadar içerir. İşte tam sıralama:

Adım 1 — Tarayıcı Önbellek Kontrolü

Tarayıcınıza www.example.com yazdığınızda, işletim sistemi önce yerel DNS önbelleğini kontrol eder. Linux’ta bu, systemd-resolved tarafından yönetilebilir; Windows’ta ise DNS İstemci hizmeti tarafından. Geçerli bir önbelleğe alınmış kayıt mevcutsa ve TTL (Yaşam Süresi) sona ermemişse, çözümleme burada durur.

Linux’ta yerel DNS önbelleğini şu komutla inceleyebilirsiniz:

resolvectl statistics

Veya şu komutla temizleyebilirsiniz:

sudo resolvectl flush-caches

Windows’ta:

ipconfig /displaydns
ipconfig /flushdns

Adım 2 — Özyinelemeli Çözümleyici Sorgusu

Önbellekte yanıt yoksa, işletim sistemi sorguyu yapılandırılmış özyinelemeli çözümleyiciye (özyinelemeli DNS sunucusu veya tam hizmet çözümleyici olarak da adlandırılır) iletir. Bu genellikle şunlardan biridir:

• İSS’nizin çözümleyicisi (DHCP aracılığıyla atanır)
• Genel bir çözümleyici: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)
• Kendi VPS Hosting altyapınızda Unbound veya BIND gibi kendi barındırdığınız bir çözümleyici

Özyinelemeli çözümleyici ağır işi üstlenir. DNS hiyerarşisini sizin adınıza gezer ve gelecekteki sorguları daha hızlı yanıtlamak için sonuçları önbelleğe alır.

Adım 3 — Kök Sunucu Yönlendirmesi

Özyinelemeli çözümleyici, 13 kök sunucu kümesinden birini sorgular. Kök sunucu, www.example.com‘nin IP adresini bilmez. Bunun yerine bir yönlendirme döndürür — .com TLD bölgesi için yetkili ad sunucularının listesi ve bunların IP adresleri (yapıştırıcı kayıtlar olarak adlandırılır).

Adım 4 — TLD Ad Sunucusu Sorgusu

Çözümleyici, .com TLD ad sunucularını (Verisign tarafından işletilir) sorgular. Bu sunucular da nihai yanıtı tutmaz. Özellikle example.com için yetkili ad sunucularını içeren başka bir yönlendirme döndürürler (örn. ns1.example.com, ns2.example.com).

Adım 5 — Yetkili Ad Sunucusu Sorgusu

Çözümleyici, example.com için yetkili ad sunucusunu sorgular. Bu sunucu gerçek bölge dosyasını tutar ve kesin yanıtı döndürür — IPv4 adresini içeren A kaydı (veya IPv6 için AAAA).

Adım 6 — Yanıtın Önbelleğe Alınması ve İletilmesi

Özyinelemeli çözümleyici, yanıtı kaydın TTL değerine göre önbelleğe alır (örn. 300 saniye = 5 dakika, 86400 saniye = 24 saat). Ardından IP adresini istemcinin işletim sistemine döndürür; işletim sistemi de bunu tarayıcıya iletir.

Adım 7 — TCP/IP Bağlantısı

Tarayıcı, çözümlenen IP adresini kullanarak bir TCP bağlantısı açar (genellikle HTTPS için 443 numaralı bağlantı noktasında). DNS’in görevi artık tamamlanmıştır. Web sunucusu yanıt verir ve sayfa yüklenir.

Bu sürecin tamamı — 2’den 6’ya kadar olan adımlar — sıcak çözümleyici önbelleğinde genellikle 20–120 milisaniye içinde, tüm hiyerarşi düzeylerini geçen tamamen soğuk, önbelleksiz bir çözümlemede ise 500 milisaniyenin altında tamamlanır.

DNS Kayıt Türleri: Teknik Başvuru Kılavuzu

CAA kayıtları özel bir ilgiyi hak etmektedir: Sertifika Yetkililerine, alan adınız için SSL Sertifikaları düzenleme yetkisine sahip kuruluşları bildirirler — bu, sıklıkla göz ardı edilen kritik bir güvenlik kontrolüdür.

DNS Sorgu Türleri: Özyinelemeli, Yinelemeli ve Özyinelemesiz

Son kullanıcı cihazlarının çoğu, yapılandırılmış çözümleyicilerine özyinelemeli sorgular gönderir. Çözümleyicinin kendisi ise hiyerarşiyi gezerken yinelemeli sorgular kullanır.

TTL: En Yanlış Anlaşılan DNS Parametresi

TTL (Yaşam Süresi), bir DNS kaydının çözümleyiciler ve istemciler tarafından önbelleğe alınabileceği saniye sayısıdır. Alan adı sahibi tarafından bölge dosyasında belirlenir.

• Düşük TTL (60–300 saniye): Değişikliklerin daha hızlı yayılması. Planlı geçişler, IP değişiklikleri veya yük devretme olaylarından önce zorunludur. Yetkili sunuculardaki sorgu yükünü artırır.
• Yüksek TTL (3600–86400 saniye): Çözümleyici yükünü azaltır ve tekrarlanan sorguları hızlandırır. Değişikliklerin küresel olarak yayılması daha uzun sürer.

Kritik operasyonel bilgi: Bir sunucu geçişi veya IP değişikliği planlarken, değişiklikten en az 48 saat önce TTL’nizi 300 saniyeye düşürün. Bu, A kaydını güncellediğinizde hiçbir çözümleyicinin eski değeri 5 dakikadan fazla önbellekte tutmamasını sağlar. Bunu yapmamak, geçişler sırasında uzun süreli kesintilerin en yaygın nedenlerinden biridir.

Alan Adı Kaydı aracılığıyla bir alan adı kaydettirip yeni bir sunucuya yönlendirdiğinizde, yayılma süresi doğrudan önceki TTL değeri tarafından belirlenir — sıklıkla yanlış aktarılan “24–48 saatlik” keyfi bir kuralla değil.

DNS Aktarım Protokolleri: UDP, TCP, DoH ve DoT

Geleneksel DNS, 512 baytın altındaki sorgular için UDP port 53 üzerinden çalışır. Bu boyutu aşan yanıtlar, TCP port 53‘e geri dönüşü tetikler. DNSSEC yanıtları, bölge aktarımları (AXFR) ve büyük TXT kayıtları genellikle TCP gerektirir.

Modern DNS gizlilik protokolleri bu ortamı önemli ölçüde değiştirmiştir:

DoH ile DoT arasındaki gerçek operasyonel fark: DoH, DNS’i 443 numaralı bağlantı noktasında HTTPS trafiğinin içine tüneller ve bunu normal web trafiğinden ayırt edilemez hale getirir. Bu gizlilik açısından kullanışlıdır, ancak kurumsal ağ izleme ve filtrelemeyi önemli ölçüde zorlaştırır. DoT ise ayrı bir bağlantı noktası (853) kullanır; ağ yöneticileri bunu bağımsız olarak izleyebilir, engelleyebilir veya inceleyebilir. Bir Dedicated Server üzerinde kendi yönettiğiniz altyapı için yerel bir DoT veya DoH çözümleyicisi çalıştırmak, hem gizlilik hem de çözümleme politikası üzerinde tam kontrol sağlar.

DNSSEC: DNS için Kriptografik Bütünlük

DNSSEC (DNS Güvenlik Uzantıları), DNS yanıtlarına kriptografik imzalar zinciri ekleyerek çözümleyicilerin bir yanıtın gerçek olduğunu ve aktarım sırasında değiştirilmediğini doğrulamasına olanak tanır. DNS önbellek zehirlenmesine (Kaminsky saldırısı) ve ortadaki adam DNS sahteciliğine karşı koruma sağlar.

DNSSEC, DNS trafiğini şifrelemez — yalnızca imzalar. İmza zinciri şu şekilde çalışır:

1. Bölge sahibi bir Bölge İmzalama Anahtarı (ZSK) ve bir Anahtar İmzalama Anahtarı (KSK) oluşturur
2. Her DNS kayıt kümesi ZSK ile imzalanarak RRSIG kayıtları üretilir
3. KSK, DNSKEY kayıt kümesini imzalar
4. Bir DS (Yetki Devri İmzalayıcı) kaydı üst bölgede yayımlanır (örn. .com), böylece köke uzanan güven zinciri oluşturulur

DNSSEC’i etkinleştirmek, finansal işlemler, kimlik doğrulama veya e-posta yöneten her alan adı için şiddetle tavsiye edilir. Yanlış yapılandırılmış DNSSEC — özellikle süresi dolmuş bir imza veya eşleşmeyen bir DS kaydı — doğrulama yapan çözümleyiciler için tam çözümleme hatasına yol açar; bu, DNSSEC’in hiç olmamasından daha zor bir hata durumudur.

Yaygın DNS Hataları ve Nasıl Teşhis Edilir

NXDOMAIN — Var Olmayan Alan Adı

Yetkili sunucu, alan adının mevcut olmadığını doğruladı. Yaygın nedenler: alan adında yazım hatası, süresi dolmuş alan adı kaydı, silinmiş DNS kaydı.

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL — Sunucu Hatası

Çözümleyici sorguyu tamamlayamadı. Yaygın nedenler: DNSSEC doğrulama hatası, erişilemeyen yetkili sunucu, yanlış yapılandırılmış bölge dosyası.

dig +dnssec example.com
# Look for: status: SERVFAIL

DNSSEC doğrulamasını atlamak ve sorunu izole etmek için:

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

Eski Önbellek / Yayılma Gecikmesi

Bir DNS kaydı güncellendikten sonra, eski değerler TTL sona erene kadar çözümleyici önbelleklerinde kalmaya devam eder. Çözümleyici önbelleğini atlayarak doğrudan yetkili sunucuyu sorgulamak için:

dig @ns1.example.com www.example.com

DNS Yayılımını Küresel Olarak Kontrol Etme

Yayılım durumunu kontrol etmek için belirli genel çözümleyicilerle dig kullanın:

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

Barındırma Ortamlarında DNS: Pratik Yapılandırmalar

Bir cPanel ile VPS üzerinde bir web sitesi veya uygulama dağıttığınızda, DNS yönetimi genellikle WHM’nin DNS kümesi veya cPanel’in Bölge Düzenleyicisi aracılığıyla gerçekleştirilir. Temel bölge dosyası yapısını anlamak, GUI’nin sunmadığı değişiklikler yapmanıza olanak tanır.

example.com için minimal bir bölge dosyası şöyle görünür:

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

E-posta Barındırma‘nın düzgün çalışması için MX kaydının doğrudan bir IP adresine değil, bir ana bilgisayar adına işaret etmesi gerekir; bu ana bilgisayar adının kendisi de bir A kaydı aracılığıyla çözümlenmelidir. Yaygın bir yanlış yapılandırma, MX‘yi doğrudan bir IP’ye yönlendirmektir — bu, RFC 2821’i ihlal eder ve katı posta sunucularında iletim hatalarına neden olur.

DNS Performansı: Çözümleme Hızını Gerçekte Ne Etkiler

• Çözümleyici yakınlığı: İstemciye coğrafi olarak yakın (veya aynı ağdaki) bir çözümleyici, gidiş-dönüş süresini önemli ölçüde azaltır.
• Önbellek isabet oranı: Makul TTL değerlerine sahip yüksek trafikli alan adları neredeyse her zaman önbellekten sunulur. Soğuk önbellek çözümlemesi 5–20 kat daha yavaştır.
• Anycast yönlendirme: Kök sunucular ve büyük genel çözümleyiciler anycast kullanır; sorguları otomatik olarak en yakın fiziksel düğüme yönlendirir.
• Sayfa başına DNS arama sayısı: Tek bir web sayfası 20–50 DNS sorgusu tetikleyebilir (CDN varlıkları, analitik, yazı tipleri, reklam ağları). Tarayıcılar bunları paralel olarak işler, ancak her benzersiz ana bilgisayar adı kendi aramasını gerektirir.
• DNS ön getirme: Modern tarayıcılar, ihtiyaç duyulmadan önce üçüncü taraf ana bilgisayar adlarını çözümlemek için <link rel="dns-prefetch" href="//cdn.example.com">‘yi destekler; bu da algılanan gecikmeyi azaltır.

DNS ile Alternatif Çözümleme Mekanizmaları Karşılaştırması

/etc/hosts dosyası, neredeyse her işletim sisteminde DNS’den önce değerlendirilir. Bu, yerel geliştirme için son derece değerlidir — herhangi bir DNS altyapısına dokunmadan myapp.local‘yi 127.0.0.1‘e eşleyebilirsiniz.

Temel Çıkarımlar ve Karar Kontrol Listesi

Herhangi bir üretim ortamı için DNS yapılandırırken veya sorun giderirken bu kontrol listesini kullanın:

• Herhangi bir sunucu geçişinden önce: En az 48 saat öncesinden TTL’yi 300 saniyeye düşürün
• E-posta teslim edilebilirliği için: MX, SPF (TXT), DKIM (TXT), DMARC (TXT) ve PTR kayıtlarının doğru yapılandırıldığını doğrulayın
• Güvenlik için: Alan adınızda DNSSEC’i etkinleştirin ve sertifika düzenlemeyi kısıtlamak için CAA kayıtları ekleyin
• Gizlilik için: İstemci cihazlarda ve sunucularda DoT veya DoH kullanın; güvenilmeyen ağlar üzerinden düz metin DNS göndermekten kaçının
• Performans için: Kararlı kayıtlar için TTL’yi 3600–86400 olarak ayarlayın; 300‘i yalnızca sık değişen kayıtlar için kullanın
• Teşhis için: Yayılma gecikmesini gerçek bir yanlış yapılandırmadan ayırt etmek için her zaman dig @ns1.yourdomain.com ile doğrudan yetkili sunucuyu sorgulayın
• Bölge yönetimi için: Bir bölge dosyasını her değiştirdiğinizde SOA seri numarasını artırın — çözümleyiciler değişiklikleri tespit etmek için bunu kullanır
• Barındırma için: Kayıt kuruluşunuzun ad sunucusu delegasyonunun bölge dosyanızdaki NS kayıtlarıyla eşleştiğini doğrulayın — uyumsuzluk, alan adı transferlerinden sonra “DNS çalışmıyor” sorunlarının en yaygın tek nedenidir

Sıkça Sorulan Sorular

DNS çözümleyici ile yetkili DNS sunucusu arasındaki fark nedir?

Özyinelemeli çözümleyici (örn. 8.8.8.8), cihazınız adına DNS hiyerarşisini sorgulayan ve sonuçları önbelleğe alan bir aracıdır. Yetkili ad sunucusu ise belirli bir alan adı için gerçek bölge kayıtlarını tutar ve kesin yanıtlar sağlar. Çözümleyiciniz birçok yetkili sunucuyu sorgular; alan adınızın yetkili sunucusu ise yalnızca barındırdığı bölgeler için yanıt verir.

Bir kaydı güncelledikten sonra DNS yayılımı neden zaman alır?

Yayılma gecikmesi, TTL tabanlı önbelleklemeden kaynaklanır. Eski kaydınızı daha önce önbelleğe almış olan her çözümleyici, TTL sona erene kadar onu sunmaya devam edecektir. TTL’niz 86400 (24 saat) ise, çözümleyiciler güncellemenizden sonra 24 saate kadar eski kaydı sunabilir. Bu bir hata değildir — DNS’i ölçeklenebilir kılan amaçlanan önbellekleme mekanizmasıdır.

DNS sızıntısı nedir ve neden önemlidir?

DNS sızıntısı, cihazınızın VPN veya gizlilik aracı kullanırken bile DNS sorgularını amaçlanan çözümleyicinizin dışına — genellikle İSS’nizin çözümleyicisine — göndermesi durumunda oluşur. Bu, göz atma etkinliğinizi İSS’nize ifşa eder. dnsleaktest.com adresinde sızıntıları test edebilir ve VPN istemcinizi DNS yönlendirmesini kendi çözümleyicisi üzerinden zorlamak üzere yapılandırarak bunları düzeltebilirsiniz.

DNS bir saldırı vektörü olarak kullanılabilir mi?

Evet. Yaygın DNS tabanlı saldırılar arasında önbellek zehirlenmesi (çözümleyicinin önbelleğine sahte kayıtlar enjekte etme), DNS amplifikasyon DDoS (bir hedefi büyük DNS yanıtlarıyla doldurmak için açık çözümleyicileri kullanma), DNS ele geçirme (sorguları kötü amaçlı sunuculara yönlendirme) ve DNS tünelleme (verileri DNS sorgu dizelerine kodlayarak sızdırma) sayılabilir. DNSSEC, önbellek zehirlenmesini azaltır; yetkili sunuculardaki hız sınırlama ve yanıt hızı sınırlama (RRL) ise amplifikasyonu azaltır.

Herhangi bir alan adı için yetkili ad sunucularını nasıl bulabilirim?

Temiz çıktı için NS kayıt türü ve +short bayrağıyla dig kullanın:

dig NS example.com +short

Kökten yetkili sunucuya kadar tam yetki devri yolunu izlemek için şunu kullanın:

dig +trace example.com

Bu, her yönlendirme adımını gösterir — kök → TLD → yetkili — ve yetki devri yanlış yapılandırmalarını teşhis etmenin en güvenilir yoludur.