Alan Adı Sistemi (DNS) Nasıl Çalışır?

Bir web sitesini her açtığınızda, e-posta gönderdiğinizde ya da bir API’yi çağırdığınızda cihazınız önce basit bir soruyu yanıtlamak zorundadır: Bu ada hangi IP adresi karşılık geliyor? Alan Adı Sistemi (DNS), bu soruyu yanıtlayan küresel ve dağıtık rehberdir. Günlük olarak kullanılan en eski internet altyapılarından biridir ve genellikle görünmeden çalıştığı için pek çok site sahibi onun nasıl işlediğini ancak bir şeyler bozulduğunda öğrenir. Bu rehberde bir DNS sorgusunun baştan sona yolculuğunu sade bir dille anlatıyor, önbelleğin neden bu kadar önemli olduğunu açıklıyor ve tüm süreci kendi gözünüzle görebileceğiniz komutları gösteriyoruz.

DNS aslında ne yapar?

Bilgisayarlar trafiği 93.184.215.14 (IPv4) veya 2606:2800:21f:cb07:6820:80da:af6b:8b2c (IPv6) gibi sayısal adreslerle yönlendirir. İnsanlar ise isimleri tercih eder. DNS bu ikisi arasında eşleme yapar; ancak basit bir arama tablosundan çok daha fazlasıdır. Hiyerarşik ve yetki devrine dayalı bir veritabanıdır: Hiçbir sunucu tüm yanıtları tek başına bilmez. Sorumluluk bölgelere (zone) ayrılır ve her bölgeyi onu kontrol eden taraf yönetir.

Bu tasarımın üç pratik sonucu vardır:

• Ölçeklenebilirlik: Kök sunucuların milyarlarca ana makine adını bilmesi gerekmez; yalnızca her üst düzey alan adının nerede bulunacağını bilirler.
• Özerklik: Bir alan adı size devredildiğinde, içinde hangi kayıtların olacağına kimseye sormadan siz karar verirsiniz.
• Dayanıklılık: Her seviye birden fazla sunucu tarafından, çoğu zaman anycast yönlendirmesiyle farklı kıtalara yayılmış biçimde hizmet verir.

Bir bölgenin içindeki A, AAAA, CNAME ve MX gibi kayıtları DNS kayıtlarını anlama rehberimizde ayrıntılı olarak ele aldık. Burada ise bir çözümleyicinin bu kayıtları en başta nasıl bulduğuna odaklanıyoruz.

DNS hiyerarşisi: kök, TLD ve yetkili sunucular

Bir alan adını sağdan sola okuduğunuzda DNS ağacını yukarıdan aşağıya okumuş olursunuz. www.example.com. adı aslında kökü temsil eden görünmez bir noktayla biter.

Seviyeler arasındaki bağlantıya yetki devri (delegation) denir. Bir alan adını kaydedip kayıt firmanızda ad sunucularını belirlediğinizde, kayıt firması bu NS kayıtlarını registry’ye iletir ve registry bunları TLD bölgesinde yayımlar. Ad sunucuları alan adının kendi içindeyse (örneğin ns1.example.com), tavuk-yumurta sorununu önlemek için registry bu sunucuların IP adreslerini de glue kaydı olarak yayımlar.

Adım adım: Adres çubuğuna bir URL yazdığınızda neler olur?

Yeni bir ağda www.example.com adresini ilk kez ziyaret ettiğinizi düşünelim. Sorgu kabaca şu şekilde ilerler:

1. Yerel kontroller. Tarayıcı önce kendi önbelleğine bakar, ardından işletim sistemine sorar. İşletim sistemi de kendi önbelleğini ve hosts dosyasını kontrol eder.
2. Stub çözümleyiciden özyinelemeli çözümleyiciye. Önbellekte bir şey yoksa işletim sistemindeki stub çözümleyici, tanımlı özyinelemeli çözümleyiciye sorgu gönderir. Bu genellikle internet servis sağlayıcınızın sunucusu, modeminiz ya da 1.1.1.1, 8.8.8.8 veya 9.9.9.9 gibi herkese açık bir hizmettir.
3. Çözümleyici kök sunucuya sorar. Çözümleyicide kök sunucu adreslerinin bir listesi (root hints) hazır bulunur. Bunlardan birine www.example.com adını sorar. Kök yanıtı bilmez ama bir yönlendirme döndürür: “.com için ad sunucuları bunlar.”
4. Çözümleyici TLD sunucularına sorar. Bir .com sunucusu yeni bir yönlendirmeyle yanıt verir: example.com için yetkili ad sunucuları ve gerekiyorsa glue kayıtları.
5. Çözümleyici yetkili sunucuya sorar. Bölgeyi barındıran bu sunucu gerçek yanıtı, örneğin IPv4 adresi içeren bir A kaydını döndürür ve AA (yetkili yanıt) bayrağını işaretler.
6. Yanıt iletilir ve önbelleğe alınır. Çözümleyici yanıtı cihazınıza iletir; hem bu yanıtı hem de topladığı yönlendirmeleri, her kaydın TTL süresi boyunca saklar.

Çözümleyici, cihazınızın özyinelemeli sorgusunu yanıtlarken hiyerarşiye doğru yinelemeli sorgular yapar. Dizüstü bilgisayarınız bir kez sorar ve bekler; yolu yürüyen çözümleyicidir. Uygulamada 3. ve 4. adımlara nadiren gerek kalır, çünkü çözümleyicide kök ve .com yönlendirmeleri zaten önbellekte bulunur.

dig +trace ile süreci izlemek

BIND araçlarının bir parçası olan ve Linux ile macOS’ta bulunan dig, bu yürüyüşü kendisi yapıp her yönlendirmeyi ekrana yazdırabilir. Aşağıdaki çıktı kısaltılmıştır:

$ dig +trace www.example.com A

.                 518400  IN  NS  a.root-servers.net.
.                 518400  IN  NS  b.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53

com.              172800  IN  NS  a.gtld-servers.net.
com.              172800  IN  NS  b.gtld-servers.net.
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net)

example.com.      172800  IN  NS  a.iana-servers.net.
example.com.      172800  IN  NS  b.iana-servers.net.
;; Received 361 bytes from 192.5.6.30#53(a.gtld-servers.net)

www.example.com.  300     IN  A   93.184.215.14
;; Received 60 bytes from 199.43.135.53#53(a.iana-servers.net)

Her blok bir adımı gösterir: kök, TLD ve yetkili sunucu. Addan sonraki sayı, saniye cinsinden TTL değeridir.

Önbellek ve TTL: DNS neden bu kadar hızlı?

Her sorgu ağacın tamamını dolaşsaydı kök ve TLD sunucuları altında ezilir, internette gezinmek de ağırlaşırdı. Bunu önbellek engeller. Her kayıt, bölge sahibinin belirlediği bir TTL (Time To Live, yaşam süresi) değeri taşır ve çözümleyicilere yanıtı yeniden sormadan önce kaç saniye kullanabileceklerini söyler.

• Uzun TTL’ler (saatler ya da bir gün) sorgu yükünü azaltır ve yetkili sunuculardaki kısa kesintilere karşı sitenizi daha dayanıklı kılar; ancak değişikliklerin herkese ulaşması uzun sürer.
• Kısa TTL’ler (60 ile 300 saniye) sunucu değişikliklerini hızla yapmanızı sağlar, karşılığında daha fazla sorgu oluşur.
• Negatif önbellek: “Bu ad yok” (NXDOMAIN) yanıtı da, bölgenin SOA kaydından türetilen bir süre boyunca önbellekte tutulur. Biri bir adı sorguladıktan hemen sonra kaydı oluşturursanız, bir süre çalışmıyormuş gibi görünebilir.

Bir taşıma öncesinde edinilecek iyi bir alışkanlık: Değiştireceğiniz kayıtların TTL değerini bir iki gün önceden düşürün, geçişi yapın ve trafik yeni sunucuya geçtikten sonra TTL’yi yeniden yükseltin.

“DNS yayılması” gerçekte ne demek?

Bir kaydı düzenlediğinizde internet üzerinde hiçbir şey aktif olarak dağıtılmaz. “Yayılma” dediğimiz şey, binlerce çözümleyicideki önbellek kopyalarının süresinin dolması için geçen zamandır. Burada iki farklı sayaç devreye girer:

• Bölgenizin içindeki kayıtlarda yapılan değişiklikler, o kayıtların TTL değerlerine bağlıdır.
• Ad sunucusu değişiklikleri ise TLD bölgesinde yayımlanan yetki devrini ilgilendirir. Bu NS kayıtlarının TTL değerini registry belirler ve bazı TLD’lerde 48 saat ya da daha uzundur. Eski yetkilendirmeyi önbelleğe almış çözümleyiciler, süresi dolana kadar onu kullanmaya devam eder.

Ad sunucusu geçişi sırasında eski DNS sağlayıcısının aynı kayıtları yayınlamaya devam etmesini sağlarsanız, geçiş ziyaretçileriniz için tamamen fark edilmez olur.

Sık karşılaşılan DNS sorunları ve teşhisi

Hatalı yetkilendirme (lame delegation), TLD’nin gerçekte bölgenize hizmet vermeyen ad sunucularını göstermesidir. Çoğu zaman NS kayıtları güncellenmeden bir hosting paketinin iptal edilmesiyle ortaya çıkar. Bir alan adının hangi ad sunucularına devredildiğini, kayıt firmasını ve bitiş tarihini TLDix WHOIS sorgulama aracıyla hızlıca görebilirsiniz.

Özyinelemeli çözümleyiciler, gizlilik ve güvenlik

Klasik DNS, UDP 53 numaralı port üzerinden düz metin olarak iletilir; bu yüzden ağ yolu üzerindeki herkes sorguları görebilir ve hatta değiştirebilir. Bu sorunlara yönelik birkaç iyileştirme vardır:

• DNS over TLS (DoT) ve DNS over HTTPS (DoH), cihazınız ile özyinelemeli çözümleyici arasındaki bağlantıyı şifreleyerek ilk adımda gizliliği korur.
• QNAME minimizasyonu, çözümleyicinin her sunucuya yalnızca ihtiyaç duyduğu kısmı göndermesini sağlar; böylece kök sunucu, aradığınız tam ana makine adını öğrenmez.
• DNSSEC, yanıtlara kriptografik imzalar ekleyerek çözümleyicilerin yanıtın gerçekten bölge sahibinden geldiğini ve değiştirilmediğini doğrulamasına olanak tanır. Şifreleme sorguları gizler, DNSSEC ise yanıtın gerçekliğini kanıtlar. Farklı sorunları çözerler ve birlikte iyi çalışırlar.

Alan adınızın DNS sağlığını korumak

DNS kesintilerinin çoğu sıra dışı saldırılardan değil, sıradan gözden kaçmalardan kaynaklanır: süresi dolmuş bir alan adı, unutulmuş bir DNS barındırma hesabı ya da kimsenin not almadığı bir ad sunucusu değişikliği. Basit bir rutin işinizi kolaylaştırır:

1. En az iki yetkili ad sunucusu kullanın; mümkünse farklı ağlarda olsunlar.
2. Bölgenizi hangi sağlayıcının barındırdığını ve kimlerin erişimi olduğunu kayıt altına alın.
3. Alan adı kaydını ve DNS barındırma hesabını yenileyin; mümkünse otomatik yenilemeyi açın.
4. Her sağlayıcı değişikliğinden sonra yetkilendirmeyi dig NS ve dig +trace ile kontrol edin.
5. Bitiş tarihlerini tek bir yerden takip edin. TLDix alan adı panelinde alan adlarınızı, SSL sertifikalarınızı ve hosting yenilemelerinizi bir arada izleyebilir, süresi dolmadan önce hatırlatma alabilirsiniz.

Kökten yetkili sunucuya uzanan zinciri anladığınızda DNS gizemlerinin çoğu basitleşir: Beklenmeyen yanıtı hangi halkanın verdiğini bulun, TTL değerine bakın ve veriyi kaynağında düzeltin.