- Katılım
- 21 May 2023
- Mesajlar
- 496
- Tepki
- 17
- Puan
- 18
Site ev internetinde açılıyor ama mobil veride zaman aşımına uğruyor; başka bir kullanıcıda ise bunun tam tersi oluyor. Böyle bir belirti, “DNS henüz yayılmadı” cümlesinden daha fazla araştırma ister. A ve AAAA kayıtları, IPv4/IPv6 rotası, güvenlik duvarı, TLS ve CDN katmanı birbirinden ayrılmadan yapılan değişiklik sorunu büyütebilir.
AAAA kaydı güçlü bir şüpheli olabilir, fakat tek olasılık değildir. Hedef, kaydı hemen silmek değil; aynı adresin iki IP ailesindeki davranışını kanıtla karşılaştırmaktır.
“Bazı kişiler giremiyor” yerine tek satırlık test kaydı tutun: tam URL, tarih-saat, cihaz, işletim sistemi, tarayıcı, kullanılan ağ, VPN/özel DNS durumu ve görülen hata. Aynı cihazda Wi-Fi ile mobil veri arasında geçiş yapmak, cihaz farkını ağ farkından ayırmaya yardım eder.
Ana alan adı ile
IETF RFC 3596, AAAA kaydının tek bir 128 bit IPv6 adresi taşıdığını belirtir. A kaydı alan adını IPv4 adresine, AAAA ise IPv6 adresine eşler. Her ikisi yayımlanmışsa çift yığın destekli istemci bağlantı kurarken iki aileden adresleri değerlendirebilir.
DNS cevabının bulunması, 443 numaralı portta çalışan web hizmetinin ve o adrese giden rotanın sağlıklı olduğunu kanıtlamaz. Yazım hatalı ama biçim olarak geçerli bir IPv6 adresi, eski sunucu adresi, eksik güvenlik duvarı kuralı veya yalnız IPv4'te dinleyen servis; AAAA sorgusunu başarılı, web bağlantısını başarısız bırakabilir.
Ardından herkese açık bir çözümleyiciyle karşılaştırma yapılabilir. Google Public DNS’in resmî JSON API belgesi,
Buradaki
Doğrulama notu: Bu komutlar 16 Ağustos 2026'da
Testi mümkünse hem sorun yaşayan ağda hem de çalışan bir kontrol ağında aynı URL ile yapın.
Sonucu şöyle okuyun:
Bu yazı hazırlanırken aynı
Modern istemciler çoğu zaman tek bir adrese sırayla bağlanmak yerine IPv6 ve IPv4 adaylarını kısa aralıklarla dener. IETF RFC 8305 bu yaklaşımı Happy Eyeballs olarak tanımlar. Amaç, bir adres ailesi engelli veya bozuk olduğunda kullanıcıya yansıyan gecikmeyi azaltmaktır.
Aynı RFC, geçerli görünen fakat olağan portlarda yanıt vermeyen bozuk AAAA kayıtlarının yazım hatası, rota kara deliği veya hizmet kesintisi gibi nedenlerle oluşabileceğini de açıklar. Bir tarayıcı hızla IPv4'e dönerken başka bir uygulama daha uzun bekleyebilir; IPv6 ağırlıklı ağ ise hatayı doğrudan gösterebilir. Bu nedenle “Bende açılıyor” cevabı yapılandırmanın doğru olduğunu kanıtlamaz.
İstemcilerde IPv6'yı topluca kapatmak site tarafı çözüm değildir; yalnızca belirtiyi saklayabilir ve IPv6 ağırlıklı kullanıcıları dışarıda bırakabilir. Önce hatalı ilanı ya da bağlantı yolunu düzeltin.
A ile AAAA'yı ayrı sorgulayın, IPv4 ile IPv6 web isteğini ayrı çalıştırın, sonucu iki ağda karşılaştırın. Sorunu paylaşırken alan adını yazabiliyorsanız A/AAAA çıktısını, curl hata kodunu ve hangi ağda görüldüğünü ekleyin; gizli origin IP veya panel bilgisini paylaşmayın.
Güncelleme: 16 Ağustos 2026. Komut çıktıları ağ, DNS önbelleği ve sağlayıcı yapılandırmasına göre değişir; kayıt düzenlemeden önce mevcut değerleri yedekleyin.
AAAA kaydı güçlü bir şüpheli olabilir, fakat tek olasılık değildir. Hedef, kaydı hemen silmek değil; aynı adresin iki IP ailesindeki davranışını kanıtla karşılaştırmaktır.
Önce belirtinin sınırını kaydedin
“Bazı kişiler giremiyor” yerine tek satırlık test kaydı tutun: tam URL, tarih-saat, cihaz, işletim sistemi, tarayıcı, kullanılan ağ, VPN/özel DNS durumu ve görülen hata. Aynı cihazda Wi-Fi ile mobil veri arasında geçiş yapmak, cihaz farkını ağ farkından ayırmaya yardım eder.
Ana alan adı ile
www adresini ayrı deneyin. Sorun yalnız bir alt alandaysa onun A, AAAA, CNAME, sertifika ve proxy ayarı farklı olabilir. Hata ekranının görüntüsünü alın; fakat IP, panel adresi veya erişim anahtarı gibi hassas bilgileri herkese açık mesaja koymayın.AAAA kaydı tam olarak neyi gösterir?
IETF RFC 3596, AAAA kaydının tek bir 128 bit IPv6 adresi taşıdığını belirtir. A kaydı alan adını IPv4 adresine, AAAA ise IPv6 adresine eşler. Her ikisi yayımlanmışsa çift yığın destekli istemci bağlantı kurarken iki aileden adresleri değerlendirebilir.
DNS cevabının bulunması, 443 numaralı portta çalışan web hizmetinin ve o adrese giden rotanın sağlıklı olduğunu kanıtlamaz. Yazım hatalı ama biçim olarak geçerli bir IPv6 adresi, eski sunucu adresi, eksik güvenlik duvarı kuralı veya yalnız IPv4'te dinleyen servis; AAAA sorgusunu başarılı, web bağlantısını başarısız bırakabilir.
Teşhis kuralı' Alıntı:
A ve AAAA cevaplarını ayrı sorgulayın
dig bulunan bir sistemde önce yerel ağın kullandığı çözümleyiciyi sorgulayın:
Bash:
dig +short A example.com
dig +short AAAA example.comArdından herkese açık bir çözümleyiciyle karşılaştırma yapılabilir. Google Public DNS’in resmî JSON API belgesi,
name ve type parametreleriyle A veya AAAA sorgusunu destekler:
Bash:
curl -sS 'https://dns.google/resolve?name=example.com&type=A'
curl -sS 'https://dns.google/resolve?name=example.com&type=AAAA'Buradaki
Status: 0 DNS açısından NOERROR demektir; Answer dizisi kayıtları ve TTL değerlerini gösterir. Ancak dışarıdaki bir DoH sorgusu, sorun yaşayan ağın aynı cevabı aldığını veya IPv6 hedefe erişebildiğini kanıtlamaz. Yerel sonuçla karşılaştırma içindir.Doğrulama notu: Bu komutlar 16 Ağustos 2026'da
www.google.com için A ve AAAA sorgularıyla çalıştırıldı; iki sorgu da Status 0 döndürdü. Adresler ve TTL değişken olduğu için çıktılar yazıya sabitlenmedi.Web isteğini IPv4 ve IPv6'ya zorlayın
Testi mümkünse hem sorun yaşayan ağda hem de çalışan bir kontrol ağında aynı URL ile yapın.
curl için aşağıdaki iki ayrıntılı GET isteği, bağlanılan adresi, TLS akışını ve HTTP cevabını ayrı gösterir:
Bash:
curl -4 -v -o /dev/null --max-time 15 \
'https://example.com/'
curl -6 -v -o /dev/null --max-time 15 \
'https://example.com/'Sonucu şöyle okuyun:
- IPv4 başarılı, IPv6 her ağda başarısız: AAAA adresi, IPv6 rotası, 443 güvenlik kuralı, servis dinleme adresi ve TLS yapılandırmasını denetleyin.
- IPv6 yalnız belirli ağda başarısız: Önce istemcide global IPv6 rotası bulunduğunu ve bilinen çalışan bir IPv6 hedefe erişilebildiğini doğrulayın; ardından operatör rotası, peering, yerel güvenlik ürünü veya VPN/özel DNS farkını araştırın. Tek başına DNS kaydını suçlamayın.
- İki aile de bağlanıyor, yalnız tarayıcı hata veriyor: Tarayıcı DNS önbelleği, güvenli DNS, eklenti, proxy, sertifika/SNI ve uygulama katmanını karşılaştırın.
- IPv6 TCP bağlantısı var ama TLS hatalı: IPv6 hedefindeki sanal sunucu, sertifika zinciri ve CDN/origin TLS ayarını IPv4 tarafıyla eşleştirin.
Bu yazı hazırlanırken aynı
curl -4/-6 akışı www.google.com üzerinde de denendi. Test ortamında IPv4 200 döndü; global IPv6 rotası bulunmadığından IPv6 bağlantısı kurulamadı. Bu sonuç komutun ayrımı gösterdi, fakat hedef sitenin IPv6 hizmeti hakkında hüküm vermedi. Test yapan cihazın kendi IPv6 erişimi yoksa, curl -6 hatası site arızası kanıtı değildir.Happy Eyeballs sorunu bazen gizler, çözmez
Modern istemciler çoğu zaman tek bir adrese sırayla bağlanmak yerine IPv6 ve IPv4 adaylarını kısa aralıklarla dener. IETF RFC 8305 bu yaklaşımı Happy Eyeballs olarak tanımlar. Amaç, bir adres ailesi engelli veya bozuk olduğunda kullanıcıya yansıyan gecikmeyi azaltmaktır.
Aynı RFC, geçerli görünen fakat olağan portlarda yanıt vermeyen bozuk AAAA kayıtlarının yazım hatası, rota kara deliği veya hizmet kesintisi gibi nedenlerle oluşabileceğini de açıklar. Bir tarayıcı hızla IPv4'e dönerken başka bir uygulama daha uzun bekleyebilir; IPv6 ağırlıklı ağ ise hatayı doğrudan gösterebilir. Bu nedenle “Bende açılıyor” cevabı yapılandırmanın doğru olduğunu kanıtlamaz.
Kök nedeni küçük değişiklikle düzeltin
- Değişiklikten önce A/AAAA değerlerini, TTL'yi, proxy durumunu ve saati kaydedin.
- IPv6 desteği amaçlanıyorsa doğru adresi, rotayı, 80/443 güvenlik kurallarını, web sunucusunun IPv6 dinlemesini ve sertifikayı düzeltin.
- Sunucu gerçekten IPv6 sunmayacaksa, yanlış AAAA kaydını yalnız yetkili DNS bölgesinden kaldırın. Önbellekler TTL dolana kadar eski cevabı verebilir.
- CDN veya ters proxy kullanılıyorsa görünen AAAA adresinin edge'e mi, origin'e mi ait olduğunu sağlayıcı belgesinden doğrulayın. Cloudflare’ın DNS kayıt referansı, A ve AAAA kayıtlarının alan adını IPv4/IPv6 adreslerine eşlediğini ve TTL'nin çözümleyici önbelleğini yönettiğini açıklar.
- Düzeltmeden sonra aynı komutları en az iki farklı ağda, hem kök alan adı hem
wwwiçin yeniden çalıştırın.
İstemcilerde IPv6'yı topluca kapatmak site tarafı çözüm değildir; yalnızca belirtiyi saklayabilir ve IPv6 ağırlıklı kullanıcıları dışarıda bırakabilir. Önce hatalı ilanı ya da bağlantı yolunu düzeltin.
İlgili Dijital Pusula konuları
- A, AAAA ve DNS geçişini kontrollü yönetme
- Hosting, domain, SSL ve yayın kontrolü
- CDN katmanını kanıtla ayırma rehberi
Özetle
A ile AAAA'yı ayrı sorgulayın, IPv4 ile IPv6 web isteğini ayrı çalıştırın, sonucu iki ağda karşılaştırın. Sorunu paylaşırken alan adını yazabiliyorsanız A/AAAA çıktısını, curl hata kodunu ve hangi ağda görüldüğünü ekleyin; gizli origin IP veya panel bilgisini paylaşmayın.
Güncelleme: 16 Ağustos 2026. Komut çıktıları ağ, DNS önbelleği ve sağlayıcı yapılandırmasına göre değişir; kayıt düzenlemeden önce mevcut değerleri yedekleyin.
Dijital Dünyanıza Yön Veren Pusula
