DNS Nedir ve DNS Hiyerarşisi Nedir? Eksiksiz Teknik Rehber

DNS (Domain Name System), `www.example.com` gibi insan tarafından okunabilir alan adlarını `192.0.2.1` gibi makine tarafından okunabilir IP adreslerine çeviren hiyerarşik, dağıtık bir adlandırma sistemidir. DNS olmadan, her internet kullanıcısının etkileşime girdiği her web sitesi, API uç noktası veya posta sunucusu için sayısal adresleri ezberlemesi gerekirdi. DNS, modern interneti büyük ölçekte gezilebilir kılan protokoldür.

Özünde DNS, küresel olarak dağıtılmış bir veritabanı işlevi görür. Sorgular, yapılandırılmış bir yetkilendirme zinciri aracılığıyla çözümlenir — en üstteki kök sunuculardan, üst düzey alan (TLD) sunucuları aracılığıyla, belirli bir alan için gerçek kayıtları tutan yetkili ad sunucularına kadar. Bu mimari, DNS’yi aynı anda hızlı, dayanıklı ve genişletilebilir kılan şeydir.

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

“Telefon rehberi” analojisi yararlı bir başlangıç noktasıdır, ancak DNS’nin üretim ortamlarında gerçekte ne yaptığını büyük ölçüde küçümsemektedir. DNS şunları destekler:

• Ad çözümleme — FQDN’leri (Tam Nitelikli Alan Adları) IPv4 ve IPv6 adreslerine dönüştürme
• E-posta yönlendirme — MX kayıtları SMTP trafiğini doğru posta altyapısına yönlendirir
• Hizmet keşfi — SRV kayıtları uygulamaların hizmetleri dinamik olarak bulmasına olanak tanır (SIP, XMPP ve Kubernetes’te yoğun olarak kullanılır)
• Trafik mühendisliği — Geo-DNS ve ağırlıklı yönlendirme kayıtları küresel yük dengeleme ve gecikmeye dayalı yük devretmeyi mümkün kılar
• Güvenlik uygulaması — TXT kayıtları SPF, DKIM ve DMARC politikalarını taşır; DNSSEC kriptografik doğrulama ekler
• CDN orkestrasyonu — CNAME düzleştirme ve Anycast yönlendirme, CDN’lerin en yakın kenar düğümünü şeffaf bir şekilde sunmasına olanak tanır

Bir VPS Hosting ortamı veya Dedicated Server yöneten herkes için DNS’yi bu düzeyde anlamak isteğe bağlı değildir — yanlış yapılandırılmış DNS, uygulama kesintilerinin, e-posta teslim edilebilirlik hatalarının ve SSL sağlama hatalarının en yaygın temel nedenlerinden biridir.

DNS Çözümleme Süreci: Adım Adım

Bir kullanıcı tarayıcıya `www.example.com` yazdığında aşağıdaki dizi gerçekleşir. Her adımı anlamak, çözümleme hatalarını teşhis etmek ve TTL stratejilerini optimize etmek için kritik öneme sahiptir.

Adım 1: Yerel Önbellek Kontrolü

İşletim sistemi önce yerel DNS önbelleğini kontrol eder (önceki aramalardan doldurulmuş). Linux’ta bu, `systemd-resolved` veya `nscd` içerebilir. Windows’ta DNS İstemci hizmeti bu önbelleği yönetir. TTL süresi içinde geçerli bir önbelleğe alınmış kayıt mevcutsa, çözümleme burada durur.

Adım 2: Stub Çözümleyiciden Özyinelemeli Çözümleyiciye

Yerel önbellekte eşleşme yoksa, işletim sistemi stub çözümleyicisi sorguyu bir özyinelemeli DNS çözümleyicisine iletir — genellikle ISP’nizin çözümleyicisi veya şunlar gibi yapılandırılmış bir genel çözümleyici:

• Google Public DNS: `8.8.8.8` / `8.8.4.4`
• Cloudflare: `1.1.1.1` / `1.0.0.1`
• Quad9: `9.9.9.9`

Özyinelemeli çözümleyici, istemci adına DNS hiyerarşisini geçme işinin ağır kısmını üstlenir.

Adım 3: Kök Sunucu Sorgusu

Özyinelemeli çözümleyicinin önbelleğe alınmış bir yanıtı yoksa, 13 kök sunucu kümesinden birine (`a.root-servers.net` ile `m.root-servers.net` arasında adreslenmiş) sorgu gönderir. Bunlar 13 ayrı makine değildir — ICANN, Verisign, NASA ve RIPE NCC dahil kuruluşlar tarafından işletilen, küresel olarak dağıtılmış 1.500’den fazla fiziksel örneğe sahip 13 Anycast adres grubudur.

Kök sunucu bir IP adresi döndürmez. Sorgulanan sonek için yetkili TLD sunucusunun adresini içeren bir yönlendirme döndürür (örn. `.com`).

Adım 4: TLD Sunucu Sorgusu

Özyinelemeli çözümleyici uygun TLD ad sunucusunu sorgular. `.com` için bu Verisign tarafından işletilmektedir. TLD sunucusu başka bir yönlendirme döndürür — belirli ikinci düzey alan için yetkili ad sunucuları (örn. `ns1.example.com`).

Adım 5: Yetkili Ad Sunucusu Sorgusu

Özyinelemeli çözümleyici, `example.com` için bölge dosyasını tutan yetkili ad sunucusunu sorgular. Bu sunucu gerçek DNS kaydını döndürür — örneğin, `www.example.com` adresini `93.184.216.34` ile eşleştiren bir A kaydı.

Adım 6: Yanıt Önbelleğe Alma ve Teslim

Özyinelemeli çözümleyici yanıtı kaydın TTL (Yaşam Süresi) değerine göre önbelleğe alır, ardından IP adresini istemcinin stub çözümleyicisine döndürür ve bu da tarayıcıya iletir. Tarayıcı daha sonra o IP adresine bir TCP bağlantısı (veya HTTP/3 için QUIC) açar.

Kritik nüans: TTL değerleri, alan sahibi tarafından yetkili sunucuda ayarlanır. 300 saniyelik bir TTL, kaydın yeniden sorgulanmadan önce 5 dakika boyunca önbelleğe alınabileceği anlamına gelir. Bir geçiş veya olay müdahalesi sırasında, yayılma gecikmelerini en aza indirmek için TTL’leri önceden düşürmek (60–300 saniyeye) standart bir operasyonel uygulamadır.

DNS Hiyerarşisi: Mimari ve Bileşenler

DNS ad alanı ters çevrilmiş bir ağaç olarak yapılandırılmıştır. Ağaçtaki her düğüm bir etikettir ve yapraktan köke kadar tam bir yol bir alan adı oluşturur. `www.example.com.` içindeki sondaki nokta kökü temsil eder.

Düzey 1: Kök Bölge

Kök bölge, boş bir etiketle (`.`) temsil edilen DNS hiyerarşisinin zirvesidir. Mevcut her üst düzey alan için TLD sunucularına işaret eden NS kayıtları içerir. Kök bölge dosyası IANA (İnternet Atanmış Numaralar Otoritesi) tarafından yönetilmekte olup şu anda 1.500’den fazla TLD için yetkilendirmeler içermektedir.

Kök sunucular bir güven çıpası modeli altında çalışır — DNSSEC doğrulama zincirleri nihayetinde son derece denetimli bir tören süreci aracılığıyla yönetilen kök bölgenin Anahtar İmzalama Anahtarında (KSK) sonlanır.

Düzey 2: Üst Düzey Alanlar (TLD’ler)

TLD sunucuları, kendi sonekleri altında kayıtlı tüm alanlar için yetkilidir. Birkaç kategori vardır:

Düzey 3: İkinci Düzey Alanlar (SLD’ler) ve Alt Alanlar

İkinci düzey alan, TLD’nin hemen solundaki etikettir — `example.com` içindeki `example`. Bu, alan kayıt yaptıranların satın aldığı ve yönettiği birimdir. Alan Adı Kaydı gibi bir hizmet aracılığıyla bir alan adı kaydettiğinizde, o SLD için DNS yetkilendirmesini kontrol etme hakkını ediniyorsunuz.

Alt alanlar, SLD’ye eklenen etiketlerdir (`www`, `mail`, `api`, `blog`). Bunlar tamamen yetkili ad sunucusunun bölge dosyası içinde yapılandırılır — ek kayıt gerekmez. Alt alan derinliği teorik olarak sınırsızdır, ancak pratik sınırlar mevcuttur (toplam FQDN uzunluğu 253 karakteri geçmemeli; her etiket 63 karakteri geçmemelidir).

Düzey 4: Yetkili Ad Sunucuları ve Bölge Dosyaları

Yetkili ad sunucuları, bir alanın DNS kayıtları için gerçeğin kaynağıdır. Sorguları AA (Yetkili Yanıt) bayrağı ayarlanmış olarak yanıtlarlar. Bölge dosyası, bir alan için tüm kaynak kayıtlarını içeren düz metin bir veritabanıdır.

Her yöneticinin bilmesi gereken temel DNS kayıt türleri:

CAA kayıtları özel ilgi hak eder: yetkisiz sertifika otoritelerinin alanınız için SSL Sertifikaları vermesini engelleyen, sıklıkla göz ardı edilen bir güvenlik kontrolüdür. CAA kaydınız kullandığınız CA’yı listelemiyorsa, sertifika verimi başarısız olacaktır.

Özyinelemeli Çözümleyiciler ve Yetkili Sunucular: Kritik Bir Ayrım

Bu iki bileşen mimari açıdan farklıdır ve yeni başlayanlar tarafından sıklıkla karıştırılır.

Tek bir sunucu teknik olarak her iki rolü de üstlenebilir, ancak güvenlik ve performans etkileri nedeniyle üretimde bu kesinlikle önerilmez (açık çözümleyiciler DNS amplifikasyon DDoS saldırıları için bir vektördür).

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

Standart DNS’nin yerleşik kimlik doğrulaması yoktur — yanıtlar önbellek zehirleme saldırıları yoluyla sahte olabilir (Kaminsky saldırısı en ünlüsüdür). DNSSEC (DNS Güvenlik Uzantıları), DNS kayıtlarına dijital imzalar ekleyerek bunu ele alır.

DNSSEC güven zinciri şu şekilde çalışır:

1. Her bölge kayıtlarını bir Bölge İmzalama Anahtarı (ZSK) ile imzalar
2. ZSK’nın genel anahtarı bir DNSKEY kaydı olarak yayınlanır
3. Üst bölge, alt bölgenin DNSKEY’inin bir karmasını imzalayarak bir DS (Yetkilendirme İmzalayıcı) kaydı oluşturur
4. Bu zincir, kök bölgeden (nihai güven çıpası) bireysel kayıtlara kadar uzanır

DNSSEC doğrulaması özyinelemeli çözümleyici düzeyinde gerçekleşir. Doğrulayıcılar imzaları yayınlanan anahtarlara karşı kontrol eder; doğrulama başarısız olursa, çözümleyici potansiyel olarak zehirlenmiş bir yanıt yerine `SERVFAIL` döndürür.

Operasyonel uyarı: DNSSEC, bölge yönetimi karmaşıklığını önemli ölçüde artırır. Anahtar geçişleri, imza sona ermesi ve üst bölgeyle DS kaydı senkronizasyonu yaygın kesinti kaynaklarıdır. Üretimde etkinleştirmeden önce DNSSEC yapılandırmasını `dnsviz.net` gibi araçlarla her zaman test edin.

Hosting Ortamlarında DNS: Pratik Değerlendirmeler

Yayılma ve TTL

“DNS yayılması” yaygın olarak yanlış kullanılan bir terimdir. Gerçekte gerçekleşen şey önbellekler genelinde TTL sona ermesidir. Bir A kaydını değiştirdiğinizde, eski değeri önbelleğe almış çözümleyiciler TTL sona erene kadar onu sunmaya devam edecektir. Standart DNS’de aktif bir “itme” mekanizması yoktur.

Geçişler sırasında kesinti süresini en aza indirmek için:

1. Değişiklikten en az 24–48 saat önce etkilenen kayıtların TTL’sini 300 saniyeye düşürün (mevcut önbelleklerin sona ermesine izin vererek)
2. DNS değişikliğini yapın
3. Yeni yapılandırmanın kararlı olduğunu doğruladıktan sonra TTL’yi üretim değerine (3600–86400 saniye) geri yükleyin

Bölünmüş Ufuk DNS

Hem genel hem de özel ağ segmentlerine sahip ortamlarda — VPS Hosting veya Dedicated Servers‘da yaygın — bölünmüş ufuk DNS (aynı zamanda bölünmüş beyin DNS olarak da adlandırılır) sorgunun kaynağına göre farklı yanıtlar sunar. Dahili istemciler `db.example.com` adresini özel bir RFC 1918 adresine çözer; harici istemciler genel IP veya yük dengeleyici adresi alır. Bu, BIND’de `view` direktifleri kullanılarak veya PowerDNS’de Lua betikleme yoluyla uygulanır.

Ters DNS (PTR Kayıtları)

Ters DNS, `in-addr.arpa` (IPv4) veya `ip6.arpa` (IPv6) bölgelerini kullanarak IP adreslerini ana bilgisayar adlarına geri eşler. PTR kayıtları şunlar için kritiktir:

• E-posta teslim edilebilirliği — birçok alıcı posta sunucusu, eşleşen PTR kaydı olmayan IP’lerden gelen postaları reddeder veya ağır şekilde cezalandırır
• Güvenlik günlüğü — güvenlik duvarı ve erişim günlüklerini ana bilgisayar adlarıyla zenginleştirme
• Uyumluluk — bazı düzenleyici çerçeveler denetim izleri için ters DNS gerektirir

Bir E-posta Hosting kurulumu veya kendi kendini yöneten bir posta sunucusu çalıştırıyorsanız, hosting sağlayıcınızın sunucunuzun IP adresi için bir PTR kaydı yapılandırdığından emin olun.

DNS ve SSL Sertifika Sağlama

DNS-01 ACME zorlukları (Let’s Encrypt ve diğer CA’lar tarafından kullanılır), alan kontrolünü kanıtlamak için alanınızın bölgesine belirli bir TXT kaydı yazmayı gerektirir. Bu yöntem, joker karakter sertifikası verimi için gereklidir. Otomatik sertifika yönetimi (`certbot` veya `acme.sh` aracılığıyla), bu TXT kayıtlarını programatik olarak oluşturmak ve kaldırmak için DNS sağlayıcınıza API erişimi gerektirir.

Yaygın DNS Hata Modları ve Tanılama

Hata modlarını anlamak, yetkin bir yöneticiyi yalnızca öğreticileri takip eden birinden ayıran şeydir.

NXDOMAIN — Sorgulanan ad bölgede mevcut değil. Yaygın nedenler: kayıt adında yazım hatası, bölge yüklenmemiş veya yetkilendirme yanlış ad sunucularına işaret ediyor.

SERVFAIL — Sunucu sorguyu tamamlayamadı. Yaygın nedenler: DNSSEC doğrulama hatası, erişilemeyen yetkili sunucular veya bozuk bölge dosyası (SOA veya NS kayıtlarında sözdizimi hatası).

Eski önbellek — Çözümleyici süresi dolmuş veya güncel olmayan bir kayıt sunuyor. Çözümleyici önbelleklerini atlamak için `dig +nocache` kullanın veya doğrudan yetkili sunucuyu sorgulayın.

Hatalı yetkilendirme — Üst bölgenin NS kayıtları, bölge için gerçekte yetkili olmayan (bölgeyi yüklememiş) ad sunucularına işaret ediyor. Bu, aralıklı çözümleme hatalarına neden olan sessiz bir hata modudur.

Temel tanılama komutları:

“`bash

Query a specific resolver for an A record

dig @8.8.8.8 www.example.com A

Trace the full resolution path from root

dig +trace www.example.com

Check authoritative answer directly

dig @ns1.example.com www.example.com A +norec

Verify reverse DNS

dig -x 93.184.216.34

Check DNSSEC chain

dig www.example.com A +dnssec

Inspect SOA record (useful for checking serial after zone update)

dig example.com SOA

“`

DNS Performans Optimizasyonu

• Anycast dağıtımı — Anycast aracılığıyla dağıtılan yetkili sunucular, coğrafi olarak en yakın düğümden yanıt vererek sorgu gecikmesini azaltır
• TTL ayarı — Daha yüksek TTL’ler (3600–86400s) kararlı kayıtlar için çözümleyici yükünü azaltır ve önbellek isabet oranlarını artırır; daha düşük TTL’ler (60–300s) dinamik altyapı için daha hızlı yük devretmeyi mümkün kılar
• Negatif önbelleğe alma — NXDOMAIN yanıtları, SOA’nın minimum TTL alanında belirtilen süre boyunca önbelleğe alınır; aşırı uzun negatif TTL’ler yanlış yapılandırmadan kurtarma işlemini geciktirir
• EDNS İstemci Alt Ağı (ECS) — Özyinelemeli çözümleyicilerin istemcinin IP’sinin bir bölümünü yetkili sunuculara iletmesine olanak tanıyarak daha doğru coğrafi yönlendirme kararları verir (bir miktar gizlilik pahasına)
• HTTPS üzerinden DNS (DoH) / TLS üzerinden DNS (DoT) — DNS sorgularını aktarım sırasında şifreler, ISP düzeyinde müdahaleyi ve manipülasyonu önler; gizlilik açısından hassas dağıtımlar için giderek daha önemli hale gelmektedir

Karar Matrisi: Doğru DNS Yapılandırmasını Seçme

Teknik Temel Çıkarımlar

• DNS çözümlemesi çok adımlı bir yetkilendirme zinciridir: stub çözümleyici > özyinelemeli çözümleyici > kök > TLD > yetkili sunucu
• 13 kök sunucu kümesi (bireysel makineler değil) küresel olarak 1.500’den fazla fiziksel örneğe hizmet vermek için Anycast kullanır
• TTL önbellek süresini kontrol eder — “yayılma” yalnızca önbelleklerin sona ermesini beklemektir, aktif bir itme değil
• Yetkili sunucular bölge dosyalarını tutar; özyinelemeli çözümleyiciler önbelleğe alır ve iletir — iki rolü asla karıştırmayın
• DNSSEC kriptografik doğrulama ekler ancak operasyonel karmaşıklık getirir; anahtar geçişleri ve DS senkronizasyonu yaygın hata noktalarıdır
• PTR kayıtları posta sunucusu dağıtımları ve güvenlik günlüğü için vazgeçilmezdir
• CAA kayıtları hangi sertifika otoritelerinin alanınız için SSL sertifikası verebileceğini kısıtlar
• Hatalı yetkilendirmeler ve eski negatif önbellekler en sinsi DNS hata modları arasındadır
• Çözümleme sorunlarını kökten aşağıya doğru teşhis etmek için çözümleyici düzeyindeki çıktıya güvenmek yerine her zaman `dig +trace` kullanın

Sıkça Sorulan Sorular

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

Özyinelemeli çözümleyici, bir istemci adına DNS hiyerarşisini sorgular ve yanıtları önbelleğe alır. Yetkili DNS sunucusu, bir alan için gerçek bölge dosyasını tutar ve AA bayrağı ayarlanmış kesin yanıtlar döndürür. Bunlar mimari açıdan ayrı rollerdir, ancak teknik olarak tek bir daemon her ikisini de gerçekleştirebilir.

Bir kaydı değiştirdikten sonra DNS yayılması neden bu kadar uzun sürer?

DNS aktif bir anlamda “yayılmaz”. Çözümleyiciler kayıtları, kayıtta ayarlanan TTL süresi boyunca önbelleğe alır. A kaydınızın TTL’si 86400 saniye (24 saat) ise, eski değeri önbelleğe almış çözümleyiciler onu 24 saate kadar sunmaya devam edecektir. Bunu en aza indirmek için, değişiklik yapmadan en az 24 saat önce TTL’yi 300 saniyeye düşürün.

SERVFAIL yanıtına ne sebep olur ve nasıl düzeltirim?

SERVFAIL en yaygın olarak DNSSEC doğrulama hatasından, erişilemeyen yetkili ad sunucularından veya bozuk/hatalı biçimlendirilmiş bölge dosyasından kaynaklanır. DNSSEC sorunlarını kontrol etmek için `dig +dnssec` kullanın, yetkili sunucularınızın erişilebilir ve yanıt verdiğini doğrulayın ve bölge dosyası sözdizimini `named-checkzone` ile doğrulayın.

Alanım için DNSSEC’e ihtiyacım var mı?

DNSSEC, hassas işlemleri, e-posta altyapısını veya finansal hizmetleri yöneten alanlar için kesinlikle önerilir. Önbellek zehirleme saldırılarını önler. Ancak operasyonel yük ekler — anahtar geçişleri ve DS kaydı yönetimi dikkatli otomasyon gerektirir. Çoğu üretim alanı için güvenlik faydası karmaşıklığından daha ağır basar.

İşlevsel bir posta sunucusu için hangi DNS kayıtları gereklidir?

En azından: posta sunucunuzun ana bilgisayar adına işaret eden bir MX kaydı, bu ana bilgisayar adını çözen bir A kaydı, sunucunuzun IP’sinde bir PTR kaydı (hosting sağlayıcınız tarafından yapılandırılmış) ve SPF, DKIM ve DMARC için TXT kayıtları. Bunlardan herhangi birinin eksik olması, teslim edilebilirlik hatalarına veya alıcı posta sunucuları tarafından doğrudan reddedilmeye yol açacaktır.