DNS Nedir, Nasıl Çalışır? Kayıt Türleri ve TTL

DNS (Domain Name System), insanların kullandığı alan adlarını makinelerin kullandığı IP adreslerine çeviren sistemdir. Tarayıcıya sercebilisim.com yazarsınız, bilgisayarınız aslında 203.0.113.42 gibi bir sayıya bağlanır ve aradaki çeviriyi DNS yapar. Çalışmadığında internet kesilmiş gibi görünür: site açılmaz, mail gitmez, kurum içi uygulama başlamaz. Oysa hat yerindedir, adresiniz vardır, sadece kimin nerede olduğunu soracağınız yer cevap vermiyordur.

Bilinmeyen numaralar servisini hatırlayın. Aradığınız kişinin adını biliyordunuz, numarasını bilmiyordunuz; 118’i arar, ismi söyler, karşılığında numarayı alırdınız. Sonra o numarayı telefonunuza kaydederdiniz ve bir daha sormazdınız. Kişi numarasını değiştirdiğinde ise sizin defterinizdeki kayıt bir süre daha eskisini göstermeye devam ederdi; siz yanlış yeri arıyor, bunu da bilmiyordunuz. Sistemin tamamı bu üç şeyin üstüne kuruluydu: ismi bilip numarayı bilmemek, cevabı bir yerde saklamak ve sakladığınız cevabın bir gün bayatlaması.

DNS tam olarak bu servistir ve bu makale boyunca aynı rehbere geri döneceğiz. Aşağıda önce DNS’in ne işe yaradığını, sonra bir sorgunun kök sunucudan yetkili sunucuya kadar hangi duraklardan geçtiğini göreceğiz. Ardından çoğu kişinin en çok karıştırdığı yere geleceğiz: alan adını satan taraf ile kayıtları tutan taraf aynı değildir. Sonra kayıt türlerini (A, CNAME, MX, TXT, SRV), bir değişikliğin neden hemen yansımadığını, kurumsal ağda sorguyu kimin cevapladığını ve arıza anında hangi komutla nereye bakılacağını ele alacağız. Elinizde şu an çözülmeyen bir isim varsa doğrudan teşhis sırasına atlayabilirsiniz.

Bu makale kurumsal network kurulumu hizmetimizin isim çözümleme katmanına odaklanır. DNS, bir kurumu ayakta tutan protokol zincirinin rehber halkasıdır; zincirin tamamını ve bir arızada hangi halkanın koptuğunun belirtiden nasıl anlaşıldığını kurumsal ağ protokolleri rehberimizde ele alıyoruz.

DNS Nedir, Ne İşe Yarar?

DNS, bir ismi adrese çeviren dağıtık bir veritabanıdır ve 53 numaralı portu kullanır. Yaptığı iş tek cümleyle özetlenir: siz sercebilisim.com dersiniz, o size o ismin bugün hangi sayıda durduğunu söyler. Bu kadar basit bir iş, internetin tamamının üzerine kurulduğu iştir.

İsimden Adrese: DNS Tam Olarak Neyi Çözüyor

DNS’in çözdüğü problem ezber değil, değişkenliktir. Herkes birkaç IP adresini ezberleyebilir; asıl sorun o adreslerin değişmesidir. Sunucunuzu başka bir sağlayıcıya taşırsınız, mail servisinizi değiştirirsiniz, barındırma platformunuz kendi altyapısını yeniler. Bunların hepsinde IP değişir. İsim değişmez.

Rehber de bu yüzden vardı. İnsanlar numaraları ezberleyemedikleri için değil, numaralar taşındıkça değiştiği için. İsim sabit kalır, numara altta hareket eder, ikisini birbirine bağlayan bir kayıt tutulur.

Buradan çıkan pratik sonuç şudur: DNS bir yönlendirme değil, bir cevaptır. Kimseyi bir yere göndermez, sadece sorulan ismin karşılığını söyler. Bağlantıyı kuran taraf sizin cihazınızdır. Bu ayrım teşhis sırasında çok işe yarar; ilerleyen bölümlerde “isim doğru çözülüyor ama bağlantı kurulmuyor” durumunu ayırt ederken buraya geri döneceğiz.

DNS Durduğunda Ne Durur?

DNS çalışmadığında ağ ayakta kalır ama neredeyse hiçbir şey çalışmaz, çünkü kurumda ismiyle çağrılmayan bir şey kalmamıştır. Web siteleri açılmaz, mail teslim edilemez, dosya sunucusuna ulaşılamaz, lisans sunucusuna bağlanılamaz, yedekleme işi hedefini bulamaz.

Kurumsal tarafta bir katman daha var ve genellikle unutulan da o. Domain ortamında istemci, hangi Domain Controller’a başvuracağını DNS’teki SRV kayıtlarından öğrenir. Yani DNS yalnızca “isimden adres bulan” bir servis değil, kimlik altyapısının kendi rehberidir. Sahada gördüğüm Active Directory arızalarının önemli bir kısmı aslında DNS arızasıdır ve hata mesajının hiçbir yerinde DNS geçmez.

Belirtinin adını söylememesi bu makalenin tekrar eden temasıdır. Kullanıcı size “internet gitti” der, “domaine giremiyorum” der, “mailim spam’e düşüyor” der. Üçünün de altında aynı katman durabilir.

Bir DNS Sorgusu Nereye Gider? Kök, TLD ve Yetkili Sunucu

Bir DNS sorgusu tek bir sunucuya gitmez. Önce sizin adınıza cevabı arayacak bir çözümleyiciye uğrar; o da kökten başlayıp aşağı inen bir zincirde sırayla üç durak dolaşır. Zinciri bilmek, arızanın hangi halkada olduğunu anlamanın da tek yoludur.

Zincir Dört Durakta İşler

Cihazınız sercebilisim.com adresini sorduğunda süreç şöyle işler. Önce sorgu özyinelemeli çözümleyiciye (recursive resolver) gider: kurumdaki iç DNS sunucunuz, servis sağlayıcınızın sunucusu ya da 1.1.1.1 gibi bir genel çözümleyici. Cevabı bulmak artık onun işidir.

Çözümleyici cevabı önbelleğinde bulamazsa kök sunuculara sorar. Kök, cevabı bilmez; yalnızca .com uzantısına kimin baktığını söyler. Sonra TLD sunucusuna sorulur, o da adresi bilmez; yalnızca sercebilisim.com alan adının kayıtlarını hangi sunucuların tuttuğunu söyler. Son durakta o sunucuya, yani yetkili sunucuya (authoritative) sorulur ve gerçek cevap oradan gelir.

Rehberi ararken de tam olarak bu olurdu. Operatör aradığınız numarayı ezbere bilmezdi; hangi ilin, hangi kurumun kaydına bakılacağını bilirdi ve sizi kaydın gerçekten tutulduğu yere kadar götürürdü. Siz tek bir yeri aradınız, arkada üç kademe çalıştı.

Zincirin en önemli özelliği şudur: tek doğru kaynak yetkili sunucudur. Kök ve TLD hiçbir zaman adres vermez, yalnızca yol tarif eder. Bir kayıt değişikliğinin doğru yapılıp yapılmadığını anlamak istiyorsanız yetkili sunucuya doğrudan sormanız gerekir; aradaki her kademe size saklanmış eski bir cevap dönebilir.

Özyinelemeli ve Yinelemeli Sorgu Farkı

İki sorgu tipi vardır ve farkı işi kimin üstlendiğidir. Cihazınızın çözümleyiciye yaptığı sorgu özyinelemelidir (recursive): “bana nihai cevabı getir, ara adımlarla ilgilenmiyorum”. Çözümleyicinin kök, TLD ve yetkili sunucuya yaptığı sorgular ise yinelemelidir (iterative): her biri “bilmiyorsan bir sonrakine kimin bakacağını söyle” demektir.

Bu, rehberi arayan kişiyle operatör arasındaki ilişkinin aynısıdır. Siz tek bir talep verdiniz ve beklediniz; koşuşturan taraf operatör oldu.

Ayrımın pratik karşılığı bir güvenlik konusudur ve sonraki bölümlerden birinde karşınıza çıkacak. Özyinelemeli hizmet vermek pahalı bir iştir ve herkese açık bırakılmaz. İnternete açık, herkesin sorgusunu kabul eden bir çözümleyici (açık resolver) kurumun kendi bant genişliğini başkalarının saldırılarında kullandırır. Kurum içindeki DNS sunucusu yalnızca kendi ağına özyinelemeli cevap vermelidir.

Alan Adı Kimin, Kayıtlar Nerede? Registrar, Nameserver ve Zone

Alan adını satan taraf ile alan adının kayıtlarını tutan taraf farklı olabilir ve pratikte çoğu zaman farklıdır. Bu makalede öğreneceğiniz tek şey bu olsa, yine değerdi: sahadaki DNS kafa karışıklığının çoğu buradan çıkıyor.

Registrar Alan Adını Satar, DNS’i Yönetmek Zorunda Değildir

Kayıt kuruluşu (registrar), alan adını sizin adınıza tahsis eden ve bu tahsisi ilgili kayıt otoritesinde tutan taraftır. .com tarafında bu otorite küresel bir registry’dir; .tr uzantılarında ise işi TRABİS yürütür ve satış akredite kayıt kuruluşları üzerinden yapılır. Kayıt kuruluşunun asli işi budur: ismin size ait olduğunu kayıt altına almak.

DNS kayıtlarını yönetmek ise ayrı bir hizmettir. Kayıt kuruluşları bunu genelde ücretsiz bir ek olarak sunar, ama zorunlu değildir ve çoğu kurum bunu başka bir yere devreder: barındırma platformuna, CDN sağlayıcısına ya da kendi sunucusuna.

Numara ile operatör ilişkisi gibi düşünün. Numarayı size tahsis eden operatör bellidir. Ama numaranızın hangi rehberde, hangi bilgilerle görüneceği ayrı bir karardır ve o kaydı bambaşka bir yer tutuyor olabilir.

Kayıt kuruluşu tarafında ihmal edildiğinde en pahalıya patlayan konu ise teknik değil takvimsel: alan adı bir mülk değil, süreli bir tahsistir. Süre dolduğunda site ve mail aynı anda durur, çünkü alan adı çözülemez hale gelir. Çoğu uzantıda arkasından yaklaşık bir aylık bir tolerans dönemi gelir, ardından geri alım (redemption) dönemi başlar ve bu aşamada alan adını kurtarmak normal yenileme ücretinin katbekat üstünde bir bedel ister. En sonunda alan adı serbest bırakılır ve başkası alabilir. .tr tarafında süreler ve işleyiş farklıdır, ama sonuç aynıdır.

Bunun kurumsal karşılığı iki satırlık bir önlemdir ve ikisi de teknik değildir. Otomatik yenilemeyi açık tutun, ama ona güvenmeyin: yenilemeyi durduran şey genellikle süresi dolmuş bir kredi kartıdır. İkincisi, kayıt kuruluşundaki iletişim adresini kurumsal ve kalıcı bir adres yapın. Ayrılan bir çalışanın kişisel adresine giden yenileme uyarıları, kurumun alan adını kimsenin okumadığı bir posta kutusuna bağlar.

Nameserver Devri: Kayıtlarınız Hangi Rehberde Duruyor?

Bir alan adının kayıtlarını hangi sunucuların tuttuğunu nameserver bilgisi belirler ve bu bilgi kayıt kuruluşunun panelinde durur. Nameserver’ları değiştirdiğiniz anda, o alan adının bütün kayıtlarını yöneten yer de değişir. Buna delegasyon denir: bölge üzerindeki yetkiyi bir sunucu kümesine devretmiş olursunuz.

Sahadaki en yaygın kafa karışıklığı da tam burada. Alan adını bir kayıt kuruluşundan aldınız, sonra barındırma platformunuzun verdiği nameserver’ları yazdınız. Artık kayıt kuruluşunun DNS Yönetimi panelinde gördüğünüz kayıt listesi, gerçekte kullanılan liste değildir. Oradan bir A kaydını değiştirirsiniz, kaydedersiniz, hiçbir şey olmaz. Panel çalışıyordur, kayıt yazılmıştır; sadece dünyada kimse o sunucuya sormuyordur.

Rehber karşılığı birebir aynı. Numaranızın kaydı artık başka bir rehberde tutuluyorsa, eski rehberdeki kayıt kartına yaptığınız düzeltmeyi kimse görmez. Kart doğru doldurulmuştur, ama artık kimse o kartın olduğu yere bakmıyordur.

Barındırma platformuna geçtiğinizde kayıt yazma biçimi de biraz değişir. Kök alan adı için (yani sercebilisim.com için) platformun verdiği bir A kaydı yazılır; www gibi alt alan adları için ise CNAME kullanılır. Neden ikisinin farklı olduğu bir sonraki bölümün konusu ve bunun teknik bir sebebi var.

Domain Transferi ile Nameserver Değişikliği Aynı Şey Değildir

Bu iki işlem sürekli birbirinin yerine kullanılıyor ve kesintilerin önemli bir kısmı bu karışıklıktan doğuyor. Transfer, alan adının kayıt kuruluşunu değiştirir: fatura, yenileme ve sahiplik kaydı yeni tarafa geçer. Nameserver değişikliği ise alan adının kayıtlarının nerede tutulacağını değiştirir. Biri sahiplik, diğeri içerik.

Numara taşımayı düşünün. Operatörünüzü değiştirdiğinizde numaranız aynı kalır, sizi arayanlar bir şey fark etmez. Değişen tek şey faturayı kimin kestiği ve hattı kimin işlettiğidir. Rehberdeki kaydınıza kimse dokunmamıştır.

Pratik sonucu şudur: transferin kendisi kesinti üretmez, nameserver değişikliği üretir. Transfer sırasında yaşanan kesintilerin sebebi neredeyse her zaman aynıdır: aynı gün nameserver’lar da çevrilir ve yeni tarafta bölge eksik kurulmuştur. En sık unutulan kayıtlar da MX ile TXT’tir, yani mail akışı ve doğrulama. Site açılmaya devam eder, mailler sessizce durur ve bu birkaç saat fark edilmez.

Doğru sıra basittir ve iki adımı birbirinden ayırır:

1. Yeni tarafta bölgeyi birebir kurun: mevcut nameserver’dan bütün kayıtları okuyup yeni panele girin, hiçbirini “gerekli değildir” diye atlamayın.
2. Yeni sunucuya doğrudan sorarak doğrulayın: Resolve-DnsName sercebilisim.com -Server yeni-ns.ornek.com ile her kritik kaydı tek tek kontrol edin.
3. Ancak ondan sonra nameserver’ı çevirin. Eski sağlayıcıdaki bölgeyi de en az bir hafta silmeyin.

Transferin kendi tarafında da bilmeniz gereken birkaç kural var. Alan adının kilidi açılır, kayıt kuruluşundan bir yetki kodu (EPP ya da Auth Code) alınır ve yeni taraf bu kodla talebi başlatır. Çoğu uzantıda iki ayrı 60 günlük kilit işler: yeni kaydedilmiş bir alan adı ilk 60 gün transfer edilemez, transfer edilmiş bir alan adı da sonraki 60 gün yeniden transfer edilemez. Yani “alan adını alalım, sonra asıl kullanacağımız yere taşırız” planı ilk iki ay çalışmaz. Bu yüzden transfer, bir kesinti anına ya da kampanya dönemine denk getirilmez.

DNS Kayıt Türleri: A, AAAA, CNAME, MX, TXT, NS ve SRV

DNS kayıt türleri, aynı isim altında farklı soruların cevaplarını tutar. Bir alan adı tek bir şeye işaret etmez: web trafiği bir yere, mail başka bir yere, doğrulama bilgisi bambaşka bir yere gider ve hepsi aynı bölgenin içinde durur.

Rehberdeki kayıt kartı da tek satır değildi. Aynı ismin altında ev telefonu, iş telefonu, faks ve adres ayrı ayrı yazardı. Hangisini soruyorsanız onu alırdınız.

A ve AAAA: İsmin Karşılığındaki Adres

A kaydı bir ismi IPv4 adresine, AAAA kaydı ise IPv6 adresine bağlar ve DNS’in en temel kaydıdır. Bir sitenin açılması için gereken minimum kayıt budur.

İki incelik var. Birincisi, aynı isim için birden fazla A kaydı tanımlanabilir ve cevaptaki sıra her sorguda değişebilir; bunu hem yetkili sunucu hem aradaki çözümleyici yapar. Bu ilkel bir yük dağıtımı sağlar ama sağlık kontrolü yapmaz. Kapanmış bir sunucunun adresi listede durduğu sürece ziyaretçilerin bir kısmı oraya gitmeye devam eder. İkincisi, AAAA kaydı eklemek IPv6 tarafını açar ve eğer o adres gerçekten hizmet vermiyorsa, IPv6 tercihli istemciler siteyi açamaz. Yarım bırakılmış bir IPv6 geçişi, hiç başlamamış bir geçişten daha çok arıza üretir.

CNAME ve Kök Alan Adı Sınırı

CNAME kaydı bir ismi başka bir isme bağlar; adres tutmaz, takma ad tanımlar. www.sercebilisim.com için bir CNAME yazdığınızda, sorgu o ismin işaret ettiği hedefe devredilir ve adres oradan okunur. Barındırma platformlarının alt alan adları için CNAME istemesinin sebebi budur: platform kendi adresini istediği zaman değiştirebilir, sizin kaydınıza dokunmaya gerek kalmaz.

Burada standardın koyduğu sert bir sınır var ve pratikte herkesin başına geliyor: kök alan adına CNAME konmaz. Sebebi teknik ve nettir. Bir CNAME kaydı, aynı isim altında başka hiçbir kaydın bulunmamasını şart koşar. Oysa kök alan adında zorunlu olarak SOA ve NS kayıtları durur, üstelik çoğu kurumda MX ve TXT de oradadır. Kök alan adına CNAME yazmak bu kayıtları gölgeler; en görünür sonucu da mail akışının durmasıdır.

Sağlayıcılar bu sınırı iki yoldan aşar. Ya kök için düz bir A kaydı verirler, ya da ALIAS veya ANAME denen sağlayıcıya özgü bir kayıt tipi sunarlar; bu kayıt dışarıya A gibi görünür, arka planda hedefi takip eder. Standart bir kayıt türü olmadığı için de her sağlayıcıda bulunmaz.

MX: Postayı Hangi Sunucu Alıyor?

MX kaydı, o alan adına gönderilen postayı hangi sunucunun kabul edeceğini söyler ve yanında bir öncelik sayısı taşır. Sayı küçüldükçe öncelik artar: 10 değerli sunucu 20 değerliden önce denenir. Aynı önceliğe sahip birden fazla sunucu varsa yük aralarında dağılır.

Kurumsal tarafta en sık yapılan yapılandırma şudur: site bir barındırma platformunda durur, mail bir bulut sağlayıcısındadır. Yani A kaydı bir yeri, MX kaydı bambaşka bir yeri gösterir ve ikisi aynı bölgede yan yana yaşar. Bu bir çelişki değil, olağan kurulumdur.

Panelde işlem şöyle yürür. Bulut sağlayıcınız size bir MX listesi verir; her satırda bir sunucu adı ve bir öncelik değeri bulunur. DNS panelinizde her satır için ayrı bir kayıt açar, tür olarak MX seçer, isim alanını kök alan adı için boş bırakır, hedefe sunucu adını, öncelik alanına da sağlayıcının verdiği sayıyı yazarsınız.

Kaç satır gireceğiniz sağlayıcıya ve kurulumun yaşına göre değişir, bu yüzden internette bulduğunuz eski bir rehberi körlemesine izlemeyin. Google Workspace bunun en iyi örneği: 2023 Nisan’ından önce açılan hesaplar farklı önceliklerle beş ayrı kayıt isterdi, o tarihten sonra açılanlar için tek bir kayıt (smtp.google.com, öncelik 1) aynı işi görüyor. Yedeklilik ve yük dağıtımı artık o tek isim adının arkasında hallediliyor. Eski beşli kurulum çalışmaya devam ediyor, yani mevcut bir bölgede beş satır görmeniz bir hata değil. Sağlayıcının bugünkü kendi dokümanına bakın ve size kaç satır veriyorsa hepsini girin; yarısını girip bırakmak yapılandırmayı tamamlamaz.

En sık yapılan hata da burada: eski sağlayıcının MX kayıtlarını silmeden yenilerini eklemek. İki takım MX kaydı yan yana durduğunda postanın bir kısmı eski, artık kimsenin bakmadığı bir kutuya düşer. Kayıp mail şikayeti günler sonra gelir ve nedeni aranırken kimsenin aklına DNS gelmez.

Kayıt kartında ev telefonu değişmiş ama eskisi silinmemiş gibi. Arayanların bir kısmı hâlâ eskisini deniyordur ve size ulaşamadığını söyleyecek kimse yoktur.

Buradan çıkan kural şu: A kaydında iki adresi bir süre yan yana tutmak ilkel bir yük dağıtımı verirken, MX tarafında aynı şey postanın bölünmesi demektir. Mail sağlayıcısı değiştirirken bu yüzden eski ve yeni kayıtları aynı işlemde değiştirin; panel toplu düzenlemeye izin veriyorsa listeyi tek seferde kaydedin.

Sakın “önce hepsini silip sonra yenilerini gireyim” demeyin, çünkü hiç MX kaydı olmaması, yanlış MX kaydından daha tehlikelidir. Bir alan adında MX kaydı bulunmadığında gönderen sunucu postayı çöpe atmaz: standart gereği A kaydına düşer ve postayı doğrudan web sunucunuza teslim etmeye çalışır. O tarafta mail servisi olmadığı için mesajlar ya reddedilir ya da kaybolur. Kayıtsız geçen o birkaç dakika, iki takım kaydın yan yana durduğu saatlerden daha pahalıya patlayabilir.

TXT: SPF, DKIM ve DMARC

TXT kaydı serbest metin tutar ve bugün asıl işi mail kimliğini kanıtlamaktır. Üç kayıt birlikte çalışır ve üçü de bölgenizde durur.

SPF, sizin adınıza kimin mail gönderebileceğini listeler. Tek bir TXT satırı olarak yazılır ve burada iki katı kural vardır: bir alan adında yalnızca bir tane SPF kaydı bulunabilir, iki tane olduğunda kayıt geçersiz sayılır ve kontrol hataya düşer. İkincisi, SPF değerlendirmesi sırasında yapılabilecek DNS sorgusu sayısı on ile sınırlıdır; birden fazla sağlayıcıyı include ile zincirlediğinizde bu sınır sessizce aşılır ve kayıt yine geçersiz olur.

DKIM, giden maile bir imza koyar ve imzanın açık anahtarını TXT kaydında yayımlar. Kayıt, sağlayıcının verdiği bir seçici (selector) altında durur.

DMARC, ilk ikisinin sonucuna göre ne yapılacağını söyler: hiçbir şey yapma, karantinaya al ya da reddet. _dmarc alt alan adında tutulur ve rapor adresi tanımlayabilirsiniz.

Buradan çıkan pratik teşhis şu: giden mailleriniz karşı tarafta spam’e düşüyorsa sorun çoğu zaman mail sunucusunda değil, DNS bölgenizdedir. Mail sunucusunu kurcalamadan önce bu üç kaydı okuyun; sıralamayı tersine çevirmek en çok vakit kaybettiren alışkanlıklardan biridir.

SRV: Kurumsal Ağın Kendi Kaydı

SRV kaydı, bir servisin hangi sunucuda ve hangi portta çalıştığını söyler; A kaydından farkı port ve öncelik bilgisini de taşımasıdır. İnternet tarafında SIP ve VoIP kurulumlarında karşınıza çıkar. Kurumsal tarafta ise Active Directory’nin omurgasıdır.

Domain’e üye bir bilgisayar açıldığında hangi Domain Controller’a başvuracağını bilmez. _ldap._tcp.dc._msdcs.ad.sercebilisim.com gibi bir SRV sorgusu yapar ve kendisine uygun Domain Controller’ı öğrenir. Bu kayıtlar iç DNS’te oluşturulur; dış bir DNS sunucusunda karşılıkları yoktur.

Sonucu da makalenin başında söylediğimiz şeye çıkar: istemcinin birincil DNS’i dış bir adres olarak yazıldığında internet sorunsuz çalışır, sayfalar açılır ve domain oturumu açılmaz. Sahada en çok yanlış teşhis edilen arıza tam olarak budur, çünkü kullanıcının anlattığı belirti ile arızanın katmanı birbirini hiç işaret etmez.

CAA: Sertifikayı Kim Kesebilir?

CAA kaydı, bir alan adına hangi sertifika otoritesinin sertifika kesebileceğini belirler ve bugün neredeyse her otorite sertifika üretmeden önce bu kaydı kontrol etmek zorundadır. Amacı kötü niyetli ya da yanlışlıkla kesilmiş sertifikaların önüne geçmektir.

Kaydı olmayan bir alan adında kısıt da yoktur, yani herkes sertifika kesebilir; bu yüzden CAA yokluğu bir arıza üretmez. Arıza tam tersi durumda çıkar ve teşhisi zordur: bölgede bir CAA kaydı vardır, listede yalnızca eski sağlayıcınızın otoritesi yazılıdır ve yeni platformunuz sertifikayı kesemez. Belirti de “site yayına alındı ama HTTPS bir türlü açılmadı” olur; hata mesajı DNS’ten değil, sertifikadan bahseder.

Barındırma platformları otomatik sertifika kestiği için bu kontrolü kurulum listenize alın: yeni bir platforma geçiyorsanız CAA kaydınızı okuyun, kısıt varsa yeni otoriteyi listeye ekleyin.

Kaydı Yazarken: İsim Alanı, Kök Alan Adı ve Sondaki Nokta

Kayıt türünü bilmek yetmez, panelin sizden ne istediğini de bilmek gerekir; aynı kaydın farklı sağlayıcılarda farklı yazılması bu işin en can sıkıcı tarafıdır. Üç alan sürekli karışır.

İsim alanı. Buraya alan adının tamamını değil, yalnızca ön ekini yazarsınız. www.sercebilisim.com için yazılacak değer www’dur. Kök alan adının kendisi için ise alan ya boş bırakılır ya da @ işareti konur; ikisi aynı şeyi ifade eder ve hangisini istediği sağlayıcıya göre değişir. Buraya alan adını tam olarak yazmak en sık yapılan hatadır ve sonucunda www.sercebilisim.com.sercebilisim.com gibi bir kayıt oluşur. Panel hata vermez, kayıt kaydedilir, hiçbir işe yaramaz.

Sondaki nokta. Bölge dosyası mantığında sonu nokta ile biten bir isim mutlak kabul edilir, bitmeyen isme ise bölge adı eklenir. Çoğu modern panel bunu sizin yerinize halleder, ama bazıları hedef alanında sondaki noktayı bekler. CNAME ve MX hedefleri beklendiği gibi çalışmıyorsa bakılacak ilk yerlerden biri budur.

TTL alanı. Her kaydın kendi TTL değeri vardır ve panelde genellikle saniye cinsinden girilir. Varsayılan olarak gelen değer çoğu sağlayıcıda saatler mertebesindedir; ne anlama geldiği ve ne zaman değiştirilmesi gerektiği bir sonraki bölümün konusu.

Kayıt yazdıktan sonra paneli kapatıp “oldu” demeyin. Yazdığınız her kritik kaydı yetkili sunucuya doğrudan sorarak doğrulayın; nasıl yapıldığını teşhis bölümünde tek komutla gösteriyoruz. Panelde kaydı görüyor olmak, dünyanın o kaydı okuduğunun kanıtı değildir.

Kayda Not Düşün: Bir Yıl Sonra Kimse Hatırlamıyor

Bir DNS kaydında en çok boş bırakılan alan değeri değil, yanındaki not alanıdır. Vercel’de her kaydın bir Comment alanı vardır, Cloudflare tarafında da aynısı bulunur. İkisi de çözümlemeyi hiçbir şekilde etkilemez ve tam olarak bu yüzden doldurulmadan geçilir.

Bedeli bir sonraki kişiye çıkar. Bölgeyi bir yıl sonra açtığınızda karşınızda birkaç TXT kaydı durur: biri hâlâ çalışan bir servisin sahiplik doğrulaması, biri iki yıl önce denenip bırakılmış bir aracın kalıntısı, biri de kimsenin hatırlamadığı bir şey. Hangisinin silinebileceğini kimse bilmez. Sonuç iki yönden de kötüdür. Ya hiçbirine dokunulmaz ve bölge yıllar içinde şişer, ya da biri temizlik yapar ve çalışan bir doğrulamayı düşürür. İkincisinin faturası genellikle maillerin spam’e düşmesiyle kesilir ve kimsenin aklına iki hafta önceki DNS temizliği gelmez.

Bu işin neden bu kadar sık aksadığına dair bir gözlemim var ve kimseyi suçlamakla ilgisi yok. Kendine mid ya da senior diyen pek çok kişinin basit bir TXT veya MX düzenlemesinde tereddüt ettiğini gördüm. Sebep bilgisizlik değil ve tek de değil: iki şey üst üste biniyor.

Birincisi öğrenme biçimi. Sahada çoğumuz teoriyi atlayıp doğrudan pratikle öğreniyoruz. Panele girilir, gösterilen kutu doldurulur, iş biter ve bu yöntem tanıdık durumlarda gayet de iyi çalışır. Ama zincir kafada kurulmadığında ilk sürprizde tutunacak bir yer kalmaz. Kaydı yazıp hiçbir şeyin değişmediğini gören kişinin nereye bakacağını bilememesinin sebebi yeteneksizlik değil, o kişinin hiç kimsenin ona anlatmadığı bir haritayı kendi başına kurmak zorunda kalmasıdır.

İkincisi temas sıklığı. Bir sistem yöneticisi haftada onlarca grup ilkesine dokunur ama DNS bölgesine yılda birkaç kez girer. Az yapılan, geri alması yavaş ve yanlış yapıldığında bütün kurumun mailini durduran bir iş doğal olarak tedirginlik üretir. Üstüne bir de “bu kayıt neydi” bilgisizliği binince kimse dokunmak istemez, iş sürüncemede kalır.

Çözüm eğitim değil, kayıt tutmaktır. Her kayda üç şey yazın: ne işe yaradığı, kimin talebiyle eklendiği ve tarihi. Google Workspace alan adı doğrulaması, 2026-03, İK talebi gibi tek satırlık bir not, bir yıl sonra o kaydın silinip silinemeyeceğine saniyeler içinde karar verdirir. Panelinizde not alanı yoksa bölgeyi dışarıda belgeleyin; nerede tuttuğunuz önemli değil, tuttuğunuz önemli.

Rehber kartına dönersek: üzerinde kimin yazdığı ve neden yazıldığı belli olmayan bir kart, doğru numarayı taşısa bile kimsenin güvenip değiştirmeye cesaret edemediği bir karttır. Kurumlarda silinmeyen kayıtların çoğu yanlış olduğu için değil, sahibi bilinmediği için duruyor.

TTL ve Önbellek: DNS Değişikliği Neden Hemen Yansımaz?

DNS değişikliği anında yapılır, ama anında görünmez. Bekleme süresini belirleyen şey sunucunun hızı değil, eski cevabın kaç yerde saklandığıdır. O sürenin adı TTL’dir (Time To Live) ve her kaydın kendi TTL değeri vardır.

Rehberden aldığınız numarayı telefonunuza kaydettiğinizde de aynısı oluyordu. Kişi numarasını değiştirse bile sizin defterinizdeki kayıt duruyordu; siz eskisini arıyordunuz ve yanlış olduğunu ancak biri size söylediğinde öğreniyordunuz.

Önbellek Üç Katmanda Durur

Bir DNS cevabı tek bir yerde değil, üst üste üç katmanda saklanır ve değişikliğin görünmesi için üçünün de tazelenmesi gerekir.

Tarayıcı. Modern tarayıcıların kendi DNS önbelleği vardır ve işletim sisteminden bağımsız çalışır. İşletim sistemi önbelleğini temizleyip hâlâ eski cevabı almanızın sebebi çoğu zaman budur.

İşletim sistemi. Windows tarafında DNS Client servisi cevapları tutar. ipconfig /displaydns ile içeriğini görür, ipconfig /flushdns ya da Clear-DnsClientCache ile boşaltırsınız. Aynı katmanda bir de hosts dosyası durur, ama o bir önbellek değildir ve teşhiste ayrı bir yere oturur; az sonra ele alıyoruz.

Özyinelemeli çözümleyici. Asıl belirleyici katman budur ve size ait değildir. Kurumun iç DNS sunucusu, servis sağlayıcısının sunucusu ya da genel bir çözümleyici olabilir. Kendi tarafınızdaki iki katmanı bir saniyede temizlersiniz; bu üçüncüsü TTL süresi dolana kadar eski cevabı vermeye devam eder ve ona müdahale edemezsiniz.

Bunun doğrudan bir sonucu var ve sahada sürekli yaşanır: “bende açılıyor, sende açılmıyor” bir tuhaflık değil, önbelleğin normal davranışıdır. İki kullanıcı farklı çözümleyicilerin arkasındaysa, farklı cevaplar almaları beklenen durumdur.

”Propagation” Yayılma Değil, Önbelleğin Boşalmasıdır

DNS değişikliklerinin yayılması için kullanılan propagation terimi aslında yanlış bir resim çiziyor. Ortada dünyaya yayılan bir güncelleme yok. Yetkili sunucudaki kayıt değiştiği anda yeni cevap hazırdır; sadece eski cevabı önbelleğinde tutan her çözümleyici, kendi TTL süresi dolana kadar yenisini sormaz.

Yani beklediğiniz şey bir yayılma değil, bir zaman aşımıdır. TTL 300 saniyeyse beş dakika, 86400 saniyeyse bir güne kadar sürer. “24-48 saat sürer” sözünün arkasında da bu vardır: yüksek TTL’li kayıtlar ve gecikmeli davranan bazı çözümleyiciler.

Az bilinen ama teşhiste çok işe yarayan bir katman daha var: negatif önbellek. Bir isim sorulduğunda “böyle bir kayıt yok” cevabı da önbelleğe alınır ve süresini bölgenin SOA kaydındaki minimum değer belirler. Pratik karşılığı şudur: bir kaydı eklemeden önce o ismi sorgularsanız, aldığınız olumsuz cevap önbelleğe girer ve kaydı ekledikten sonra bir süre daha “bulunamadı” almaya devam edersiniz. Kayıt doğrudur, panel doğrudur, bekleyen şey negatif önbelleğin süresidir. Bunu bilmeyen bir yönetici aynı kaydı üç kez siler ve yeniden yazar.

Geçişten Önce TTL’i Düşürmek

Bir sunucu ya da sağlayıcı geçişini kesintisiz yapmanın yolu, geçişin kendisinde değil hazırlığındadır: taşınacak kayıtların TTL’ini geçişten 24-48 saat önce düşürün. Değeri 300 saniyeye çekmek yeterlidir.

Mantığı basittir. TTL’i bugün düşürseniz bile, çözümleyiciler ellerindeki eski kaydın TTL’i dolana kadar bunu öğrenmez. Yani düşürme işleminin kendisi de eski TTL kadar bekler. Geçiş gününde kısa TTL’in yürürlükte olması için bu bekleme süresini önceden harcamanız gerekir.

Geçiş tamamlanıp her şey oturduktan sonra TTL’i eski değerine geri çıkarın. Sürekli düşük TTL bedava değildir: her sorgu daha sık yetkili sunucuya gider, çözümleme gecikmesi artar ve yetkili sunucunuz kısa bir kesinti yaşadığında bunu çok daha fazla ziyaretçi hisseder.

Kurumsal DNS: Sorguyu Kim Cevaplıyor?

Kurumsal ağda asıl soru DNS’in ne olduğu değil, sorguyu kimin cevapladığıdır. Aynı cihaz, aynı isim için farklı yerlere sorduğunda farklı cevaplar alabilir ve kurumsal DNS arızalarının neredeyse tamamı bu cümlenin içinde saklıdır.

İç DNS, Servis Sağlayıcının Sunucusu ve Genel Çözümleyici

Bir istemcinin kullanacağı DNS sunucusu ona genellikle DHCP ile gelir; adresle birlikte dağıtılan dört bilgiden biri de budur ve ayrıntısını DHCP nedir rehberimizde ele alıyoruz. Buraya hangi adresin yazılacağı ise kurumun yapısına göre değişir ve üç seçenek vardır.

Domain ortamında cevap tartışmasızdır: iç Domain Controller. İstemci Domain Controller’ı SRV kayıtlarından bulur, o kayıtlar da yalnızca iç DNS’te durur. Buraya bir dış adres yazmak domain oturumunu bitirir. Dış dünyayı çözme işi istemcinin değil, iç DNS sunucusunun sorunudur; o da bilmediği sorguları bir üst kaynağa iletir. Bu iletme ayarının adı forwarder’dır ve yapılandırması Active Directory DNS rehberimizin konusudur.

Domain olmayan küçük bir yapıda servis sağlayıcının çözümleyicisi ya da 1.1.1.1, 8.8.8.8 gibi genel bir çözümleyici yeterlidir. Aralarındaki fark hızdan çok filtreleme tarafındadır: sağlayıcının sunucusu bulunduğunuz ülkenin erişim kararlarını uygular, genel çözümleyicilerin bir kısmı uygulamaz, bir kısmı da kendi zararlı yazılım filtresini uygular. Yani “filtresiz” diye bir çözümleyici yok; hangi filtrenin geçerli olduğu değişiyor.

Kurumun kendi çözümleyicisini kurduğu durumda ise tek bir kural vardır: o sunucu yalnızca kendi ağına özyinelemeli cevap vermelidir. İnternete açık bırakılmış bir çözümleyici, kurumun bant genişliğini başkalarına yönelik saldırılarda kullandırır.

Yerel çözümleme kayıtlarının kurumda tutuluyor olması yalnızca teknik bir konu da değil. İç IP ile cihaz eşleşmesinin saklanması gereken bir ortamda, çözümlemenin nerede yapıldığı doğrudan kayıt bütünlüğünü ilgilendirir; kapsam ve saklama süresi ayrıntıları 5651 log yönetimi rehberimizde.

Kendi Sunucunuz İçerideyse Ne Değişir?

Dışarıya hizmet veren bir sunucuyu kendi ağınızda barındırıyorsanız, aynı isim iki farklı cevaba ihtiyaç duyar. İnternetten gelen kullanıcı sunucunun genel IP adresini almalıdır; ofisten aynı ismi soran kullanıcı ise sunucunun iç IP adresini almalıdır, çünkü sunucu zaten yanı başındadır.

İç kullanıcıya genel adres verildiğinde paket ağdan çıkar, güvenlik duvarına kadar gider ve içeri geri döner. Buna hairpin NAT denir. Bazı cihazlar bunu hiç desteklemez ve bağlantı düşer; destekleyenlerde ise trafik gereksiz yere kenar cihazın üzerinden geçer.

Aynı ismin iç ağda farklı, dışarıda farklı cevaplanmasına split-brain DNS denir. Bunun kurumsal ağdaki tasarımı, adım adım yapılandırması ve bakım maliyeti (her genel kayıt değişikliğinde iç bölgenin de güncellenmesi gerekir) ayrı bir konu: Active Directory DNS rehberimizin split-brain bölümüne doğrudan geçebilirsiniz. Yukarıda geçen forwarder yapılandırması da aynı rehberde.

Buradan alınacak şey mekanizmanın kendisi: bir isim tek bir cevaba mahkum değildir. Kime sorulduğuna göre değişebilir ve kurumsal ağlarda genellikle değişir.

Rehberin bu makaledeki en son dersi de bu. Aynı ismi iki farklı yere sorduğunuzda iki farklı numara alabilirsiniz ve ikisi de yanlış olmayabilir: biri kurumun kendi iç listesinden, diğeri herkese açık listeden okumuştur. “Dışarıdan açılıyor, içeriden açılmıyor” şikayetinin altında neredeyse her zaman bu yatar ve çözüm listelerden birini düzeltmektir, ikisini birden aynı yapmak değil.

Sahadan: Dışarıdan Açılıyor, İçeriden Açılmıyor

Bu ayrımın ne kadar kafa karıştırabildiğini bir eğitim kurumunda birebir yaşadım. Satın alma portalına erişilemiyor diye şikayet geldi. O gün evden çalışıyordum, kendi bağlantımdan denedim ve site sorunsuz açıldı. Israr edilince kurum ağına VPN ile bağlandım: açılmadı. Aynı kampüsteki komşu kurumun kablosuz ağına geçtim: açıldı. Kendi kurum ağına döndüm, yine açılmadı.

Üç farklı yerden aynı ismi sordum ve iki farklı cevap aldım. Sorunun kurumun kendi ağında olduğu o anda kesinleşti, çünkü değişen tek değişken soruyu kime sorduğumdu.

Sebep yıllar öncesine dayanıyordu. Web sunucuları dışarı taşınmadan önce bir sistemci, o alt alan adı için iç DNS’e elle bir A kaydı eklemişti. Yazılım sağlayıcısı sonradan IP adresini değiştirdi, ama iç DNS’teki kayıt olduğu yerde kaldı. İçeriden gelen sorgular Domain Controller’a gidiyor ve orada bayat, artık geçersiz bir adres buluyordu; dışarıdan bağlananlar public DNS’i kullandığı için güncel adrese ulaşıyordu. İki taraf da kendince doğru cevabı veriyordu.

İşin öğretici kısmı teşhis değil, tepkiydi. Kurumun kıdemli sistemcileri suçu hizmet sağlayıcısına yıktı: “bizden kaynaklanmıyor.” Bir bakıma haklıydılar da, kendi taraflarında o hafta hiçbir şey değişmemişti. Değişiklik yıllar önce yapılmıştı ve kaydı yazan kişi çoktan kurumdan ayrılmıştı.

Buradan iki şey kalsın. Birincisi, “bizde bir şey değişmedi” cümlesi DNS’te hiçbir şeyi kanıtlamaz. Bayat bir kayıt yıllarca sessizce durur ve arızaya, karşı taraf adresini değiştirdiği gün dönüşür. İkincisi, bu tür bir şikayette en hızlı hamle sunucu loglarına dalmak değil, soruyu başka birine sormaktır. Farklı bir ağdan, farklı bir çözümleyiciden aynı ismi sorun. Cevaplar ayrışıyorsa arızanın hangi tarafta olduğunu bir dakikada öğrenirsiniz; ayrışmıyorsa DNS’i listeden çıkarıp başka katmana geçersiniz. Bu vakanın Windows tarafındaki kalıcı çözümü ve iç bölge yönetimi, yukarıda bağladığımız Active Directory DNS rehberinde ele alınıyor.

DNS Arızasında Teşhis Sırası

DNS arızasını çözerken sorulacak üç soru vardır ve sırası önemlidir: isim çözülüyor mu, cevabı kim verdi, o cevap doğru mu? Üçünün de aracı aynıdır ve ikinci soru en çok atlanandır. Yanlış numarayı aldığınızda önce numarayı değil, kime sorduğunuzu tespit edersiniz; rehberi arayan da, kendi defterine bakan da aynı cevabı vermek zorunda değildir.

Üç Soru, Üç Komut

Windows tarafında Resolve-DnsName, nslookup’a göre daha güvenilir sonuç verir; nslookup sorguya makinenin alan adı sonekini eklediği için bazı ortamlarda beklenmedik isimler döndürebilir.

# 1. İsim hangi adrese çözümleniyor
Resolve-DnsName sercebilisim.com

# 2. Bu alan adının kayıtlarını kim tutuyor (yanlış panel arayışını bitirir)
Resolve-DnsName sercebilisim.com -Type NS

# 3. Yetkili sunucuya DOĞRUDAN sor, aradaki bütün önbellekleri atla
Resolve-DnsName sercebilisim.com -Server ns1.ornek-saglayici.com

# 4. Mail ve doğrulama kayıtları yerinde mi
Resolve-DnsName sercebilisim.com -Type MX
Resolve-DnsName sercebilisim.com -Type TXT

# 5. İstemci önbelleğini oku ve boşalt
Get-DnsClientCache
Clear-DnsClientCache

Komut satırında nslookup, Linux ve macOS tarafında dig aynı işi görür:

dig sercebilisim.com
dig sercebilisim.com NS
dig @ns1.ornek-saglayici.com sercebilisim.com
dig sercebilisim.com MX +short

dig çıktısında üç yere bakılır ve üçü farklı sorulara cevap verir. ANSWER SECTION istediğiniz kaydı gösterir. Çıktının en altındaki ;; SERVER: satırı sorunun hangi sunucuya sorulduğunu söyler; bir cevabı tartışırken önce bu satırı okumak gerekir, çünkü aynı sorgu farklı sunucularda farklı cevap verebilir. Üstteki bayrak listesinde aa görüyorsanız cevap yetkili sunucudan gelmiştir, görmüyorsanız aradaki bir çözümleyiciden gelmiştir. AUTHORITY SECTION ise size cevabı vereni değil, o bölgenin yetkili sunucularını listeler; ikisi sıkça karıştırılır.

nslookup tarafında aynı bilgiyi Non-authoritative answer ibaresi verir: cevap yetkili sunucudan değil, aradaki bir çözümleyiciden gelmiştir ve o çözümleyici size önbelleğindeki eski bir değeri veriyor olabilir. Kaydın gerçekten güncellendiğini anlamanın tek yolu yetkili sunucuya doğrudan sormaktır.

hosts Dosyası: DNS’e Hiç Sormadan Cevap Vermek

Bir isim, DNS’e hiç sorulmadan da cevaplanabilir. İşletim sistemi çözümlemeye başlamadan önce yerel hosts dosyasına bakar ve orada bir eşleşme bulursa zincirin tamamını atlar: kök, TLD, yetkili sunucu, önbellek, hiçbiri devreye girmez.

Bunun bir önbellek olmadığını vurgulamak gerekiyor, çünkü ikisi sürekli karıştırılıyor. Önbellekteki kayıt bir yerden gelmiştir ve TTL’i dolunca kendiliğinden düşer. hosts dosyasındaki satır ise kimseden gelmemiştir, süresi yoktur ve siz silene kadar durur.

Dosya Windows’ta C:\Windows\System32\drivers\etc\hosts, Linux ve macOS’ta /etc/hosts yolundadır ve uzantısı yoktur. Buradaki klasik tuzak da tam olarak budur: Not Defteri ile açıp kaydettiğinizde dosya sessizce hosts.txt olarak yazılır. Yeni dosyayı hiçbir şey okumaz, eski dosya olduğu gibi kalır ve yaptığınızı sandığınız değişiklik hiç var olmaz. Kaydederken dosya adını tırnak içine alın ya da düzenleyiciyi yönetici yetkisiyle açıp üzerine yazın.

Teşhis tarafında işe yarayan asıl ayrım şu: nslookup bu dosyayı okumaz. Sorguyu doğrudan DNS sunucusuna gönderir. Tarayıcı, ping ve varsayılan haliyle Resolve-DnsName ise okur. Dolayısıyla “nslookup doğru adresi gösteriyor ama tarayıcı bambaşka bir yere gidiyor” tablosunun altında çoğu zaman elle yazılmış bir hosts satırı vardır.

# Normal yol: hosts dosyası ve istemci önbelleği dahil
Resolve-DnsName sercebilisim.com -Type A

# Yalnızca DNS: hosts dosyasını ve önbelleği atla
Resolve-DnsName sercebilisim.com -Type A -DnsOnly -NoHostsFile

Sahada bu satırlar neredeyse her zaman iyi niyetle yazılır: bir geçiş sırasında test için, bir sunucu taşınırken geçici çözüm olarak. Sonra kimse silmez. Kalıcı hale gelmiş geçici bir hosts kaydı o makineyi ağın geri kalanından sessizce ayırır; arıza aylar sonra ve bambaşka bir sebep aranırken bulunur.

Belirtiden Sebebe

Son iki satır bu tablonun en çok vakit kazandıran kısmı. Sondan bir önceki satır makalenin başındaki ayrıma dayanıyor: DNS bağlantı kurmaz, yalnızca cevap verir. İsim doğru adrese çözülüyorsa DNS işini bitirmiştir ve aramayı başka katmana taşımanız gerekir. Sonuncusu ise bir sonraki bölümün konusu.

DNS Güvenliği: Önbellek Zehirlenmesi, DNSSEC ve Şifreli DNS

DNS internetin en eski protokollerinden biri ve kimlik doğrulama düşünülmeden tasarlandı. Sorduğunuz soruya gelen cevabın gerçekten yetkili sunucudan geldiğini protokolün kendisi kanıtlamaz. Güvenlik tarafındaki bütün eklemeler bu tek boşluğu kapatmak için geldi.

Önbellek Zehirlenmesi ve DNSSEC

Önbellek zehirlenmesi (cache poisoning), bir çözümleyicinin önbelleğine sahte bir cevap yerleştirilmesidir. Saldırgan gerçek cevaptan önce davranıp uydurma bir adres verirse, çözümleyici bunu kaydeder ve TTL süresi boyunca ona soran herkese aynı yanlış adresi dağıtır. Kullanıcı doğru ismi yazar, tarayıcısında doğru isim görünür ve bambaşka bir sunucuya bağlanır.

Sahte bir rehber gibi. İsim doğrudur, sorduğunuz yer güvenilir görünmektedir ve size verilen numara başkasına aittir.

Protokol tarafında iki savunma var. Birincisi, çözümleyicilerin sorguyu tahmin edilmesi zor hale getirmesidir: rastgele kaynak portu ve rastgele sorgu kimliği kullanmak saldırının maliyetini ciddi biçimde yükseltti. İkincisi DNSSEC: kayıtları imzalayarak cevabın yetkili sunucudan geldiğini ve yolda değiştirilmediğini kanıtlar. Burada sık yapılan bir yanlış anlamayı düzeltmek gerekiyor: DNSSEC şifrelemez, imzalar. Sorgularınızı gizlemez; yalnızca gelen cevabın sahte olmadığını doğrular. Desteği hem uzantıya hem kayıt kuruluşuna bağlıdır ve açıldıktan sonra kayıt kuruluşu tarafındaki imza bilgisiyle birlikte bakımda tutulması gerekir.

Açık Resolver: Kendi Sunucunuzun Saldırıya Ortak Olması

Kurum içine kurulan bir DNS çözümleyicisinin internete açık bırakılması, o sunucuyu başkalarına yönelik saldırıların aracına çevirir. Mekanizması basit ve bu yüzden yaygın: saldırgan sorguyu sizin sunucunuza gönderir ama kaynak adres olarak hedefin adresini yazar. Cevabı siz üretir ve hedefe yollarsınız. Küçük bir sorguya karşılık çok daha büyük bir cevap döndüğü için, saldırganın gönderdiği trafik yolda büyür; buna yükseltme (amplification) denir.

Sonuç iki taraflı bir zarardır. Hedef, sizin sunucunuzdan gelen trafikle boğulur. Siz ise farkında bile olmadan hattınızı, sunucunuzu ve itibarınızı harcarsınız; olay incelendiğinde trafiğin çıktığı adres kurumunuza aittir.

Bunu daha önce ayırdığımız iki sorgu tipi üzerinden düşünün. Sunucunuz kendi bölgesi için yetkili cevap vermeye devam etmelidir, çünkü dış dünyanın o kayıtları sorması normaldir. Vermemesi gereken şey özyinelemeli hizmettir: tanımadığı bir isim için gidip cevabı arayıp getirmek yalnızca kendi kullanıcılarına sunulacak bir hizmettir. Rehber benzetmesiyle: kayıt kartlarınızı soranlara gösterirsiniz, ama tanımadığınız birinin adına başka rehberleri arayıp numara toplamazsınız.

Pratik karşılığı tek satırlık bir kontroldür: iç DNS sunucunuzun 53 numaralı portu internetten erişilebilir durumda mı? Cevap evet ise, özyinelemeyi yalnızca iç ağ aralıklarıyla sınırlayın.

DoH ve DoT: Gizlilik Kazancı, Kurumsal Maliyet

Şifreli DNS, sorgunun yolda okunmasını engeller ve iki biçimi vardır. DoT (DNS over TLS) 853 numaralı portu kullanır; şifreli olsa da ayrı bir port kullandığı için ağda görünür ve gerektiğinde engellenebilir. DoH (DNS over HTTPS) ise sorguyu 443 numaralı portta normal web trafiğinin içine gömer; ağdan bakıldığında sıradan bir HTTPS bağlantısından ayırt edilemez.

Son kullanıcı için bu bir kazanç. Kurumsal ağ için üç ayrı sorun demektir ve üçü aynı anda ortaya çıkar. DNS tabanlı filtreleme devre dışı kalır, çünkü tarayıcı kurumun sunucusuna hiç sormadan kendi sağlayıcısına gider. İç isimler çözülemez, çünkü dış çözümleyici ad.sercebilisim.com diye bir bölge tanımaz; belirti de “bazı iç uygulamalar tarayıcıda açılmıyor, diğer her şey çalışıyor” olur. Çözümleme kayıtları eksik kalır, çünkü kurumun sunucusundan geçmeyen sorgu hiçbir yere yazılmaz.

Doğru müdahale ağ tarafında değil, cihaz tarafındadır. Tarayıcıyı ilkeyle yönetin: kurumsal cihazlarda şifreli DNS özelliğini kapatın. Firefox tarafında ek bir mekanizma da vardır: iç DNS sunucunuz use-application-dns.net adresine “böyle bir kayıt yok” cevabı döndürüyorsa Firefox kendi şifreli DNS’ini devre dışı bırakır. Port kapatarak çözmeye çalışmak ise yalnızca DoT tarafında işe yarar; DoH’u 443 portunu kapatmadan engelleyemezsiniz, o portu da kapatamazsınız.

Sonuç: Cevabı Kimin Verdiğini Bilmek

Bu makalede bir DNS sorgusunun kökten yetkili sunucuya inen zincirini, alan adını satan taraf ile kayıtları tutan tarafın neden farklı olduğunu, kayıt türlerinin her birinin ne taşıdığını, bir değişikliğin neden hemen görünmediğini ve arıza anında hangi komutla nereye bakılacağını gezdik. Akılda tutulacak tek cümle şu olabilir: DNS’te asıl soru cevabın ne olduğu değil, o cevabı kimin verdiğidir.

Panelde doğru kaydı görüyor olmanız, dünyanın o kaydı okuduğu anlamına gelmez. Aldığınız cevabın doğru görünmesi, onun yetkili sunucudan geldiği anlamına gelmez. Bir şeyin sizde çalışıyor olması, komşu masada çalıştığı anlamına gelmez. Üç sorunun da cevabı tek bir yerde: kime sordunuz ve o nereye baktı?

Bir “nedir” makalesinin sonunda söylenmesi gereken asıl şey de bu. Sahada çoğumuz teoriyi atlayıp pratikle öğreniyoruz ve bu uzun süre işe yarıyor; panele girip gösterilen kutuyu doldurmak günlük işi görür. Ama o yöntem yalnızca tanıdık durumlarda çalışır. Kaydı yazdınız ve hiçbir şey değişmediyse, mailler bir kısım alıcıya gitmiyorsa ya da site dışarıdan açılıp içeriden açılmıyorsa, sizi ileri taşıyan şey panel bilgisi değil kafanızdaki zincirdir.

Bunun bugün fazladan bir değeri var. Yapay zekâya bir DNS sorusu sorduğunuzda akıcı ve kendinden emin bir cevap alırsınız; o cevabın hâlâ güncel olup olmadığını, sizin kurulumunuza uyup uymadığını ve neyi atladığını yalnızca zinciri kurmuş biri ayırt eder. Bu makaledeki MX örneği tam olarak öyle bir tuzaktır: internetteki rehberlerin çoğu hâlâ beş kayıtlık listeyi anlatır, oysa belirli bir tarihten sonra açılan hesaplarda tek kayıt yeterlidir. Doğru soruyu sormak, gelen cevabı tartmak, bir arızayı doğru katmana oturtmak ve bir projeyi baştan kurgulamak; dördü de aynı temele dayanır. Araçlar değişir, temel bilgi yerinde durur ve BT personelini asıl ayıran da odur.

Bilinmeyen numaralar servisi de böyleydi. İyi çalıştığı sürece kimse kaydı kimin tuttuğunu merak etmezdi; ismi söyler, numarayı alır, işine bakardı. Kaydın nerede tutulduğu ancak yanlış numaraya düştüğünüz gün önem kazanırdı.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.