Site açılıyor ama geç yanıt veriyor, e-posta bazen ulaşıyor bazen kayboluyor ve farklı şehirlerden gelen kullanıcılar aynı sayfada bambaşka performans görüyor. Bu tabloyu çoğu zaman tema, sunucu ya da reklam kodları değil; yanlış kurgulanmış DNS ayarları oluşturur. DNS tarafında tek bir kayıt hatası bile erişim, hız, güvenlik ve teslimat zincirini aynı anda bozar. Bu rehberde 100 DNS kullanımını temel mantığıyla ele alacağım; hangi kayıt ne işe yarar, hız için nasıl düzen kurulur, erişim sorunları nasıl teşhis edilir ve riskli noktalar nasıl temizlenir, adım adım anlatacağım. Kendi tecrübemle söyleyebilirim ki, sahada “sunucu sorunu” sanılan vakaların hatırı sayılır bölümü aslında DNS tarafında saklı çıkar.
100 DNS ayarlarını anlamadan hız sorunu çözülmez
100 DNS ifadesi kullanıcı tarafında çoğu zaman DNS çözümleyici, alan adı yönlendirmesi ve kayıt yönetimi başlıklarını aynı sepete koyar. Oysa işin temeli çok nettir: Tarayıcı alan adını sorar, DNS bu adı IP adresine çevirir, ardından istemci doğru sunucuya bağlanır. Bu çeviri ne kadar sağlıklı ilerlerse kullanıcı da o kadar hızlı ve sorunsuz erişir.
DNS hızını tek başına “internet hızım” belirlemez. Şu unsurlar doğrudan etkiler:
– Yetkili ad sunucusunun yanıt süresi
– TTL süresi
– Kayıtların doğruluğu
– IPv4 ve IPv6 yapılandırmasının tutarlılığı
– CNAME zincirinin uzunluğu
– DNSSEC ve güvenlik katmanlarının doğru kurulumu
– Coğrafi dağıtım ve anycast altyapısı
DNS çözümleme süresi, sayfa açılış süresinin tek kalemi değildir ama ilk temas noktasıdır. Google’ın web performansı yaklaşımında alan adı araması ve bağlantı kurulumu, kullanıcı deneyimini etkileyen ilk ağ adımları arasında yer alır. HTTP Archive verileri de yıllardır ilk bağlantı maliyetinin, özellikle mobil ağlarda hissedilir etkisi olduğunu gösterir. Yani DNS tek başına mucize yaratmaz; ama bozuksa iyi bir altyapının avantajını da hızla siler.
En temel kayıt türlerini net tanıman gerekir:
– A kaydı: Alan adını IPv4 adrese bağlar.
– AAAA kaydı: Alan adını IPv6 adrese bağlar.
– CNAME: Bir alan adını başka bir alan adına takma ad olarak bağlar.
– MX: E-posta teslimat sunucularını tanımlar.
– TXT: SPF, DKIM, doğrulama kayıtları ve benzeri metin tabanlı verileri taşır.
– NS: Alan adının hangi ad sunucularında yönetildiğini söyler.
– CAA: Hangi sertifika otoritesinin SSL sertifikası üretebileceğini sınırlar.
– SRV: Belirli servislerin port ve öncelik bilgilerini taşır.
– PTR: Ters DNS için kullanılır, özellikle e-posta itibarı açısından önemlidir.
Burada ilk kritik nokta şu: Her kayıt türü hız için değil, işlev için vardır. Hız optimizasyonu; doğru kayıt seçimi, kısa çözüm yolu, tutarlı yapı ve düşük hata oranıyla gelir.
Hız ve erişim için DNS ayarları nasıl kurulmalı
DNS tarafında iyi yapı kurmak için “tek ayar” yoktur. Doğru yaklaşım, alan adının kullanım amacına göre sade ama sağlam bir kayıt mimarisi oluşturmaktır.
1. A ve AAAA kayıtlarını çakışmasız kur
Web siten hem IPv4 hem IPv6 üzerinden hizmet veriyorsa A ve AAAA kayıtlarının aynı uygulamaya gitmesi gerekir. Çok sık görülen hata şu olur: A kaydı güncellenir, AAAA eski sunucuda kalır. IPv6 kullanan ziyaretçiler hata alır, IPv4 kullananlar siteyi açar. Bu yüzden sorun “bazı kişilerde var” gibi görünür.
APNIC ve Google’ın yıllara yayılan IPv6 ölçümleri, dünya genelinde IPv6 kullanım payının ciddi seviyelere ulaştığını gösteriyor. Bu nedenle AAAA kaydını “şimdilik dursun” mantığıyla bırakmak risklidir. Eğer IPv6 aktif değilse yanlış AAAA yerine hiç AAAA kullanmamak daha güvenlidir.
2. Gereksiz CNAME zincirlerini kısalt
Bir alan adının başka bir CNAME’e, onun da başka bir CNAME’e gitmesi her çözümlemede ek adım demektir. Tarayıcı önce bir adı çözer, sonra diğerini takip eder. Özellikle mobil bağlantılarda bu gecikme daha görünür olur.
Pratik kural:
– Ana alan adında mümkünse doğrudan A veya AAAA kullan.
– Alt alan adlarında CNAME kullanacaksan zinciri tek seviyede tut.
– CDN ya da SaaS servisinin önerdiği yapı dışına çıkma.
Yıllar süren performans takibim gösteriyor ki, çok katmanlı CNAME kurgusu kâğıt üzerinde küçük görünür ama yoğun trafikte ilk byte süresine doğrudan yük bindirir.
3. TTL değerini amaca göre belirle
TTL, bir kaydın ne kadar süre önbellekte tutulacağını belirler. Çok düşük TTL, değişikliklerin hızlı yayılmasını sağlar ama sorgu sayısını artırır. Çok yüksek TTL ise sunucu değişimi ya da hata düzeltmesinde seni yavaşlatır.
Uygulamada işe yarayan çerçeve:
– Sık değişen kayıtlar için 300 ila 900 saniye
– Daha stabil web kayıtları için 3600 saniye
– Uzun süre sabit kalan doğrulama kayıtları için daha yüksek değerler
Sunucu taşıma öncesi TTL’yi 24 ila 48 saat önce düşürmek akıllıca olur. Taşıma tamamlandıktan sonra tekrar yükseltebilirsin. Bu yöntem yıllardır operasyon ekiplerinin kullandığı en temiz geçiş hamlelerinden biridir.
4. NS kayıtlarında tek otorite kullan
Alan adı kayıt kuruluşunda başka, DNS panelinde başka, CDN tarafında başka otorite kullanırsan tutarsızlık çıkabilir. NS kayıtları, alan adının gerçekte nerede yönetildiğini belirler. Burada yarım geçiş en tehlikeli senaryodur.
Kontrol etmen gerekenler:
– Kayıt kuruluşundaki NS ile aktif DNS sağlayıcısı aynı mı
– Glue record gerektiren özel nameserver yapısı var mı
– DNSSEC açıksa DS kaydı doğru mu
ICANN ve büyük kayıt kuruluşlarının teknik dokümanlarında tekrar tekrar vurgulanan konu şudur: Delegasyon zinciri temiz değilse alan adının çözüm güvenilirliği düşer.
5. E-posta kayıtlarını web kayıtlarından ayrı mantıkla yönet
Site açılıyor diye e-postanın da sağlıklı çalıştığını varsayma. MX, SPF, DKIM ve DMARC kayıtları ayrı kontrol ister. DNS tarafında en pahalı hatalardan biri e-posta teslimatındaki itibar kaybıdır.
Temel düzen şöyle olmalı:
– MX kayıtların doğru öncelik sırasına sahip olsun
– SPF kaydın tek satır mantığıyla ilerlesin, çoklu SPF hatasına düşme
– DKIM seçicileri güncel olsun
– DMARC ile izleme başlat, sonra politikayı kademeli sıkılaştır
Google ve Microsoft gibi büyük posta sağlayıcıları son yıllarda alan adı doğrulama ve gönderici itibarı konusunu daha sıkı ele alıyor. Bu yüzden TXT kayıtlarını “çalışıyor gibi” bırakmak yerine düzenli doğrulamak gerekir.
6. DNSSEC kullan ama eksik kurma
DNSSEC, sorgu yanıtının sahte olup olmadığını doğrulamak için imza katmanı ekler. Güvenlik tarafında ciddi artıdır. Ancak yanlış DS kaydı veya yarım aktivasyon alan adını erişilemez hale getirebilir.
DNSSEC kurarken:
– Registrar ile DNS sağlayıcısı arasındaki DS eşleşmesini kontrol et
– Anahtar yenileme takvimini izle
– Geçiş sırasında önbellek etkisini hesaba kat
Cloudflare, ICANN ve çeşitli kök DNS operatörlerinin teknik notlarında bu konu net biçimde yer alır: DNSSEC güvenlik kazandırır, yanlış kurulum ise doğrudan kesinti üretir.
7. CAA kaydı ile sertifika kontrolünü daralt
CAA kaydı hız değil, güvenlik ayarıdır. Yine de erişim sürekliliği açısından kritik rol oynar. Çünkü yanlış ya da eksik CAA, otomatik sertifika yenilemesini aksatabilir. Sertifika süresi dolarsa kullanıcı siteye güvenli bağlanamaz.
Çok kullanılan yapı:
– issue ile izinli sertifika otoritelerini tanımla
– issuewild gerekiyorsa ayrıca belirt
– iodef ile ihlal bildirim adresi ekle
8. Coğrafi erişim için anycast DNS tercih et
Anycast altyapısı, sorguyu en yakın ya da en uygun ağa yönlendirir. Bu yaklaşım dünya geneline yayılan sitelerde daha dengeli çözüm süresi sağlar. Büyük DNS sağlayıcılarının çoğu bunu standart hale getirdi. Buradaki kazanım özellikle farklı ülkelerden trafik alan projelerde belirginleşir.
RIPE NCC ve benzeri ağ topluluklarının ölçümleri, coğrafi dağıtık çözümleme altyapısının gecikme dalgalanmasını düşürdüğünü sık sık ortaya koyuyor. Yerel trafikte fark küçük olabilir; uluslararası trafikte etkisi daha görünür olur.
Erişim kesintisi yaşamadan DNS değişikliği yapmanın yolu
DNS değişikliği sırasında yapılan acele müdahaleler erişim kaybının ana nedenidir. Temiz geçiş için planlı ilerle.
1. Mevcut kayıtların tam envanterini çıkar.
A, AAAA, CNAME, MX, TXT, NS, CAA ve özel servis kayıtlarını tek tek kaydet. Panel ekran görüntüsü almak yetmez; metin olarak dışa aktarmak daha güvenlidir.
2. Yeni sağlayıcıda aynı kayıtları birebir oluştur.
Önce kopyala, sonra iyileştir. Taşıma anında mimari değişiklik yaparsan sorun kaynağını ayırmak zorlaşır.
3. TTL’yi önceden düşür.
Geçişten 24 ila 48 saat önce kritik kayıtların TTL değerini 300 saniye civarına çek. Böylece önbellekler değişikliği daha hızlı alır.
4. Test alt alan adı aç.
Örneğin test alanında yeni sunucuyu dene. SSL, yönlendirme, uygulama yanıtı, IPv6, CDN ve WAF davranışını burada doğrula.
5. NS ya da ilgili kayıt değişimini tek seferde uygula.
Parça parça geçiş çoğu zaman kaos üretir. Özellikle e-posta kayıtlarını unutmamaya dikkat et.
6. Birkaç farklı çözümleyiciyle kontrol et.
Google Public DNS, Cloudflare DNS ve yerel ISS çözümleyicilerinde alan adının nereye çözüldüğünü karşılaştır. Fark varsa önbellek ya da delegasyon sorunu olabilir.
7. Sunucu loglarını ve uptime ölçümünü izle.
DNS yayılımı tek başına yetmez. Yeni hedefte 200 yanıtı geliyor mu, TLS hatası var mı, yönlendirme döngüsü oluşuyor mu, bunu gör.
Kendi tecrübemle söyleyebilirim ki, geçişlerde en çok ihmal edilen iki nokta MX kayıtları ve eski AAAA kayıtlarıdır. İnsanlar web sayfasını kontrol eder ama e-posta akışının sessizce kırıldığını saatler sonra fark eder.
Sahada en sık gördüğüm DNS hataları ve çözüm yolu
Bu bölüm, teoriden çok gerçek operasyonlarda tekrar eden hatalara odaklanır. Hobi Time gibi teknik içeriklerde en çok değer üreten şey, kâğıt üstündeki doğruyla sahadaki doğru arasındaki farkı gösterebilmektir.
Yanlış yönlenen www ve kök alan adı
example.com ayrı yere, www.example.com ayrı yere gidebilir. Bu durumda bir kullanıcı siteyi açarken diğeri hata görebilir.
Çözüm:
– Kök alan için A ya da ALIAS benzeri sağlayıcı çözümünü kullan
– www için tek bir CNAME politikası belirle
– 301 yönlendirmeyi sunucu tarafında net kur
Eski IP’nin DNS’te unutulması
Taşıma sonrası bir alt alan adı eski IP’de kalır. Kullanıcıların bir kısmı yeni sisteme, bir kısmı eski sisteme gider.
Çözüm:
– Tüm zone dosyasını satır satır denetle
– CDN panelindeki origin IP ile DNS panelindeki hedefin uyumlu olduğundan emin ol
– Eski sunucu loglarını birkaç gün izle
Tek SPF kaydı kuralının bozulması
Ayrı servisler için birden fazla SPF TXT kaydı eklenir. Bu yapı doğrulamayı bozabilir.
Çözüm:
– Tek SPF kaydında include mekanizmasıyla birleştir
– 10 DNS lookup sınırını aşmadığını kontrol et
RFC tabanlı e-posta doğrulama mantığı bu konuda nettir: SPF çoklanırsa değerlendirme beklenmedik sonuç verebilir.
CDN açıkken DNS ve SSL uyumsuzluğu
DNS doğru görünür ama origin sertifikası, SNI veya proxy modu yüzünden site hata verir.
Çözüm:
– CDN proxy durumunu kontrol et
– Origin sertifikasının alan adı eşleşmesini denetle
– HTTP’den HTTPS’ye yönlendirmeyi çift katmanlı kurma
Yanlış DNSSEC yüzünden tam erişim kaybı
DS kaydı eski anahtarı işaretler ve çözümleyiciler alan adını doğrulayamaz.
Çözüm:
– DNSSEC durumunu sağlayıcı panelinde ve bağımsız kontrol araçlarında doğrula
– Geçici olarak DNSSEC kapatmayı ancak kontrollü şekilde düşün
– Registrar tarafındaki DS kaydını güncelle
Performansı ölçmeden iyi DNS kurduğunu anlayamazsın
DNS tarafında iyileştirme yaptıktan sonra ölçüm almak şarttır. Hissiyatla ilerlersen küçük gecikmeleri veya bölgesel sorunları kaçırırsın.
Bakman gereken metrikler:
– DNS lookup time
– Time to first byte
– Bölgesel uptime oranı
– NXDOMAIN ve SERVFAIL oranı
– E-posta teslim başarısı
– SSL yenileme ve doğrulama durumu
Araç tarafında şu yaklaşım işe yarar:
– Tarayıcı geliştirici araçlarıyla ilk bağlantı zamanlarını izle
– Komut satırında dig ya da nslookup ile kayıt doğrula
– Farklı ülkelerden çalışan izleme servisleriyle yanıt süresini karşılaştır
– E-posta test araçlarıyla SPF, DKIM, DMARC tutarlılığını kontrol et
Burada tek bir test noktasına güvenme. Türkiye’den hızlı açılan bir alan adı Avrupa’dan ya da ABD’den daha geç çözülebilir. Özellikle uluslararası ziyaretçi alan projelerde çok noktalı test şarttır. Hobi Time okurları için en faydalı yaklaşım da budur: bir ayar yaptıktan sonra önce doğrula, sonra kalıcılaştır.
Sıkça Sorulan Sorular
DNS ayarı site hızını gerçekten etkiler mi?
Evet. DNS, bağlantının ilk adımıdır. Kötü DNS kurgusu ilk yanıtı geciktirir ve özellikle mobil ağlarda fark daha belirgin olur.
TTL kaç olmalı?
Sabit yapı için çoğu projede 3600 saniye dengeli seçimdir. Taşıma veya test döneminde 300 saniye daha kullanışlıdır.
AAAA kaydını silmeli miyim?
IPv6 hizmetin yoksa yanlış AAAA kaydını tutma. Doğru yapı yoksa kaldırmak daha güvenlidir.
DNS yayılımı ne kadar sürer?
Teknik olarak anlık değişir ama önbellekler yüzünden kullanıcı tarafında saatler sürebilir. Süreyi en çok TTL etkiler.
MX kaydı olmadan site açılır mı?
Açılır. MX e-posta içindir. Web erişimi için A, AAAA, CNAME ve ilgili yönlendirmeler rol oynar.
DNSSEC zorunlu mu?
Zorunlu değil ama güvenlik açısından güçlü artıdır. Yalnız kurulumunu eksiksiz yapman gerekir.
En iyi DNS sağlayıcısı nasıl seçilir?
Anycast ağ, yüksek uptime, hızlı panel, net loglar, DNSSEC desteği ve güçlü kayıt yönetimi sunan sağlayıcıları tercih et.
Alan adında hangi kayıtların aktif olduğunu bugün kontrol ettin mi? İstersen önce yalnızca A, AAAA, CNAME, MX ve TXT kayıtlarını çıkar; ardından en çok karışan satırı yorumlarda paylaş, birlikte en doğru DNS düzenini netleştirelim.