DNS kayıtları ne anlatır?

DNS, ornek.com gibi insanların kullandığı adlarla internet servislerinin ihtiyaç duyduğu hedefler arasındaki dağıtık dizindir. Tarayıcının hangi sunucuya gideceğini, gelen e-postanın nereye teslim edileceğini ve bir hizmetin alan adı sahipliğini nasıl doğrulayacağını ayrı kayıtlar belirler. DNS’i doğru okumak için yalnızca kaydın değerine değil, ad, tür, TTL ve yetkili kaynağa birlikte bakmak gerekir.

Önce dört parçalı modeli anlayın

Bir DNS kaydı genellikle dört soruya cevap verir: Kayıt hangi ada ait, türü ne, değeri ne ve önbellekte ne kadar tutulabilir? Örneğin www.ornek.com. 300 IN A 192.0.2.10 satırı, www adının IPv4 hedefini ve 300 saniyelik TTL değerini gösterir. Sondaki nokta, adın tam nitelikli olduğunu belirtir; bazı yönetim panelleri bunu kullanıcıdan gizler.

Bir web sitesini DNS’e bağlama: adım adım

1. Hedefi barındırma sağlayıcısından alın.

   Sağlayıcı bir IPv4/IPv6 adresi veya hedef.saglayici.net gibi bir ad verir. Tahmin ederek IP girmeyin; paylaşımlı platformlar özel doğrulama da isteyebilir.

2. Kök ad ile www seçimini yapın.

   Kök alan adı için çoğunlukla A/AAAA, www için A/AAAA veya CNAME kullanılır. Standart DNS’te CNAME bulunan bir ad başka kayıtlarla birlikte kullanılamaz. Bazı sağlayıcıların “ALIAS”, “ANAME” ya da CNAME flattening özelliği DNS standardındaki ayrı bir kayıt türü değil, sağlayıcı uygulamasıdır.

3. Değişiklikten önce TTL’yi planlayın.

   Taşıma yaklaşırken eski kaydın TTL’sini önceden düşürmek geçişi hızlandırabilir. Çok düşük TTL sürekli ve gereksiz sorgu yükü yaratabileceği için kalıcı çözüm olmayabilir.

4. Hem yetkili cevabı hem kullanıcı yolunu test edin.

   Önce nameserver’ın yeni kaydı döndürdüğünü, sonra farklı çözümleyicilerin bunu gördüğünü kontrol edin. DNS doğru olsa bile HTTP yapılandırması, TLS sertifikası veya uygulama hatası siteyi kapalı gösterebilir.

5. Eski sistemi hemen kapatmayın.

   Önbelleklerde eski yanıt varken iki sunucunun da kısa süre çalışması kesintiyi azaltır. Ölçüm sonrası kullanılmayan kaydı ve sunucuyu kaldırın.

Buradaki @ işareti panelde kök alan adını temsil eder. MX satırındaki 10 bir “hız puanı” değil önceliktir; daha küçük değer önce denenir. Eşit öncelikli birden fazla MX yük paylaşımı veya yedeklilik için kullanılabilir. Posta hedefinin sonunda nokta kullanılmaması bazı panellerde alan adının iki kez eklenmesine yol açabileceğinden panelin biçimlendirme kuralı okunmalıdır.

SPF, DKIM ve DMARC birlikte nasıl çalışır?

Bu üç mekanizma aynı işi yapmaz. SPF, gönderen sunucunun alan adına göre yetkili olup olmadığını DNS’teki politika üzerinden kontrol eder. DKIM, mesajın seçili başlıklarını ve gövdesini özel anahtarla imzalar; alıcı, ilgili seçicide yayımlanan açık anahtarla imzayı doğrular. DMARC ise görünen “From” alanıyla SPF veya DKIM kimliği arasındaki hizalamayı değerlendirir ve başarısız mesajlar için politika bildirir.

1. Gönderim kaynaklarını envanterleyin.

   Kurumsal posta, web formu, bülten ve destek sistemi gibi her göndericiyi listeleyin. Unutulan bir hizmet sıkça teslimat sorunu yaratır.

2. Tek SPF kaydı oluşturun.

   Aynı ad üzerinde iki ayrı v=spf1 kaydı geçerli bir birleştirme yöntemi değildir. Gerekli kaynakları tek politika içinde tutun ve DNS sorgu sınırlarını hesaba katın.

3. DKIM’i sağlayıcı bazında etkinleştirin.

   Her hizmetin verdiği seçiciyi ve değeri tam kopyalayın. Anahtar döndürme sırasında eski ve yeni seçiciler bir süre birlikte bulunabilir.

4. DMARC’a gözlemle başlayın.

   Raporları okuyup meşru kaynakları düzelttikten sonra quarantine veya reject politikasına kademeli geçin. Hazırlıksız sert politika geçerli e-postaları engelleyebilir.

“DNS yayılımı” gerçekte nedir?

Değişiklik bütün internete tek merkezden itilmez. Özyinelemeli çözümleyiciler önceki cevabı TTL süresince önbellekte tutar; süre dolunca yetkili sunucudan yeniden sorar. Bu yüzden bir kullanıcı yeni IP’yi görürken diğeri eski IP’yi görebilir. “24–48 saat kesin beklenir” genellemesi her durum için doğru değildir: eski TTL, sağlayıcı önbelleği, delegasyon değişikliği ve istemci yazılımı süreyi etkiler.

Nameserver değişikliği sıradan bir A kaydı değişikliğinden daha fazla katman içerir. Üst bölgedeki delegasyon, varsa glue kayıtları ve yeni nameserver’daki bölge birbiriyle uyumlu olmalıdır. Alan Hattı DNS yayılım aracı farklı çözümleyicilerde görünen kayıtları karşılaştırmaya yardımcı olur; kesin kaynak için alan adının yetkili nameserver’ını ayrıca sorgulayın.

DNSSEC ne sağlar, ne sağlamaz?

DNSSEC, çözümleyicinin aldığı DNS verisinin yetkili kaynaktan geldiğini ve yolda değiştirilmediğini kriptografik olarak doğrulamasına yardım eder. Web trafiğini şifrelemez; bunun için HTTPS/TLS gerekir. Alan adı kayıt kuruluşundaki DS kaydı ile DNS sağlayıcısındaki imza anahtarları uyuşmazsa doğrulayan çözümleyiciler alan adını tamamen erişilemez görebilir.

Sağlayıcı değiştirirken DNSSEC’i plansız açıp kapatmak yerine yeni anahtar zincirini ve DS güncellemesini sağlayıcının yönergesine göre sıralayın. SERVFAIL yalnız DNSSEC demek değildir ama imza zinciri bozukluğu araştırılması gereken nedenlerden biridir.

Belirtiye göre hata ayıklama matrisi

Yayın öncesi kontrol listesi

• Kayıt adında alan adının panel tarafından otomatik eklenip eklenmediğini doğruladım.
• A ve AAAA hedeflerinin gerçekten çalışan sunuculara ait olduğunu test ettim.
• CNAME hedefinin IP değil alan adı olduğunu ve aynı adda çakışan kayıt bulunmadığını kontrol ettim.
• MX hedeflerinin çözüldüğünü ve posta kabul ettiğini doğruladım.
• Tek SPF politikası yayımladım; DKIM seçicisini ve DMARC hizalamasını test ettim.
• Taşıma öncesi TTL’yi planladım, eski sistemi önbellek süresi boyunca erişilebilir tuttum.
• DNSSEC kullanıyorsam DS–anahtar zincirini doğruladım.
• Değişiklikleri, tarihi ve geri dönüş planını kaydettim.