{
“title”: “IPv6’ye Geçişin Sıcacık Yol Haritası: Dual‑Stack DNS, AAAA Kayıtları ve Gerçek Dünyada Test Etme”,
“content”: “
Hiç başınıza geldi mi? Ofiste sessiz sakin bir sabah, kahvenizi almışsınız, her şey rayında… Derken bir mesaj: ‘Bazı kullanıcılar sitede yavaşlık yaşıyor.’ İlk tepki hep aynıdır, sunucu mu sıkıştı, CDN mi nazlandı, yoksa DNS tarafında mı küçük bir pürüz var? O gün ben de aynı döngüden geçtim. Sonra aklıma düşen şu oldu: Geçen hafta AAAA kaydını açmıştım, belki de bazı ağlarda IPv6 yolu taşlıdır, tarayıcılar önce IPv6’yı deniyordur. Biraz iz sürünce mesele netleşti: Dual‑stack’e geçmiş olmanın avantajları kıymetliydi ama gerçek dünyada test etmeden düğmeye asıl basmamak gerekiyordu.
Bugün, IPv6’ye geçiş meselesini beraber, sıcak bir sohbet eşliğinde ele alalım istiyorum. Dual‑stack DNS mantığını konuşacağız, AAAA kayıtlarını nasıl ve ne zaman açmanın mantıklı olduğuna bakacağız. Nginx veya Apache’ye dokunmadan önce nelere göz atmalı, firewall ve loglarda neleri takip etmeli, onları paylaşacağım. Sonra da işin en hayati kısmı: Gerçek dünyada test etme. Kafede, evde, mobilde, kurumsal ağda; kısacası sitenizin kullanıcılarının gerçekten olduğu yerlerde nasıl emin adımlarla ilerlenir, onu anlatacağım. Hadi başlayalım, kahve benden.
Dual‑Stack’in Kalbi: DNS ve AAAA Kayıtları Ne Zaman, Nasıl?
IPv6’ye geçiş deyince kulağa sanki bir gecede büyük bir göç yapılacakmış gibi geliyor. Oysa işin sırrı, IPv4’ü kapatmadan önce ikisini yan yana, dostça koşturmakta. Adına dual‑stack diyoruz. Yani alan adınız için A ve AAAA kayıtları birlikte var oluyor. Tarayıcılar da ‘hangisi daha hızlıysa’ ona koşuyor. Pratikte, pek çok kullanıcı IPv6 üzerinden gelecek, bazıları IPv4’le bağlanacak. Ağ koşulları, operatör tercihleri, kurumsal politikalar derken o seçim kullanıcıya göre değişecek. Sizin yapmanız gereken, her iki yolu da açık tutmak ve DNS tarafını sade, net, tutarlı yönetmek.
Ben önce alan adımın kökü ve kritik alt alan adları için AAAA kayıtlarını açıyorum. ‘www’, ‘api’, ‘cdn’ gibi trafiğin asıl aktığı giriş noktaları. TTL’leri başta nispeten kısa tutmak iyi geliyor. Diyelim 300 ya da 600 saniye; sorun çıkarsa hızlıca geri alabilmek için. Bir de kendi ad sunucularınıza sahipseniz ve ‘ns1’ gibi bir kayıt açacaksanız, glue kayıtları ve IPv6 adreslerini eksik etmeyin. Bu kısım çok kıymetli, çünkü çözümleme zincirinin en dibinde o kayıtlar duruyor. Detayı daha önce toparlamıştım, isterseniz adım adım özel ad sunucusu ve glue record kurulumunu bu rehberde gözden geçirebilirsiniz.
Bir de şu sık soruluyor: ‘AAAA kaydı açınca bir anda herkes IPv6’dan gelmiyor mu?’ Hayır, işin güzel yanı bu. Kullanıcının cihazı, tarayıcısı ve bulunduğu ağ ne destekliyorsa ona göre akıyor trafik. Modern tarayıcılar, başta IPv6’yı yoklarken aynı anda IPv4’e de göz kırpıyor. Hızlı olan kazanıyor. Bu yüzden dual‑stack bir anda dünyayı tersyüz etmez; doğru testlerle çok güvenli bir geçiş yoludur.
Küçük bir bölümü örneklemek hoş olur. Diyelim alan adınız example.com. Alan adınızın DNS bölgesinde şu tarz bir akış görebilirsiniz:
; example.com zone
@ 600 IN A 192.0.2.10
@ 600 IN AAAA 2001:db8:abcd::10
www 600 IN A 192.0.2.10
www 600 IN AAAA 2001:db8:abcd::10
api 300 IN A 192.0.2.20
api 300 IN AAAA 2001:db8:abcd::20
Bu arada ters DNS (PTR) konusu da posta sunucuları için önemli. Web tarafında kritik değildir ama e‑posta gönderiyorsanız IPv6 PTR’ın da tutarlı olduğundan emin olun. Bazı e‑posta sağlayıcıları, yeni IPv6 aralıklarından gelen postaları daha sıkı süzebiliyor; geçişin ilk günlerinde, outbound mail’i IPv4’te tutmak bazen yeni başlayanlar için daha rahat oluyor. Bu bir zorunluluk değil, daha çok pratik bir not.
Sunucu Cephesi: Nginx/Apache, Firewall ve Logların Dili
DNS’i konuşturduk, sıra sunucuya geldi mi ilk durak ağ yapılandırması. Sağlayıcınız size en az bir IPv6 adresi verir. Kimi zaman bir /64 ağ da açılmış olur. Bu kısmı panelden eklemek kolay, bazen de işletim sistemi tarafını elle beslemek gerekir. Interface’e IPv6’yı ekledikten sonra ‘ping6’ ya da ‘ping -6’ ile dışarıyı yoklamak adetim. Sonra firewall’a bakıyorum; 80 ve 443 trafiğinin IPv6 tarafında da açık olduğundan emin olmak yetiyor. Ufw kullanıyorsanız kurallar genellikle IPv4 ve IPv6’yı bir arada kapsar, yine de ‘ufw status verbose’ ile çift kontrol iyidir.
Web sunucusunda yapılacaklar şaşırtıcı derecede basit. Nginx tarafında şuna benzer bir yapı bana güven veriyor:
server {
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.com www.example.com;
# Burada TLS ayarları, sertifikalar, vs.
# ssl_certificate ...;
# ssl_certificate_key ...;
location / {
proxy_pass http://127.0.0.1:8080;
}
}
Bu noktada performans ve güvenliğe dokunmak isterseniz, HTTP/2 ve hatta HTTP/3 tarafını açmanın da yolu var. Bunu yaparken ağ yığınınızdaki IPv6’yı da hesaba katmak güzel olur. Günün sonunda ziyaretçi için deneyimi hızlandırır. Detayı Nginx ve Cloudflare’da HTTP/2 ve HTTP/3 (QUIC) rehberinde adım adım anlatmıştım. Bir de TLS 1.3 tarafında küçük dokunuşlarınız varsa, IPv6 üzerinde de aynı pürüzsüzlüğü görmek için hızlı ve güvenli HTTPS rehberindeki önerileri yanınıza alın. İkisi birlikte çok sağlam bir temel atıyor.
Gelelim loglar ve gözlemlemeye. IPv6 adresleri uzun, evet, ama düzenli kalıplarla okumak kolaylaşıyor. Access log’da hem IPv4 hem IPv6 isabetlerini görmek, geçişin sağlığını anlamada harika bir gösterge. Belki kısa bir süre ‘geoip’ ya da benzeri bir çözümle v6 trafiğinin nereden geldiğini izlersiniz; çoğu zaman mobil ağlardan artan bir akış görürsünüz. Eğer bir CDN arkasındaysanız, gerçek istemci IP’sini doğru devretmek için proxy başlıklarını IPv6 ile uyumlu tuttuğunuzdan emin olun. Cloudflare, Fastly ya da benzeri bir CDN kullanıyorsanız, ‘real IP’ ayarlarının v6’yı da kapsaması gerekiyor.
Gerçek Dünyada Uyum Testleri: Kafede, Evde, Kurumsalda
Bir yapı lokalde kusursuz görünebilir ama kullanıcılarınızın olduğu ağlarda bambaşka davranabilir. Ben testleri hep küçük bir rota gibi planlarım. Önce mobil ağda bakarım. Bir cep telefonunun hücresel verisi çoğu zaman IPv6’yı erkenden dener; o yüzden gerçek kullanıcıların ayağına en yakın laboratuvar gibidir. Sonra ev internetimden yoklarım, özellikle CGNAT kullanan bağlantılar bazen farklı sürprizler çıkarır. Bir de mümkünse kurumsal bir ağdan bakmak, proxy ve güvenlik cihazlarının davranışlarını görmenizi sağlar. Hepsi küçük, günlük hayatta erişebileceğiniz adımlar.
Komut satırıyla hızlı testler için şunların yeri ayrı:
# AAAA kayıtlarını gör
dig AAAA example.com +short
# IPv6 üzerinden HTTP başlıklarını çek
curl -6 -I https://example.com
# Temel erişilebilirlik
ping -6 example.com
Tarayıcı tarafında ise ‘bu ağ beni dünyaya nasıl gösteriyor’ demek için en pratik çözümlerden biri test-ipv6.com sayfasını açmak. Dolaylı da olsa ‘Happy Eyeballs’ dediğimiz, tarayıcıların ‘kim hızlıysa oradan devam edeyim’ davranışının nasıl sonuç verdiğini gözlemlemiş olursunuz. Eğer özel bir URL’i doğrulamak isterseniz, IPv6 görünümlü doğrulayıcılar da bazen hızlı fikir verir. Doğrudan site değil de TLS yenileme ve otomasyon tarafında acaba IPv6 sorunsuz mu derseniz, Let’s Encrypt’in IPv6 desteği notları da içinize su serper.
Bu arada, IPv6‑only ortamlara da ucundan ben değmek isterim. Bazı sağlayıcılar tamamen IPv6’lı VPS’ler sunuyor, IPv4 dünyasına NAT64/DNS64 gibi köprülerle uzanıyorsunuz. Bu kulvarda yürüyecekseniz, DNS çözümlemesini ve dış erişimleri nasıl köprülediğinizi netleştirmek gerekir. Merak edenler için IPv6‑only bir VPS üzerinde NAT64/DNS64 ile köprü kurma hikayesini ayrı ele almıştım. Dual‑stack’ten farklı bir oyun bahçesi ama mantık güzel oturduğunda sürprizsiz gider.
Gerçek dünyadaki testlerin bir başka faydası, küçük kenar durumlarını yakalamak. Mesela bazı kurumsal güvenlik ürünleri, yanlış yapılandırılmışsa, AAAA kayıtlı ama IPv6’dan cevap vermeyen endpoint’lere daha agresif zaman aşımı uygulayabiliyor. Aynı şekilde, CDN arkasında alt alan adı IPv6’yı kapatırken ana alan açık kalırsa, beklenmedik bağlantı rotaları oluşabiliyor. Bu nedenle ‘küçük adımlarla aç, ölç, sonra büyüt’ yaklaşımı burada altın kural.
Yol Haritası: Güvenle Aç, Sorun Çıkarsa Zarifçe Geri Dön
Benim denediğim ve rahat ettiğim yol hep aynı. Önce sahte bir alan adı ya da test alt alanı üzerinde dual‑stack’i çalıştırıyorum. Üretim akışını etkilemeden bütün taşları dizerken insanın eli rahat oluyor. Sonra kritik olmayan bir alt alan için AAAA’yı açıyorum; diyelim ‘static’ ya da ‘img’ gibi. CDN varsa burada ufak bir trafik dilimini IPv6’ya yönlendirip ölçüyorum. Her şey yerli yerindeyse sıra ana siteye geliyor. TTL’leri başta kısa tutmak, bir terslikte dakikalar içinde düzeltme yapabilmeyi sağlıyor. Büyülü bir his, çünkü ‘geçtim’ demek yerine ‘kontrollü şekilde genişlettim’ diyorsunuz.
Bu sürecin görünmeyen kahramanı izleme. Dual‑stack açıldıktan sonra IPv6 için ayrı uçtan uca kontrol eklemek, içinizi rahatlatır. Ping değil, gerçek HTTP kontrolü, idealde anahtar sayfanın 200 dönmesi. Küçük bir js dosyasının yanıt süresini izlemek de güzel bir fikir. Bizim tarafta bunu anlatırken Uptime Kuma ve Grafana ile basit alarm kurulumunu örneklemiştim; IPv6 endpoint’i ayrı bir hedef olarak eklemek harika sonuç veriyor. İlk günlerde birkaç 4xx veya 5xx çıkarsa, grafikte izlersiniz, logla doğrularsınız, sorunu nokta atışı yakalarsınız.
Güvenlik tarafını da es geçmeyelim. Firewall kuralları tamam, ama uygulama katmanında IPv6’dan gelen istekleri farklı yorumlayan bir kural var mı, bakın. WAF kullanıyorsanız ve beyaz listeye aldığınız bir kaynak IP varsa, onun IPv6 karşılığına da göz kırpmayı unutmayın. CDN üzerinden TLS ayarlarınızı yaparken eğer ‘modern’ profil kullanıyorsanız, bunu IPv6 bağlantıları için de bire bir uygulamak iyi bir pratik. Cloudflare kullanıyorsanız, ağ sekmesinde IPv6’nın açık olduğunu doğrulamak ve QUIC ile birlikte test etmek performans algısını güçlendirir. Bu başlıkların çoğunu toparlarken TLS 1.3 ve modern şifreler rehberindeki öneriler yanımda dursun istiyorum; sürprizlere karşı güzel bir kalkan.
Son bir küçük numara da geri dönüş planı. AAAA’yı açtınız ve beklenmedik bir ağ parçası kullanıcılarınızın bir bölümünde dert çıkardı diyelim. Yapacağınız şey çok net: AAAA kaydını kaldırın, TTL’nin dolmasını beklerken CDN üzerinde IPv6’yı geçici kapatın, akışınız IPv4’te akmaya devam ederken teşhise odaklanın. Bu, ‘panik butonu’ gibi dursun. Çoğu zaman gerekmez, ama var olduğunu bilmek bile karar vermeyi kolaylaştırır.
Kapanış: IPv6 Dalgası Kıyınıza Nazikçe Vursun
Toparlayalım. IPv6’ye geçiş bir maraton değil, ritmi olan bir yürüyüş gibi. Dual‑stack ile başlamak hem güvenli hem de gerçekçi. DNS tarafında AAAA kayıtlarını dikkatle açıp kısa TTL’lerle başlayınca kontrol sizde oluyor. Sunucu tarafında Nginx ya da Apache’yi IPv6’yı dinleyecek şekilde ayarlamak birkaç satırlık iş. Firewall ve loglar gözünüzün önünde olursa, kalan her şey daha sakin akıyor. En kritik adımın test olduğunu söyleyip durdum; çünkü kafede, evde, mobilde bakmadan ‘tamamdır’ demek, bana hep eksik gelmiştir. Basit curl ve dig komutları, tarayıcı test sayfaları ve küçük bir izleme kurgusu ile bu iş çok daha az stresli hale geliyor.
İşin güzel yanı, bu geçiş sırasında performans ve güvenlik gibi konulara da dokunabiliyor olmanız. HTTP/2, HTTP/3, TLS 1.3 gibi kapıları açarken, ağın geleceğine ayak uydurmak moral veriyor. Eğer daha ileri adımlar düşünürseniz, IPv6‑only dünyasına köprü kurmak ya da özel ad sunucularınızı IPv6’ya taşımak gibi başlıklar için paylaştığım rehberler elinizin altında. Tüm bu yolculukta en çok işe yarayan şey ise sakin kalmak, küçük adımlarla ilerlemek ve ölçmek oldu. Umarım bu yazı, sizde de aynı güven duygusunu uyandırır. Sorularınız olursa yorumlara bırakın, birlikte bakalım. Bir dahaki yazıda görüşmek üzere; IPv6 dalgası kıyınıza nazikçe vursun, siz de keyfini sürün.
“,
“focus_keyword”: “IPv6’ye geçiş”,
“meta_description”: “IPv6’ye geçişi dual‑stack DNS ve AAAA kayıtlarıyla, gerçek dünyada uyumluluk testleri ve pratik ipuçlarıyla adım adım anlatıyorum; güvenle ilerleyin.”,
“faqs”: [
{
“question”: “AAAA kaydı eklersem siteye erişim bozulur mu?”,
“answer”: “Genelde hayır. Dual‑stack’te A ve AAAA yan yana çalışır. Tarayıcılar hızlı olan yolu seçer. Başta kısa TTL’lerle açıp gerçek dünyada test ederseniz risk iyice azalır.”
},
{
“question”: “IPv6 adresini nereden alırım ve tek IP yeterli mi?”,
“answer”: “VPS ya da barındırma sağlayıcınız IPv6 adresini verir. Çoğu senaryoda tek IPv6 adresi web için yeterlidir. Sağlayıcıdan bir /64 ağ da alabiliyorsanız ileride esneklik sağlar.”
},
{
“question”: “Gerçek dünyada testi nasıl yapmalıyım, hangi araçlarla?”,
“answer”: “Mobil ağ, ev interneti ve mümkünse kurumsal bir bağlantıdan bakın. Komut satırında dig ve curl ‑6 iş görür. Tarayıcıdan test‑ipv6.com gibi sayfalar da hızlı fikir verir.”
}
]
}
