A Kaydı Nedir? IPv4 Adresi Yönlendirmesi

Alan adınızı bir IP adresine bağlayan kayıt A kaydıdır. Tarayıcı seodenetim.com adresine gitmek istediğinde sorduğu ilk şey budur: bu domain hangi IP'de? A kaydı bu soruyu yanıtlar ve bağlantı kurulur.

DNS'in diğer kayıt türleri e-posta akışını, domain doğrulamayı veya farklı alt domainleri yönetir. Ancak web sitesinin hangi sunucuya yönleneceğini yalnızca A kaydı belirler. Bu yüzden A kaydı eksik ya da yanlış olduğunda, diğer her şey doğru çalışıyor olsa bile site erişilemez hale gelir.

DNS kayıt türlerini genel olarak ele aldığımız yazıda MX, TXT, CNAME ve NS kayıtlarının ne işe yaradığını incelemiştik. Bu yazı A kaydına özelinde giriyor: nasıl yapılandırılır, ne zaman yetersiz kalır, değiştirilirken nelere dikkat edilir.

Alan adından sunucuya giden yol

Bir kullanıcı tarayıcıya ornek.com yazdığında süreç şöyle işler: tarayıcı önce yerel DNS önbelleğine bakar, bulamazsa recursive resolver'a sorar. Resolver sırasıyla kök DNS sunucularına, TLD name server'larına ve authoritative name server'a ulaşır. Son aşamada A kaydı devreye girer.

A kaydının yapısı şudur: bir hostname, bir TTL değeri ve bir IPv4 adresi.

ornek.com.    3600    IN    A    185.230.63.107

Burada 3600 saniye cinsinden TTL'dir; resolver bu yanıtı 1 saat boyunca önbellekte tutar. Süre dolana kadar aynı sorgu yeniden yapılmaz. Bu detay sonraki bölümde önem kazanır.

AAAA kaydı ise aynı işlevi IPv6 adresleri için görür. İkisi birlikte tanımlandığında tarayıcı genellikle IPv6'yı önce dener; başarısız olursa IPv4'e geçer. Bu mekanizma "Happy Eyeballs" olarak bilinir. Pratikte çoğu barındırma altyapısı hâlâ A kaydı üzerinden çalışır, ancak IPv6 desteği artmaktadır.

A kaydı yapılandırması: root, subdomain ve wildcard

Bir domain için üç farklı A kaydı türü söz konusudur.

Root domain (apex): @ işaretiyle temsil edilir. ornek.com'un kendisi için yazılan A kaydıdır. Bazı DNS sağlayıcıları bu işareti desteklerken bazıları root domain için yalnızca A kaydını kabul eder — CNAME'e izin vermez. Bu sınırlama RFC 1912'den kaynaklanır; root domain'de MX ve SOA kayıtları da bulunur, CNAME bunlarla çakışır.

Subdomain: www, api, mail gibi hostname'ler ayrı A kayıtları olarak tanımlanır. www.ornek.com ile ornek.com aynı IP'ye işaret edebilir ya da farklı sunuculara yönlenebilir — her biri bağımsız bir kayıttır. Bu esneklik subdomain tabanlı mimari için avantaj sağlar.

Wildcard: *.ornek.com formatında tanımlanan wildcard kaydı, eşleşmeyen tüm subdomainleri tek IP'ye yönlendirir. Dinamik subdomain üreten uygulamalarda yaygındır. Ancak her subdomainin ayrı sertifika gerektirdiği ortamlarda yönetim karmaşıklığı artar; wildcard SSL sertifikası bu sorunu çözer ama her sağlayıcı her yapılandırmayı desteklemez.

A kaydı mı, CNAME mi?

A kaydı bir hostname'i doğrudan IPv4 adresine bağlar. CNAME ise bir hostname'i başka bir hostname'e yönlendirir — IP'yi o kaynaktan devralır.

Pratik fark şudur: sunucu IP'si değiştiğinde, A kaydı her subdomain için tek tek güncellenmelidir. CNAME kullanılıyorsa yalnızca hedef A kaydı güncellenir; diğerleri otomatik takip eder. Bu nedenle CDN veya Load Balancer arkasındaki subdomainler çoğunlukla CNAME üzerinden yönetilir.

Ama CNAME'in kısıtı açıktır: root domain için kullanılamaz. Bazı sağlayıcılar "CNAME Flattening" veya "ALIAS" kaydı sunarak bu engeli aşar — arka planda A kaydına çözümlenirken dışarıya CNAME gibi davranır. Bu özellik yoksa root için A kaydından başka seçenek kalmaz.

Karar çerçevesi şudur: IP büyük olasılıkla değişecekse ve birden fazla subdomain aynı hedefe işaret ediyorsa CNAME tercih edilir. IP sabit ve subdomain sayısı azsa A kaydı yeterlidir. Hangisinin kullanıldığını ve hangi değerleri döndürdüğünü alan adının DNS kayıtlarını anlık olarak sorgulamak için DNS Lookup aracıyla kontrol edebilirsiniz.

Birden fazla A kaydı: yük dağıtımı ve basit yedeklilik

Aynı hostname için birden fazla A kaydı tanımlanabilir. Resolver bu durumda round-robin uygular — kayıtları sırayla döndürür.

ornek.com.    300    IN    A    185.230.63.10
ornek.com.    300    IN    A    185.230.63.11
ornek.com.    300    IN    A    185.230.63.12

Bu yönteme DNS round-robin denir. Gerçek bir yük dengeleyici değildir — sunucu sağlığını kontrol etmez, yük durumunu bilmez, bir sunucu çöktüğünde trafiği otomatik olarak başka yere yönlendirmez. Bunun için health-check destekli DNS sağlayıcısı veya gerçek bir load balancer gerekir.

Round-robin'in en büyük sorunu resolver önbelleğidir. Kullanıcının DNS önbelleğinde bir IP sabitlendiğinde, o IP çevrimdışı olsa bile kullanıcı aynı adrese gitmeye devam eder. TTL değerini düşük tutmak bu pencereyi kısaltır, ancak sorgu hacmini artırır.

TTL değerini değiştirmeden önce

TTL (Time To Live), resolver'ın DNS yanıtını önbellekte tutacağı süreyi saniye cinsinden belirler.

Yaygın değerler ve kullanım bağlamı şöyledir:

• 86400 saniye (24 saat): Değişmeyecek, statik hostname'ler için. Sorgu yükünü en aza indirir.
• 3600 saniye (1 saat): Standart yapılandırma. Çoğu hostname için makul denge.
• 300 saniye (5 dakika): Yakında değiştirilecek kayıtlara geçiş öncesi indirilir.

A kaydını değiştirmeden önce TTL'yi düşürmek standart bir önlemdir. TTL 3600'deyken kaydı değiştirirseniz, eski IP bazı resolver'larda 1 saat daha geçerli kalabilir. TTL'yi önceden 300'e indirirseniz, değişiklik en fazla 5 dakika içinde yayılır.

Dikkat edilmesi gereken nokta şudur: TTL değişikliğinin kendisi de o anki TTL süresi kadar yayılma süresi gerektirir. Örneğin TTL 3600 durumdayken 300'e indirirseniz, bu değişikliğin tüm resolver'lara ulaşması 1 saat alır. Dolayısıyla planlamayı değişiklikten en az mevcut TTL süresi kadar önce başlatmak gerekir.

Sık yapılan yapılandırma hataları

Eski IP bırakılması: Eski sunucudan yeni sunucuya geçiş sonrası eski A kaydı silinmeden bırakılırsa, DNS round-robin modunda eski sunucuya trafik gitmeye devam eder. Geçiş tamamlandıktan sonra gereksiz A kayıtlarını kaldırmak önemlidir.

Root ve www farklı IP'ye işaret ediyor: ornek.com ve www.ornek.com farklı A kayıtlarıyla farklı sunuculara yönlendirildiğinde TLS sertifikası sorunları ortaya çıkabilir. Sertifikanın hangi domainleri kapsadığını kontrol etmek için SSL Sertifika Kontrol aracı bu yapılandırmayı doğrulamaya yardımcı olur.

Wildcard ve özel subdomain çakışması: *.ornek.com ile api.ornek.com aynı anda tanımlıysa, özel kayıt öncelik alır. Bu davranış DNS sağlayıcısından sağlayıcıya değişebilir; belgelenmeden değiştirilemez.

Bakım süresi dolmuş domain: A kaydı doğru olsa bile domain yenilenmemişse sorgular authoritative name server'a ulaşamaz. Domain bitiş tarihini ve kayıt bilgilerini düzenli aralıklarla kontrol etmek bu riski erken görünür kılar.

A kaydı DNS'in en temel yapı taşıdır. Yapısı basit, ama yanlış yapılandırılması veya göz ardı edilmesi ciddi erişim sorunlarına yol açar. TTL'yi değişiklikten önce ayarlamak, eski kayıtları temizlemek ve root/subdomain ayrımını net tutmak; hem geçiş sürecini pürüzsüzleştirir hem de olası kesintilerin kapsamını daraltır.