Paul Mockapetris'in HOSTS.TXT'nin yerini alan ölçeklenebilir DNS sistemini nasıl tasarladığını öğrenin. DNS nasıl çalışır, önbelleklemenin önemi ve temel güvenlik konuları hakkında bilgi edinin.
Herhangi bir web adresi yazdığınızda, bir bağlantıya tıkladığınızda veya e-posta gönderdiğinizde dayandığınız basit bir fikir vardır: insanlar hatırlaması kolay isimleri kullanmalı, bilgisayarlar ise doğru makineyi bulma işini yapmalı.
DNS günlük bir sorunu çözer: bilgisayarlar 203.0.113.42 gibi sayısal adreslerle konuşur, ama insanlar sayı dizilerini ezberlemek istemez. example.com adresini hatırlamak istersiniz, sitenin bugün kullandığı IP adresini değil.
Domain Name System (DNS), insan dostu alan adlarını bilgisayarların bağlantı kurmak için kullandığı IP adreslerine çeviren internetin “adres defteri”dir.
Bu çeviri küçük görünse de, internetin kullanılabilir hissetmesi ile tamamen rakamlardan oluşan bir telefon rehberi gibi hissettirmesi arasındaki farktır.
Bu teknik olmayan bir tur—herhangi bir ağ bilgisi gerekmiyor. Şunları ele alacağız:
Bu arada, 1980'lerin başında DNS'i tasarlayan mühendisi Paul Mockapetris ile tanışacaksınız. Onun işi sadece yeni bir isim formatı yaratmak değildi—küçük bir araştırma ağından milyarlarca insanın kullandığı bir şeye dönüşen internet büyüdükçe çalışmaya devam edecek bir sistem tasarlamaktı.
Eğer bir sitenin “çöktüğünü”, bir alan adının değişikliklerinin "propagasyon"u beklemek zorunda kaldığınızı ya da e-posta ayarlarına neden garip DNS girdileri konulduğunu merak ettiyseniz, DNS'i dışarıdan zaten görmüşsünüz demektir. Bu makalenin geri kalanı, perde arkasında neler olduğunu açık ve jargon olmadan anlatıyor.
Tanıdık bir web adresi yazılmadan çok önce, erken ağların daha basit bir sorunu vardı: belirli bir makineye nasıl ulaşırsınız? Bilgisayarlar IP adresleri (10.0.0.5 gibi numaralar) kullanarak konuşabiliyordu, fakat insanlar MIT-MC veya SRI-NIC gibi kısa host adlarını tercih ediyordu—bunlar hatırlaması ve paylaşması daha kolay etiketlerdi.
Erken ARPANET için çözüm, HOSTS.TXT adında tek bir paylaşılan dosyaydı. Temelde bir arama tablosuydu: host adlarını IP adresleriyle eşleştiren bir liste.
Her bilgisayar bu dosyanın yerel bir kopyasını tuttu. Bir makineye isimle bağlanmak istediğinizde, sisteminiz HOSTS.TXT'yi kontrol eder ve ilgili IP adresini bulurdu.
Ağ küçük olduğu için, değişiklikler göreceli olarak nadirdi ve güncellemelerin nereden alınacağı açıktı; bu yöntem ilk başta işe yarıyordu.
Daha fazla organizasyon katıldıkça yaklaşım doğal büyüme altında zorlanmaya başladı:
Esas sorun koordinasyondu. HOSTS.TXT, tüm dünya için tek bir paylaşılan adres defteri gibiydi. Herkes aynı deftere bağlıysa, her düzeltme küresel bir düzenleme gerektirir ve herkes en yeni sürümü hızla indirmelidir. Ağ belirli bir büyüklüğe ulaştığında, o “her şey için tek dosya” modeli çok yavaş, çok merkezi ve çok hataya açık hale geldi.
DNS, isimleri sayılara eşleştirme fikrini değiştirmedi—onu bakım ve dağıtım yönteminin kırılgan halinin yerine geçti.
1980'lerin başında internet, küçük bir araştırma ağından daha büyük, daha dağınık ve daha yaygın paylaşılan bir şeye doğru kayıyordu. Daha fazla makine bağlanıyor, organizasyonlar özerklik istiyor ve insanlar sayısal adresleri ezberlemek yerine hizmetlere daha kolay ulaşmak istiyordu.
Paul Mockapetris, o ortamda çalışırken DNS'in tasarımcısı olarak geniş kabul gördü. Onun katkısı gösterişli bir ürün değil; hızla büyüyen bir ağda isimleri kullanılabilir kılmak için pratik bir mühendislik cevabıdır.
Bir isimlendirme sistemi basit görünür, ta ki o zamanki "basitleğin" ne anlama geldiğini hayal edene kadar: herkesin indirmesi ve güncel tutması gereken tek bir listeden ibaret olmak. Değişiklik sürekli hale gelir gelmez bu yaklaşım çöker. Her yeni host, yeniden adlandırma veya düzeltme herkes için koordine edilmesi gereken bir işe dönüşür.
Mockapetris'in kilit içgörüsü, isimlerin sadece veri olmadığı; aynı zamanda paylaşılan anlaşmalar olduğuydu. Ağ genişlerse, bu anlaşmaları yaratma ve dağıtma sistemi de büyümeliydi—her bilgisayarın sürekli olarak bir ana listeyi çekmesini gerektirmeden.
DNS, “tek otoriter dosya” fikrinin yerine dağıtılmış bir tasarım koydu:
Bu sakin zekâdır: DNS zekice olmaktan ziyade, gerçek kısıtlar altında—sınırlı bant genişliği, sık değişiklikler, birçok bağımsız yönetici ve durmayan bir ağ—çalışmaya devam edecek şekilde tasarlanmıştır.
DNS bir kısayol olarak icat edilmedi—erken İnternet büyüdükçe ortaya çıkan belirli, çok pratik problemleri çözmek için tasarlandı. Mockapetris'in yaklaşımı önce net hedefler koymak, sonra onlar için yıllarca dayanacak bir isimlendirme sistemi kurmaktı.
Ana kavram delegasyondur: farklı gruplar ad ağacının farklı parçalarını yönetir.
Örneğin, .com altındaki işleri bir kuruluş yönetir, bir registrar example.com adını talep etmenize yardımcı olur ve sonra siz (veya DNS sağlayıcınız) www.example.com, mail.example.com gibi kayıtları kontrol edersiniz. Bu sorumluluğu temiz bir şekilde böler, böylece büyüme darboğaz yaratmaz.
DNS sorunların olacağını varsayar—sunucular çöker, ağlar bölünebilir, yollar değişir. Bu yüzden bir alan için birden fazla authoritative sunucuya ve çözücülerde önbelleğe güvenilir; böylece geçici bir kesinti her sorguyu anında bozmaz.
DNS insan dostu isimleri teknik verilere çevirir, en bilinen şekliyle IP adreslerine. İnternetin kendisi değildir—cihazlarınızın nereye bağlanacağını bulmasına yardımcı olan bir adlandırma ve arama servisidir.
DNS isimleri bir ağaç gibi düzenleyerek yönetilebilir kılar. Her ismin küresel olarak benzersiz olması gerektiği ve birilerinin bunu denetlemesi gerektiği büyük tek liste yerine, DNS isimlendirmeyi seviyelere böler ve sorumluluğu delege eder.
Bir DNS ismi sağdan sola okunur:
www.example.com. teknik olarak bir . ile biter..com, .org, .net, ülke kodları gibi .ukexample kısmı example.com içindewww kısmı www.example.com içindeYani www.example.com şu parçalara ayrılabilir:
com (TLD)example (.com altında kayıtlı alan)www (alan sahibi tarafından oluşturulan ve kontrol edilen etiket)Bu yapı çakışmaları azaltır çünkü isimler sadece ebeveynleri içinde benzersiz olmalıdır. Birçok kuruluş www alt alanına sahip olabilir; www.example.com ile www.another-example.com çakışmaz.
Ayrıca iş yükünü yayar. .com işletmecileri her sitenin kayıtlarını yönetmek zorunda değildir; sadece example.com için kimin sorumlu olduğunu gösterir ve example.com sahibi ayrıntıları yönetir.
Bölge, yönetilebilir bir ağaç parçasıdır—birinin yayımlamaktan sorumlu olduğu DNS verisi. Birçok ekip için “bizim bölge”, example.com için DNS kayıtlarımız ve barındırdığımız alt alanlardır; bunlar authoritative DNS sağlayıcılarında tutulur.
Tarayıcıya bir web sitesi adı yazdığınızda doğrudan “internete” sormuyorsunuz. Cevap kısa zamanda ve güvenilir şekilde bulunması için işi bölen birkaç uzman yardımcı vardır.
Siz (cihazınız ve tarayıcınız) example.com için IP adresinin ne olduğunu sorar. Cihazınız genellikle cevabı bilmez ve düzinelerce sunucuya sormak istemez.
Recursive resolver sizin adınıza arama yapar. Bu genellikle ISP'iniz, işyeri/okul BT'niz veya bir kamu çözücüsü tarafından sağlanır. Ana avantaj: önceki sorgulardan gelen önbelleklenmiş cevapları yeniden kullanabilir, bu da herkes için hız kazandırır.
Authoritative DNS sunucuları bir alanın gerçeğini tutan kaynaklardır. "Arama" yapmazlar; bir alanın hangi IP'lere, posta sunucularına veya doğrulama token'larına sahip olduğunu belirten resmi kayıtları barındırırlar.
example.com sorusunu sorar.Recursive resolver'ı sizin için arama yapan ve popüler cevapları hatırlayan bir kütüphaneci, authoritative server'ı ise yayıncının resmi kataloğu gibi düşünebilirsiniz: diğer kataloglara bakmaz, kendi kitapları için doğru bilgiyi söyler.
example.com yazdığınızda tarayıcı aslında bir ismi aramıyor—bir sayısal IP adresine ihtiyaç var (93.184.216.34 gibi) ki nereye bağlanacağını bilsin. DNS, “bu isim için numarayı bul” sistemidir.
Tarayıcınız önce bilgisayar/telefonunuzun işletim sistemine: “example.com için IP adresini zaten biliyor muyuz?” diye sorar. İşletim sistemi kendi kısa süreli hafızasını (önbellek) kontrol eder. Taze bir cevap varsa iş burada biter.
Eğer işletim sistemi cevabı bilmiyorsa, soruyu genellikle ISP'niz, şirketiniz ya da bir kamu sağlayıcısı tarafından işletilen bir DNS resolver'a iletir. Resolver, sizin “DNS konsiyerjiniz” gibidir: işi üstlenir ki cihazınız yapmasın.
Resolver'in önbelleğinde cevap yoksa kılavuzlu bir arama başlatır:
.com gibi son eki olan alanlar için nereden bilgi alınacağını sorar. Kök sunucu nihai IP'yi vermez—daha çok “bunlara sor” şeklinde yönlendirmeler verir..com): Resolver, .com sunucularına example.comun nerede işlendiğini sorar. Yine nihai IP değil—daha fazla yönlendirme: “example.com için bu authoritative sunucuya sor.”A veya AAAA gibi) içeren IP adresini döner.Resolver IP'yi işletim sisteminize, oradan da tarayıcınıza gönderir; tarayıcı artık bağlanabilir. Çoğu sorgu milisaniyeler içinde gelir çünkü resolver'lar ve cihazlar cevapları alan sahibinin belirlediği süre (TTL) boyunca önbellekler.
Aklınızda tutması kolay akış: Tarayıcı → OS önbelleği → Resolver önbelleği → Kök (yönlendirme) → TLD (yönlendirme) → Authoritative (cevap) → Tarayıcı.
Eğer her site ziyaretinde her seferinde sıfırdan başlamak ve aynı cevabı almak için birden çok sunucuya sormak zorunda kalsaydınız DNS acayip yavaş olurdu. Bunun yerine DNS, çoğu kullanıcının cevapları milisaniyeler içinde almasını sağlayan önbelleklemeye—son sorguların geçici hafızasına—güvenir.
Cihazınız bir DNS resolver'a example.com sorduğunda, resolver ilk seferinde biraz iş yapabilir. Cevabı öğrendikten sonra bunu önbellekte tutar. Aynı ada sırada soran bir sonraki kullanıcı anında yanıt alabilir.
Önbellekleme iki sebeple vardır:
Her DNS kaydı bir TTL (Time To Live) değeriyle gelir. TTL şöyle bir talimat gibidir: bu cevabı X saniye boyunca tut, sonra at ve tekrar sor.
Bir kaydın TTL'si 300 ise resolver'lar cevabı yeniden kontrol etmeden önce yaklaşık 5 dakika boyunca kullanabilir.
TTL bir denge işidir:
Bir siteyi yeni bir sunucuya taşırken, bir CDN değiştirirken veya posta geçişi yaparken (MX kayıtlarını değiştirirken), TTL kullanıcıların eski yere ulaşmayı bırakmasının ne kadar süreceğini belirler.
Ortak yaklaşım: planlanmış bir değişiklikten önce TTL'leri düşürmek, değişikliği yapmak, sonra her şey stabil olunca TTL'leri tekrar yükseltmektir. Bu yüzden DNS gündelik kullanımda hızlı hissettirir—ve güncellemeden hemen sonra bazen “inatçı” gelebilir.
Bir DNS kontrol paneline girdiğinizde çoğunlukla bir avuç kayıt türünü düzenlersiniz. Her kayıt internetin insanlara nereye göndereceğini (web), postanın nereye teslim edileceğini veya sahipliği doğrulamayı söyleyen küçük bir talimattır.
| Kayıt | Ne yapar | Basit örnek |
|---|---|---|
| A | Bir ismi IPv4 adresine yönlendirir | example.com → 203.0.113.10 (web sunucunuz) |
| AAAA | Bir ismi IPv6 adresine yönlendirir | example.com → 2001:db8::10 (aynı fikir, yeni adresleme) |
| CNAME | Bir ismi başka bir ismin takma adı yapar | www.example.com → example.com (ikisi aynı yere gitsin diye) |
| MX | Alanın postasının nereye gitmesi gerektiğini söyler | example.com → mail.provider.com (öncelik 10) |
| TXT | Makinelerin okuyabileceği "notlar" tutar (doğrulama, posta politikası) | example.com üzerinde v=spf1 include:mailgun.org ~all gibi bir SPF kaydı |
| NS | Hangi authoritative sunucuların bir alan/bölgeyi barındırdığını söyler | example.com → ns1.dns-host.com |
| SOA | Bölgenin "başlığı": birincil NS, yönetici iletişimi ve zamanlama değerleri | example.com SOA'sı ns1.dns-host.com ve retry/expire zamanlarını içerir |
Yineleyen birkaç DNS hatası vardır:
example.com). Birçok DNS sağlayıcısı bunu izin vermez çünkü kök isim aynı zamanda NS ve SOA gibi kayıtları da taşımalıdır. "Kökü bir host adına yönlendirmek" gerekliyse, sağlayıcınız destekliyorsa A/AAAA kullanın veya "ALIAS/ANAME" özelliğini kullanın.www). Tek bir yaklaşım seçin.mail.provider.com içinde bir karakter hatası e-postayı bozabilir; eksik/fazla noktalar ve yanlış host alanının kopyalanması (ör. @ yerine www) tipik kesinti sebeplerindendir.Eğer ekibinize DNS rehberliği sunuyorsanız, dokümanlarınıza küçük bir tablo veya runbook sayfası eklemek incelemeleri ve hataları gidermeyi çok daha hızlı yapar.
DNS, sorumluluğun birçok organizasyon arasında bölünmesi sayesinde çalışır. Bu bölünme aynı zamanda sağlayıcı değiştirebilmenizi, ayarları değiştirebilmenizi ve isminizi çevrimiçi tutabilmenizi sağlar—"internete" sormadan.
Alan kaydı (registering a domain) bir ismi (ör. example.com) kullanma hakkını satın almaktır. Bu, bir etiketi rezerve etmek gibidir ki başkası onu alamasın.
DNS barındırma ise o ismin dünyaya nereye işaret ettiğini (web, e-posta, doğrulama kayıtları vb.) söyleyen ayarları çalıştırmaktır. Alanınızı bir şirketten kaydettirip DNS'i başka bir yerde barındırabilirsiniz.
.com, .org veya .uk gibi bir TLD'yi işleten organizasyondur. Her TLD altındaki hangi ismin kimde olduğunu ve hangi name server'ların sorumlu olduğunu tutar.Kök sunucular DNS'in en üstünde oturur. Web sitenizin IP adresini bilmezler ve alanınızın kayıtlarını saklamazlar. İşleri daha dar: resolver'lara hangi TLD'nin nerede işlendiğini söylerler (ör. .comun nerede yönetildiği).
Registrar üzerinde domaininize name server'lar atadığınızda bir delegasyon oluşturmuş olursunuz. .com registry'si (yetkili sunucuları vasıtasıyla) artık example.com için sorguları sizin seçtiğiniz name server'lara yönlendirir.
O andan itibaren, internetin geri kalanı aldıkları cevaplar konusunda bu name server'lara güvenir—ta ki siz delegasyonu tekrar değiştirene kadar.
DNS güven üzerine kuruludur: bir isim yazdığınızda cevabın gerçek servise işaret ettiğini varsayırsınız. Çoğu zaman bu doğru olur—ancak DNS, büyük miktarda insanı yeniden yönlendirebileceği için saldırganların tercih ettiği bir hedeftir.
Klasik bir sorun spoofing ya da cache poisoning'dir. Bir saldırgan bir DNS resolver'ı sahte bir cevabı önbelleğe almaya ikna edebilirse, kullanıcılar doğru alan adını yazsalar bile yanlış IP'ye yönlendirilebilir. Sonuç phishing sayfaları, zararlı yazılım indirmeleri veya trafiğin ele geçirilmesi olabilir.
Bir diğer sorun registrar düzeyinde alan adı ele geçirilmesidir. Birisi registrar hesabınıza girerse name server'ları veya DNS kayıtlarını değiştirerek alan adınızı ele geçirebilir.
Günlük tehlike ise yanlış yapılandırmalardır. Uzak bir CNAME, eski bir TXT kaydı veya yanlış MX kaydı girişleri oturum açma akışlarını, e-posta teslimatını veya doğrulama kontrollerini bozabilir. Bu arızalar genellikle “internet çöktü” gibi görünür, ama gerçek neden küçük bir DNS düzenlemesidir.
DNSSEC DNS verilerine kriptografik imzalar ekler. Basitçe: DNS cevabının iletim sırasında değiştirilmediğini ve gerçekten alanın authoritative kaynağından geldiğini doğrulayabilirsiniz. DNSSEC DNS'i şifrelemez veya sorgularınızı gizlemez, ama birçok sahte cevabın kabul edilmesini engelleyebilir.
Geleneksel DNS sorguları ağlar tarafından kolayca gözlemlenebilir. DNS-over-HTTPS (DoH) ve DNS-over-TLS (DoT), cihazınız ile resolver arasındaki bağlantıyı şifreleyerek dinlemeyi ve bazı yol üzeri müdahaleleri azaltır. Bunlar DNS'i “anonim” yapmaz, ama kimlerin sorguları görebileceğini ve değiştirebileceğini değiştirir.
Registrar hesabınızda MFA kullanın, domain/transfer kilitlerini etkinleştirin ve kimlerin DNS düzenleyebileceğini sınırlandırın. DNS değişikliklerini üretime dokunacak değişiklikler gibi ele alın: inceleme isteyin, değişiklik günlüğü tutun ve kayıt ya da name server değişiklikleri için izleme/alert mekanizmaları kurun ki sürprizleri hızlıca öğrenin.
DNS "kur ve unut" gibi hissedilebilir, ta ki küçük bir değişiklik sitenizi veya e-postanızı bozana kadar. İyi haber: birkaç alışkanlık DNS yönetimini öngörülebilir kılar—küçük ekipler için bile.
Tekrarlanabilir hafif bir süreçle başlayın:
Çoğu DNS sorunu karmaşık değildir—sadece fark etmek zordur.
Örneğin sık sık uygulama dağıtımı yapan takımlar için DNS, yayın sürecinin parçası haline gelir. Koder.ai gibi platformlardan web uygulamaları gönderen ekipler bile aynı temellere güvenir: doğru A/AAAA/CNAME hedefleri, kesintiler sırasında mantıklı TTL'ler ve yanlış yönlenme durumunda net bir geri dönüş yolu.
Eğer alan adınızdan e-posta gönderiyorsanız, DNS doğrudan iletilip iletilmeyeceğini etkiler.
İnsan dostu isimler internetin küçük bir araştırma topluluğunun ötesine ölçeklenmesini sağladı. DNS'i paylaşılan bir altyapı olarak görün—başta biraz özen göstermek, sitenizin erişilebilirliğini ve e-postanızın güvenilirliğini büyüdükçe korur.
DNS (Domain Name System), example.com gibi insan dostu isimleri 93.184.216.34 gibi IP adreslerine çevirir, böylece cihazınız nereye bağlanacağını bilir.
DNS olmasaydı her site ve servis için sayısal adresleri ezberlemek zorunda kalırdınız.
Erken ağlar, isimleri IP adreslerine eşleyen tek bir paylaşılan dosya (HOSTS.TXT) kullanıyordu.
Ağ büyüdükçe bu yöntem sürdürülemez hale geldi: sürekli güncellemeler, çakışan isimler ve güncel olmayan kopyalardan kaynaklanan kesintiler ortaya çıktı. DNS, “tek bir küresel dosya” yaklaşımını dağıtılmış bir sisteme dönüştürdü.
Paul Mockapetris, 1980'lerin başında DNS'i tasarlayarak hızla büyüyen ağlarda isimlendirme sorununu çözdü.
Onun ana fikri delegasyondu: sorumlulukları birçok kuruluşa bölerek tek bir ana liste ya da yöneticiye bağımlılığı ortadan kaldırmak.
DNS isimleri hiyerarşik olarak sağdan sola okunur:
www.example.com..comexample.comwww.example.comBu hiyerarşi, delege etme ve yönetimi küresel ölçekte pratik hale getirir.
Bir recursive resolver sizin yerinize arama yapar ve cevapları önbelleğe alır (genellikle bir ISP, işyeri veya kamu sağlayıcı tarafından çalıştırılır).
Bir authoritative DNS server ise bir alanın kayıtları için gerçek kaynaktır; internette "arama" yapmaz, kendi bölgesi için doğru cevapları verir.
Tipik bir sorgu şöyle işler:
.com) → alanın authoritative sunucuları.A/AAAA).TTL (Time To Live), bir DNS kaydının ne kadar süreyle önbellekte tutulabileceğini söyler.
“Propagasyon” büyük ölçüde farklı önbelleklerin farklı zamanda süresi dolduğu için gerçekleşir.
Çoğunlukla yöneteceğiniz kayıt türleri şunlardır:
Bir registrar, alan adını kaydettiğiniz ve yenilediğiniz yerdir (örneğin example.com hakkını alırsınız).
Bir DNS sağlayıcısı/host ise authoritative name server'ları çalıştırır ve DNS kayıtlarınızı barındırır. Registrar ile DNS hostunu farklı şirketlerden seçebilirsiniz; bu durumda registrar üzerinde NS (name server) ayarlarını değiştirirsiniz.
DNS şu risklere açıktır:
MX, çakışan kayıtlar veya yazım hataları e-posta teslimatı ve doğrulama akışlarını bozabilir.Önlemler:
A / AAAA: bir ismi IPv4/IPv6 adresine yönlendirir (web uygulamaları, sunucular).CNAME: bir ana makine adını başka bir ada takma ad yapar (çoğunlukla www için).MX: alan için mailin nereye teslim edileceğini belirtir.TXT: doğrulama ve e-posta yetkilendirmesi (SPF, DKIM, DMARC).NS: alanın hangi name server'lar tarafından yetkilendirildiğini söyler.Pratik kural: aynı ana ad üzerinde hem CNAME hem A kaydı koymayın.