DNS Çözümlemesi, Baştan Sonuna

Her seferinde bir domain'i tarayıcıya yazdığınızda, istediğiniz siteye tek bir paket ulaşmadan önce bir dizi arama tetiklenir. Bu zincirin çoğu görünmez ve buna ilişkin çoğu açıklama "sanki bir telefon rehberi gibi" diyerek biter. İşte gerçekte neler olduğu, adım adım; insanların genellikle atladığı kısımlar da dahil olmak üzere.

Stub resolver akıllı değildir

İşletim sisteminiz kendi başına gerçek DNS çözümlemesi yapmaz. Sorgunuzu Linux'ta /etc/resolv.conf dosyasında yapılandırılan DNS sunucusuna veya Windows'ta ağ adaptörü ayarlarında yapılandırılan sunucuya yönlendiren ince bir kod parçası olan bir stub resolver çalıştırır. Sizinkini şu komutla kontrol edin:

cat /etc/resolv.conf

Bu dosya genellikle yönlendiriciye (192.168.1.1 gibi), ISS'nizin resolver'ına veya 1.1.1.1 veya 8.8.8.8 gibi herkese açık bir resolver'a işaret eder. Stub resolver'ın, OS'un veya systemd-resolved gibi yerel bir daemon'un sağladığı kısım dışında kendi önbellek mantığı yoktur.

Recursive resolver gerçek işi yapar

Sorgunuz bir recursive resolver'a ulaştığında, o sunucu cevap bulma işini devralmış olur; bunu yapmak için birden fazla başka sunucuya sormak zorunda kalsa bile. Cevap daha önceki bir araştırmadan zaten önbellekte varsa, hemen geri alırsınız. TTL'yi şu komutla kontrol edin:

dig example.com

ANSWER SECTION bölümüne bakın — kayıt türünden önce gelen sayı (örneğin A öncesindeki 300) TTL'dir ve saniye cinsinden ölçülür. Bu, resolver'ların yeniden sormadan önce kaydı ne kadar süre önbelleğe alabileceğidir.

Eğer hiçbir şey önbellekte yoksa, recursive resolver DNS hiyerarşisinin kökünden aşağıya doğru bir yolculuğa başlar.

Kök, TLD ve authoritative sunucuları

13 kök sunucu adresi vardır (a.root-servers.net ile m.root-servers.net arasında); her biri anycast yönlendirme aracılığıyla birçok fiziksel makine tarafından desteklenir. Kök sunucu example.com'un nerede olduğunu bilmez, ancak .com'u hangi sunucuların işlediğini bilir; bu nedenle bir gönderme döndürür.

Resolver daha sonra bir .com TLD sunucusundan sorar; bu da yine nihai cevabı bilmez ancak hangi nameserver'ların example.com için authoritative olduğunu bilir. Bu delegasyonu kendiniz görebilirsiniz:

dig +trace example.com

Bu komut her atlamayı gösterir: kök, sonra TLD, sonra domain için authoritative nameserver'lar; ve gerçek A veya AAAA kaydıyla biter. DNS'i teorik yerine görsel olarak anlamak için en iyi tek komuttur.

Authoritative nameserver son duraktır. Domain sahibinin aslında yapılandırdığı sunucu; çoğu zaman bir kayıt kuruluşunun DNS paneli veya Route 53 veya Cloudflare DNS gibi bir hizmet aracılığıyla. Bu, bütün zincirdeki tek sunucu; önbellekte olan bir kopya veya gönderme yerine, gerçek, kanonik cevaba sahip olan.

Gerçekten karşılaşacağınız kayıt türleri

Bir A kaydı bir adı IPv4 adresiyle eşleştirir; AAAA aynı şeyi IPv6 için yapar. CNAME bir adı IP yerine başka bir adla işaret eder; bu, Cloudflare veya Fastly gibi CDN'lerin ham IP'leri açığa çıkarmadan trafiği yönlendirme şeklidir. MX kayıtları posta yönlendirmesini işler; TXT kayıtları keyfi metin taşır; günümüzde en sık SPF, DKIM ve domain doğrulama dizesi için kullanılır. NS kayıtları dünyaya hangi sunucuların bir bölge için authoritative olduğunu söyler; ve işte bu kayıt türü ilk başta delegasyonu mümkün kılan şeydir.

Önbelleğe alma gerçekte nerde yaşar

Önbelleğe alma aynı anda birden fazla katmanda gerçekleşir: tarayıcının kendisi (Chrome'un chrome://net-internals/#dns adresinde görüntülenebilir kendi DNS önbelleği vardır), OS resolver önbelleği, yerel yönlendirici ve upstream recursive resolver. DNS değişikliğinin bir cihazda anında çalışması ve başka bir cihazda gösterilmesi saatlerce sürmesinin sebebi budur — aynı önbelleği kullanmıyorsunuz.

Planlı bir göç öncesi bir kaydın TTL'sini düşürdüğünüzde, hemen hiçbir şeyi hızlandırmıyorsunuz. Sadece değişiklik gerçekten olduğunda eski verilerin devam edebileceği pencereyi daraltıyorsunuz. Bunu kesişmeden beş dakika önce değil; en az bir TTL döngüsü öncesinde yapın.

Bu neden sorun giderme açısından önemlidir

Bir site ulaşılamaz olduğunda, dig +trace size hangi katmanın kırık olduğunu tam olarak söyler: kök/TLD sorunu, yanlış yapılandırılmış authoritative sunucu veya kendi makinenizdeki eski önbelekten tamamen farklı görünür. dig example.com ile dig example.com @1.1.1.1 gibi bilinen iyi bir resolver ile karşılaştırmak, sorunun yerel resolver'ınız mı yoksa domain'in gerçek DNS kurulumu mu olduğunu izole eder.

DNS dışarıdan basit görünür; çünkü genellikle 100ms'de çözülür ve kimse bunu düşünmez. Altında, 1980'lerden bu yana yapı olarak büyük ölçüde değişmeden çalışan dağıtılmış, önbellekli, hiyerarşik bir sorgu sistemidir; orijinal tasarımın ne kadar iyi tutunduğuna dair oldukça iyi bir argümandır.

Bu konuda daha ileri gitmek istiyorsanız, Korra Studio'nun DEFENSE_GRID üzerinde ilgili bölümleri DNS güvenlik uzantıları, veri sızması tekniği olarak DNS tünelleme ve Python'da kendi resolver'ınızı sıfırdan oluşturma konusunu kapsamaktadır.