IPv6 AAAA Kaydı Nedir, Eklemeli miyim? Bozmadan IPv6 DNS

AAAA kaydı, bir sunucu adını IPv6 adresine bağlayan DNS kaydıdır. Eklemeli misiniz? Yalnızca adın arkasındaki hizmet IPv6 üzerinden uçtan uca gerçekten çalışıyorsa: adres, dinleyen servis, güvenlik duvarı, TLS, uygulama. Doğru bir AAAA kaydı sitenizi yalnızca IPv6 kullanan ya da IPv6'yı tercih eden ağlar için erişilebilir kılar. Yanlış bir AAAA kaydı ise hiç olmamasından kötüdür; ziyaretçilerin bir kısmını yanıt vermeyen bir adrese gönderir ve hatalar rastgele görünür. AAAA kaydının olmaması hata değildir: ad yalnızca IPv4 ile çalışır, o kadar.

AAAA kaydı nedir?

AAAA kaydı (RFC 3596; "dört A" diye okunur) bir sunucu adını 128 bitlik IPv6 adresine eşler; A kaydının IPv4 için yaptığının aynısıdır. İki protokolü birlikte kullanan (dual-stack) bir sunucu ikisini de yayınlar:

www.example.com.   300   IN   A      192.0.2.10
www.example.com.   300   IN   AAAA   2001:db8:10::10

İki kayıt birbirinden bağımsızdır. Onları eşzamanlı tutan hiçbir şey yoktur: farklı makineleri gösterebilirler, biri güncellenirken diğeri unutulabilir. Bu yazıda anlatılanların çoğu buradan çıkar.

$ dig +short AAAA example.com
2001:db8:10::10

İstemci hangisini seçer? Happy Eyeballs

Dual-stack istemci hem A hem AAAA sorgular. İkisini de alırsa IPv6'yı tercih eder. IPv6 adresi yanıt vermediğinde ne olacağı istemciye bağlıdır.

Tarayıcılar ve güncel işletim sistemi kitaplıkları Happy Eyeballs yöntemini (RFC 8305) uygular: önce IPv6 bağlantısını başlatır, kısa bir gecikmenin (RFC'nin önerdiği değer 250 ms) sonunda bağlantı kurulmadıysa paralel olarak IPv4 denemesini de başlatır ve hangisi önce bağlanırsa onu kullanır. Ziyaretçi hiçbir şey fark etmez.

Bozuk bir AAAA kaydının aylarca yaşayabilmesinin nedeni budur: tarayıcılar onu maskeler. Birçok başka istemci ise maskelemez:

• betikler ve komut satırı araçları, API istemcileri, başka hizmetlerden gelen webhook çağrıları;
• eski HTTP kitaplıkları ve dil çalışma ortamları;
• izleme (monitoring) sondaları;
• bazı posta yazılımları.

Bunlar IPv6 adresini dener, IPv4'e geçmeden önce bağlantı zaman aşımının tamamını (çoğu zaman onlarca saniye) bekler ya da doğrudan hata verir. Tipik belirti şudur: "Site tarayıcıda sorunsuz, ama ödeme sağlayıcısının geri çağrısı zaman aşımına uğruyor."

AAAA kaydı eklemeden önce: kontrol listesi

1. Sunucunun küresel bir IPv6 adresi var. ip -6 addr show scope global bir adres göstermelidir; fe80: ile başlayan adres yerel bağlantı (link-local) adresidir, sayılmaz. Değişebilecek otomatik üretilmiş bir adres yerine sabit adres kullanın.
2. Servis IPv6'da dinliyor. ss -tlnp çıktısında yalnızca 0.0.0.0:443 değil, [::]:443 ya da *:443 arayın. Sunduğunuz her portu kontrol edin: 80, 443 ve aynı adın arkasındaki diğerleri.
3. Güvenlik duvarı kuralları IPv6 için de yazılmış. IPv4 ve IPv6 kural kümeleri çoğu zaman ayrıdır; bulut sağlayıcısındaki güvenlik grubuna da IPv6 satırları gerekir. ICMPv6'yı toptan engellemeyin: IPv6, komşu keşfi (neighbour discovery) ve yol MTU keşfi için ona ihtiyaç duyar; engellendiğinde bağlantılar açılır, sonra takılır.
4. IPv6'da doğru site yanıt veriyor. TLS sanal sunucusu (vhost) v6 dinleyicisi için de tanımlı olmalıdır; yoksa ziyaretçi varsayılan siteyi ve başka bir ada ait sertifikayı görür.
5. Uygulama IPv6 adreslerini anlıyor. Log ayrıştırıcıları, hız sınırlayıcılar, izin listeleri, coğrafi kurallar, dolandırıcılık kontrolleri ve 255.255.255.255 uzunluğuna göre boyutlandırılmış veritabanı sütunları gözden geçirilmelidir. Yönetim paneli için IPv6 satırı olmayan bir IP izin listesi, IPv6 ağındaki yöneticiyi dışarıda bırakır.
6. İzleme iki protokolü de kapsıyor. Yalnızca IPv4 kullanan kontrol, IPv6 çökmüşken yeşil kalır.
7. Düşük bir TTL ile başlayın (örneğin 300 saniye); gerekirse kaydı hızla kaldırabilirsiniz. Birkaç sorunsuz günden sonra yükseltin. Asıl belirleyici olanın neden eski değer olduğunu DNS TTL nedir yazısı anlatıyor.

Ardından her protokolü ayrı ayrı test edin; tarayıcının gizleyeceği şeyi görmenin tek yolu budur:

$ curl -6 -sI https://example.com
HTTP/2 200
$ curl -4 -sI https://example.com
HTTP/2 200
$ ping -6 example.com        # eski sistemlerde ping6

İki curl çağrısı da aynı durum kodunu ve aynı siteyi döndürmelidir. Komutları kendi ağınızın dışındaki bir makineden çalıştırın; bilgisayarınızda IPv6 yoksa başka yerdeki bir sunucu iş görür.

CDN ya da proxy arkasındaysanız

Ad bir CDN ya da proxy platformuna CNAME ise IPv6 işi uçta çözülür: AAAA kayıtlarını sağlayıcının hedef sunucu adı yayınlar, ziyaretçi uç sunucuya IPv6 ile bağlanır, uç sunucu da kaynak sunucunuzla onun desteklediği protokol üzerinden (yalnızca IPv4 dahil) konuşur. AAAA kaydını siz eklemezsiniz; ekleyemezsiniz de, çünkü CNAME aynı adda başka kayda izin vermez. Yalnızca IPv4'ü olan bir kaynak sunucudan IPv6 ziyaretçilerine hizmet vermenin en kolay yolu budur. Geçerliliğini koruyan nokta: uygulamanız, iletilen adres başlığında ziyaretçinin IPv6 adresini görür; kontrol listesinin 5. maddesi yine gündemdedir.

Klasik hata senaryoları

Belirti	Olası neden	Kontrol
Sunucu taşındıktan sonra bazı ziyaretçiler hâlâ eski siteye ulaşıyor; hiç bitmeyen bir "DNS yayılması" gibi görünüyor	A kaydı güncellendi, eski AAAA kaydı unutuldu	dig +short AAAA example.com; yeni sunucunun adresiyle karşılaştırın
Tarayıcıda sorun yok; betikler, webhook'lar ya da izleme zaman aşımına uğruyor	AAAA, güvenlik duvarının paketleri sessizce düşürdüğü bir adresi gösteriyor	dışarıdan curl -6 -sI https://example.com
Yalnızca bazı ziyaretçilerde sertifika uyarısı ya da yanlış site	IPv6 dinleyicisinde eşleşen vhost yok	curl -6 -sv https://example.com, sertifikadaki ada bakın
Site çalıştığı halde sertifika yenilemesi başarısız	AAAA kaydı varken ACME doğrulayıcısı IPv6 ile bağlanabilir ve bozuk ya da farklı bir sunucuya ulaşır	curl -6 -sI http://example.com/.well-known/acme-challenge/test
IPv6'da büyük sayfalar takılıyor, küçükler açılıyor	ICMPv6 engelli, yol MTU keşfi çalışmıyor	güvenlik duvarında ICMPv6 "packet too big" kuralı
Yönetim paneli ya da API meşru kullanıcıları reddediyor	İzin listesi ya da hız sınırlayıcı yalnızca IPv4 biliyor	uygulama loglarındaki IPv6 istemci adresleri
Giden postayı büyük sağlayıcılar reddediyor	Sunucu, PTR ve SPF kapsamı olmadan IPv6 üzerinden gönderiyor	sonraki bölüm

İlk satırın altını çizmek gerekir. Taşıma yaparken AAAA'yı A ile aynı kontrol listesine yazın; ayrıntısı kesintisiz nameserver değişikliği yazısındadır. Yeni sunucuda IPv6 yoksa AAAA kaydını bırakmayın, silin.

IPv6 ve e-posta

IPv6 hatalarının en pahalıya patladığı yer e-postadır. Küresel IPv6 adresi olan bir posta sunucusu, alıcı taraf MX sunucuları için AAAA kaydı yayınladığında, siz planlamış olsanız da olmasanız da giden bağlantılarda çoğu zaman bu adresi kullanır. Büyük alıcılar IPv6 göndericilerine karşı katı davranma eğilimindedir. IPv6 adresi için gerekenler:

• bir PTR kaydı; adresi sağlayan kurum tanımlar, ayrıntısı reverse DNS ve PTR kaydı yazısında;
• PTR'ın gösterdiği sunucu adı için eşleşen bir AAAA kaydı; ileri ve ters kayıt birbirini tutmalı;
• SPF kaydınızda ip6: mekanizmasıyla bu adres ya da önek.

$ dig +short -x 2001:db8:10::25
mail.example.com.
$ dig +short AAAA mail.example.com
2001:db8:10::25
$ dig +short TXT example.com
"v=spf1 ip4:192.0.2.25 ip6:2001:db8:10::25 -all"

IPv6 adresi için PTR tanımlatamıyorsanız posta sunucusunu yalnızca IPv4 üzerinden gönderecek biçimde ayarlayın. Bu meşru ve yaygın bir tercihtir; IPv6 üzerinden posta almak açık kalabilir.

Sık yapılan hatalar

• Bir kontrol listesi ya da tarama aracı yokluğunu sorun saydı diye, IPv6 bağlantısını test etmeden AAAA eklemek.
• Yalnızca tarayıcıda test etmek. Happy Eyeballs size her şeyin yolunda olduğunu söyler.
• Adresi, küresel, sabit ve yönlendirilmiş olup olmadığına bakmadan sunucudan kopyalamak.
• Taşınmadan sonra önceki hosting firmasının AAAA kaydını zone'da bırakmak.
• IPv4 güvenlik duvarı kurallarının hiçbirini IPv6'ya taşımamak; sonuç iki yönde de kötüdür: kapalı bir web portu ya da yalnızca IPv6'da bütün dünyaya açık bir veritabanı portu.
• IPv4 alışkanlığıyla bütün ICMPv6'yı engellemek.
• SPF'te ip6: mekanizmasını ve posta sunucusunun IPv6 adresi için PTR'ı unutmak.
• AAAA'yı www için yayınlayıp kök alan adı için yayınlamamak (ya da tersi), sonra ağa göre farklı davranan yönlendirmeleri ayıklamaya çalışmak.

OrbitProbe ile kontrol edin

OrbitProbe DNS sorgulama aracı bir sunucu adının A ve AAAA kayıtlarını TTL değerleriyle yan yana, herkese açık çözümleyicilerin o anda döndürdüğü haliyle gösterir. Her sunucu taşımasından sonra çalıştırın: beklemediğiniz ya da hâlâ önceki sağlayıcının önekini taşıyan bir AAAA kaydı, yukarıdaki tablodaki unutulmuş kayıttır. Kök alan adı, www ve posta sunucusu adı için ayrı ayrı sorgulayın; her adın kendi kayıtları vardır. Bütün kayıt türlerinin özeti DNS kayıt türleri yazısındadır.