AAAA Kaydı Nedir? IPv6 Geçişinde Ne İşe Yarar?
A kaydı bir domain'i IPv4 adresine bağlar. AAAA kaydı aynı işlevi IPv6 için yapar — ama bu teknik bir farktan çok daha fazlasını ifade eder. IPv6 geçişi olan altyapılarda AAAA kaydının nasıl yapılandırıldığı, hangi sırayla çözümlendiği ve A kaydıyla nasıl bir arada çalıştığı, doğru anlaşılmadan yapılan yapılandırmalardan kaynaklanan sorunların temel kaynağıdır.
İnternette IPv4 adres havuzunun tükenmesi 2011'de IANA düzeyinde kesinleşti. Bölgesel kayıt kurumları da sırasıyla bloklarını bitirdi. Bu noktadan itibaren IPv6, teorik bir "bir gün geçeceğiz" protokolü olmaktan çıkıp işlevsel altyapının zorunlu parçası haline geldi. Bugün büyük CDN sağlayıcıları, bulut platformları ve mobil ağlar zaten çift yığın ya da IPv6 öncelikli çalışıyor. AAAA kaydı bu geçişin DNS tarafındaki somut temelidir.
Bir kaydı DNS'e eklemek kolaydır. Ama AAAA kaydının A kaydıyla nasıl birlikte çalıştığını, resolver'ların hangi sırayla sorgu yapacağını ve CDN veya ters DNS gibi bağlamlarda nasıl farklı davranabileceğini kavramadan yapılan yapılandırmalar, bağlantı sorunlarını sessiz biçimde davet eder.
A kaydından farkı ve neden ayrı bir kayıt türü olduğu
DNS kayıt türleri, taşıdıkları veri yapısına göre tanımlanır. A kaydı bir IPv4 adresi taşır — 32 bitlik, noktalı dört sekizli format. AAAA kaydı ise 128 bitlik IPv6 adresi taşır. İsim benzerliği kasıtlıdır: AAAA, "dört A" değil, "A kaydının dört katı büyüklükte adres" anlamında yorumlanır; 32 × 4 = 128 bit.
Ayrı bir kayıt türü olmasının teknik nedeni, DNS mesaj formatının her RR (Resource Record) türünü farklı bir RDATA alanıyla tanımlamasıdır. IPv4 adresleri 4 baytlık sabit uzunlukta RDATA içerirken IPv6 adresleri 16 bayt ister. RFC 3596, AAAA kaydını tam olarak bu ayrımla standartlaştırdı. Aynı domain için hem A hem AAAA kaydı bulunabilir; bu ikisi birbirinin yerini almaz, birbirini tamamlar.
Pratikte önemli bir ayrım: bazı yazılarda "IPv6 A kaydı" ifadesine rastlayabilirsiniz. Teknik açıdan bu hatalıdır. A kaydı yalnızca IPv4 içindir; IPv6 adresini doğru kayıt türü olan AAAA olmadan bir A kaydına giremezsiniz — panel bunu zaten reddedecektir. İki kayıt türü arasındaki davranış farklarını daha geniş bir perspektiften ele almak için CNAME ve A kaydı farkları yazısı ek bağlam sunmaktadır.
IPv6 adres yapısı ve AAAA kaydının DNS'teki temsili
IPv6 adresi sekiz gruptan oluşur; her grup 16 bitlik dört onaltılık basamakla temsil edilir ve gruplar iki nokta üst üste ile ayrılır. Tam yazılımıyla bir IPv6 adresi şu biçimdedir:
2001:0db8:85a3:0000:0000:8a2e:0370:7334
Sıfırlardan oluşan ardışık gruplar :: ile kısaltılabilir, ancak bu kısaltma adres başına yalnızca bir kez kullanılabilir:
2001:db8::1
DNS zone dosyasında AAAA kaydı şu formatı alır:
@ IN AAAA 2001:db8:85a3::8a2e:370:7334
www IN AAAA 2001:db8:85a3::8a2e:370:7334
mail IN AAAA 2001:db8::25
Modern DNS panellerinde kısaltılmış ya da kısaltılmamış formu girebilirsiniz; resolver her iki formu da doğru şekilde işler. Kısaltılmamış tam formu girmek, insan hataları açısından daha güvenlidir çünkü hangi grupların sıfır olduğu açıkça görünür. Özellikle benzer görünen iki adresi karşılaştırırken tam format yanıltıcı olmayan netliği sağlar.
IPv6 adresinin TTL değeri A kaydının TTL'inden bağımsız olarak ayarlanabilir. Farklı sağlayıcıdan farklı propagation hızı bekliyorsanız, AAAA kaydına geçiş sırasında daha kısa TTL ile başlamak makul bir yaklaşımdır. TTL değeri optimizasyonu yazısında propagation ve önbellekleme dengesi ayrıntılı ele alınmaktadır.
Dual-stack yapılandırma: A ve AAAA birlikte nasıl çalışır?
Dual-stack, bir host'un hem IPv4 hem IPv6 ile erişilebilir olduğu yapıyı tanımlar. DNS tarafında bu, aynı domain adı için hem A hem AAAA kaydının aynı anda bulunması anlamına gelir:
example.com. 300 IN A 203.0.113.10
example.com. 300 IN AAAA 2001:db8::1
Bu yapıda bir resolver, her iki kaydı da döndürebilir. İstemci taraftaki karar mekanizması RFC 6724 (Default Address Selection) ile tanımlıdır ve işletim sistemleri bu kuralları uygular. Pratik davranış şudur: IPv6 bağlantısı mevcut olan istemciler genellikle AAAA kaydını tercih eder. IPv6 bağlantısı yoksa A kaydına düşer.
Ancak "IPv6 bağlantısı mevcut" ifadesi yanıltıcı olabilir. Bir istemcinin IPv6 adresi olması, yönlendirilmiş bir IPv6 bağlantısına sahip olduğu anlamına gelmez. Link-local adresi (fe80::/10 aralığında) olan ama ISP tarafından gerçek bir IPv6 rotası verilmemiş sistemler, AAAA kaydını çözümleyebilir ancak bağlantı kuramaz. Bu durumda Happy Eyeballs algoritması (RFC 8305) devreye girer: modern tarayıcılar IPv6 denemesini yaklaşık 250 ms bekler, başarısız olursa IPv4'e geçer. Kullanıcı büyük çoğunlukla bu geçişi fark etmez; ama bağlantı kurulurken gecikme eklenmiş olur.
Bu davranışı kontrol altında tutmanın yolu açıktır: AAAA kaydı yalnızca IPv6 yönlendirmesi gerçekten çalışıyorken yayına alınmalıdır. Test edilmemiş IPv6 altyapısına AAAA kaydı eklemek, belirli bir kullanıcı grubunun yavaş bağlanmasına ya da zaman zaman bağlanamamasına yol açabilir. Sorun aralıklı olduğu için teşhisi de güçleşir.
Yalnızca AAAA yeterli mi, ikisi birlikte mi gerekiyor?
Bu sorunun yanıtı büyük ölçüde servisin hedef kitlesine ve altyapının bağlamına bağlıdır.
Yalnızca AAAA kaydının yeterli olduğu durumlar mevcuttur: IPv6-only veri merkezlerine yönelik dahili servisler, IPv6 üzerinde çalışan konteyner ağları (bazı Kubernetes yapılandırmaları) ve IPv4 erişiminin zaten başka bir mekanizmayla — örneğin VPN veya NAT64 — sağlandığı özel ağlar bu kategoriye girer. Bu senaryolarda A kaydı tutmak gereksiz karmaşıklık ekler.
Genel erişime açık web siteleri ve API'ler için ise çift kayıt tutmak uzun süre daha güvenli yaklaşım olmayı sürdürecektir. E-posta sunucuları bu açıdan özellikle dikkat ister: bir MX kaydının işaret ettiği host yalnızca AAAA kaydı taşıyorsa, IPv4-only gönderen sunucular bu host'a bağlanamaz. Teslim edilemeyen mesajlar veya geçici hatalar sessiz biçimde oluşabilir. Mail altyapısı için çift yığın yapılandırması hem A hem AAAA tutmak anlamına gelir.
CDN arkasındaki origin sunucular için de benzer bir değerlendirme gerekir. CDN kendi dual-stack yapısını ziyaretçiye sunarken, CDN ile origin arasındaki iletişim origin'in ne desteklediğine göre şekillenir. Bazı CDN'ler origin'e her zaman IPv4 üzerinden bağlanırken bazıları AAAA kaydını tercih eder. Bu davranışı CDN yapılandırmanızdan bağımsız doğrulamak gerekir.
AAAA kaydı eklenirken dikkat edilmesi gerekenler
ISP ve ağ katmanı desteği: AAAA kaydı eklemek, sunucunun gerçekten bir IPv6 adresi aldığı ve bu adrese yönlendirme yapıldığı anlamına gelmez. Sunucu sağlayıcısının panelinde IPv6 adresi atanmış ve ağ arayüzünde etkin olmalıdır. Sunucuda ip -6 addr show komutuyla mevcut IPv6 adresleri görüntülenir; link-local adresler (fe80:: ile başlayanlar) harici erişim sağlamaz. Gerçek bir global unicast adresi (2000::/3 aralığında) yoksa AAAA kaydı yayına alınmamalıdır.
Ters DNS (PTR) kaydı: IPv6 için ters DNS, A kaydına kıyasla çok daha az otomatik işleyen bir süreçtir. IPv4'te pek çok barındırma sağlayıcısı PTR kaydını otomatik oluşturur; IPv6'da bu genellikle manuel olarak talep edilmesi ya da yapılandırılması gereken bir adımdır. E-posta gönderimi yapan sunucularda IPv6 üzerinden posta gönderilecekse PTR kaydının mevcut olmaması, alıcı taraftaki spam filtrelerinde ciddi sorunlara yol açar. Bu konuyu derinlemesine ele alan Reverse DNS ve PTR kaydı yazısı, mail altyapısı bağlamındaki ters DNS gereksinimlerini ayrıntılı açıklamaktadır.
IPv6 adresi atanmış bir sunucuya AAAA kaydı eklemeden önce güvenlik duvarı kurallarını gözden geçirin. Yalnızca IPv4 kuralları olan bir sunucuya AAAA kaydı eklenirse, IPv6 üzerinden gelen trafik mevcut güvenlik duvarı yapılandırmasını bypass edebilir. iptables kullanan sistemlerde IPv4 kuralları ip6tables'ı kapsamaz; her ikisinin de ayrıca yapılandırılması gerekir.
CDN davranışı: Cloudflare gibi CDN'ler, origin sunucunun IPv6 adresi olup olmadığına bakmaksızın ziyaretçilere IPv6 sunabilir. Proxy modda AAAA kaydı Cloudflare'ın kendi IPv6 adresini gösterir, asıl sunucu IP'si gizlenir. Ancak Cloudflare ile origin arasındaki bağlantı hâlâ IPv4 üzerinden çalışıyor olabilir. Bu ayrımın pratik sonuçlarını anlamak için Cloudflare Proxied ve DNS Only farkı yazısına bakabilirsiniz.
dig ve nslookup ile AAAA kaydını doğrulama
AAAA kaydını DNS'e ekledikten sonra doğrulamanın en hızlı yolu dig komutudur. Sorgu türü olarak AAAA belirtilmezse dig varsayılan olarak A kaydını sorgular; bu nedenle tür açıkça yazılmalıdır:
dig AAAA example.com
Beklenen çıktı ANSWER SECTION altında şuna benzer:
;; ANSWER SECTION:
example.com. 300 IN AAAA 2001:db8::1
Belirli bir resolver üzerinden sorgu yapmak veya yalnızca adres çıktısı almak için:
# Google DNS üzerinden sorgulama
dig AAAA example.com @8.8.8.8
# Yalnızca IPv6 adresi
dig AAAA example.com +short
# Hem A hem AAAA arka arkaya
dig A example.com +short
dig AAAA example.com +short
AAAA kaydı döndürülmüyorsa ve kaydı az önce eklediyseniz propagation henüz tamamlanmamış olabilir. Kaydın zone'a işlenip işlenmediğini anlamanın en güvenilir yolu, yetkili nameserver'a doğrudan sorgu yapmaktır:
# Önce nameserver'ı bul
dig NS example.com +short
# Yetkili nameserver'a doğrudan sor
dig AAAA example.com @ns1.example.com
Bu sorgudan AAAA kaydı dönüyorsa kayıt zone'a işlenmiş demektir; döndürülmüyorsa kayıt panelde hatalı girilmiş ya da henüz kaydedilmemiş olabilir. Windows ortamında nslookup tercih ediliyorsa:
nslookup -type=AAAA example.com
IPv6 bağlantısının sunucu tarafında gerçekten çalışıp çalışmadığını doğrulamak için DNS doğrulaması tek başına yeterli değildir. DNS kaydı doğru görünse de sunucu o adrese ulaşılamaz olabilir. curl -6 https://example.com komutu IPv6 üzerinden gerçek bir bağlantı denemesi yaparak uçtan uca çalışabilirliği test eder.
AAAA kaydı, DNS mekanizmasında A kaydının işlevsel karşılığıdır; ama IPv6'nın getirdiği ek katmanlar — ters DNS, dual-stack seçim mantığı, güvenlik duvarı davranışı — onu salt bir "IPv4 yerine IPv6 adresi gir" adımından farklı kılar. Bu katmanları anlamadan yapılan yapılandırmalar çoğunlukla yayına girdiği sırada sorun çıkarmaz; sorun, belirli ağ koşullarında veya belirli istemci türleriyle bağlantı kurulduğunda ortaya çıkar.
IPv6 geçişi hem altyapı hem DNS katmanında eş zamanlı hazırlık ister. Sunucu gerçek bir IPv6 adresiyle erişilebilir duruma getirilmeden AAAA kaydı yayına almak, bir grup kullanıcı için sessiz bir hız kaybına dönüşür. Önce altyapıyı doğrulayın, sonra kaydı ekleyin, ardından yetkili nameserver'a sorgu yaparak ve curl -6 ile uçtan uca testi tamamlayın — bu sıralama AAAA yapılandırmasındaki yaygın hataların büyük bölümünü önler.