Anycast DNS Nedir? Unicast Farkı, BGP ve DDoS Dayanıklılığı

Anycast DNS nedir?

Anycast DNS, aynı IP adresinin dünyanın farklı lokasyonlarındaki DNS sunucularından BGP ile duyurulduğu bir yönlendirme yöntemidir. Sorgu, yönlendirme tablosuna göre genellikle ağ açısından en yakın düğüme gider. Böylece tek adres hem yük dağıtır hem de bir düğüm devre dışı kalınca trafiği diğerlerine kaydırır.

Bir alan adının kayıtlarını yetkili ad sunucuları tutar. Ziyaretçinin cihazı siteye bağlanmadan önce bu sunuculardan birine "bu alan adı hangi IP adresine karşılık geliyor?" diye sorar. Anycast, bu sunucuların adresini tek bir noktaya bağlamak yerine birçok noktaya yayar.

Önce bir not düşelim: biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yazıdaki teknik anlatımı RFC belgelerine, root sunucu operatörlerinin yayımladığı verilere ve Google'ın resmi dokümanlarına dayandırdık. Amacımız, siteniz için doğru kararı vermenizi kolaylaştırmak.

Unicast ile anycast arasındaki fark nedir?

Unicast'te bir IP adresi tek bir sunucuya ya da ağ arayüzüne aittir. Anycast'te aynı adres birden fazla sunucuda yaşar ve yönlendirme sistemi her istek için bu sunuculardan birini seçer. RFC 4786, anycast'i bir hizmet adresini birden fazla bağımsız lokasyondan erişilebilir kılmak diye tanımlar.

Tablodan çıkan sonuç şu: anycast, dayanıklılık ve dağıtım için güçlü bir araç. Ancak karşılığında yönetimi zorlaşıyor, bu yüzden her hizmete uymuyor.

DNS sorgusu bir sayfanın açılışında hangi adımı oluşturur?

Tarayıcı bir sayfayı göstermeden önce alan adını IP adresine çevirmek zorundadır. Bu işlem, sayfanın ilk baytından önce gelen ilk adımlardan biridir. Zincirin hangi halkasında anycast kullanıldığını görmek için sırayı bilmek gerekir.

1. Tarayıcı, işletim sisteminin önbelleğine bakar.
2. Yanıt yoksa sorgu, internet sağlayıcınızın ya da seçtiğiniz bir özyinelemeli çözümleyiciye (recursive resolver) gider.
3. Çözümleyici önbelleğinde kayıt yoksa kök (root) sunuculardan başlayarak alan adı uzantısı sunucularına sorar.
4. Son olarak alan adınızın yetkili ad sunucusuna ulaşır ve kaydı alır.
5. Çözümleyici yanıtı TTL süresi boyunca önbelleğe yazar ve tarayıcıya iletir.

Anycast bu zincirin iki yerinde işe karışır. Birincisi, Google Public DNS gibi genel çözümleyiciler kullanıcıyı en yakın veri merkezine anycast ile yönlendirir. İkincisi, kök sunucular ile birçok yetkili ad sunucusu aynı yöntemi kullanır.

Anycast DNS aynı IP adresini BGP ile nasıl duyurur?

BGP (Border Gateway Protocol), internetteki ağların birbirine "şu IP bloğuna benim üzerimden ulaşabilirsin" dediği protokoldür. Her ağ bir otonom sistem (AS) numarasıyla anılır. Anycast DNS'te her düğüm aynı IP önekini kendi bağlantılarından internete duyurur.

Bu noktada yönlendiriciler iki ya da daha fazla yol görür. Her yönlendirici kendi politikasına ve yol uzunluğu gibi ölçütlere bakarak birini seçer. Dolayısıyla "en yakın düğüm" kararını merkezi bir yazılım değil, internetteki binlerce yönlendiricinin ortak davranışı verir.

RFC 4786 iki tür düğüm tanımlar. Küresel düğümler internetin her yerinden görünür, yerel düğümler ise NO_EXPORT gibi BGP topluluk değerleriyle yalnızca belirli bir çevreye duyurulur. BGP ve AS numarası konusunu ayrı bir yazıda daha derin işliyoruz; burada yalnızca anycast için gereken kısmını aldık.

Yetkili ad sunucusu ile özyinelemeli çözümleyicide anycast farkı nedir?

Anycast iki farklı yerde karşınıza çıkar ve bunları karıştırmak yaygın bir hatadır. Birincisi yetkili ad sunucusudur: alan adınızın kayıtlarını tutan, sizin seçtiğiniz ya da kayıt firmanızın atadığı sunucu. İkincisi özyinelemeli çözümleyicidir: ziyaretçinin cihazının sorduğu, yanıtları önbelleğe alan ve gerekirse yetkili sunuculara giden aracı sunucu.

Alan adı sahibi olarak yalnızca yetkili tarafı seçersiniz. Çözümleyici tarafı ise ziyaretçinin tercihine bağlıdır; internet sağlayıcısının sunucusu ya da Google Public DNS gibi genel bir hizmet olabilir. Google'ın dokümanına göre bu hizmet, kullanıcıyı anycast yönlendirmesiyle coğrafi olarak en yakın veri merkezine gönderir.

Dolayısıyla sitenizin DNS performansı iki ayrı anycast katmanının birleşimidir. Sizin etkileyebildiğiniz kısım, yetkili ad sunucularının nerede ve nasıl durduğudur. Ziyaretçinin çözümleyicisi üzerinde söz hakkınız yoktur, ama iyi bir yetkili altyapı o çözümleyicinin işini kolaylaştırır.

Anycast DNS ile coğrafi yönlendirme (GeoDNS) aynı şey mi?

Hayır, ikisi farklı sorunları çözer. Anycast, sorgunun hangi sunucu düğümüne ulaşacağını yönlendirme katmanında belirler. GeoDNS ise sorgunun kaynağına bakarak farklı IP adresleri döndüren bir yanıt stratejisidir.

• Anycast, DNS sunucusuna ulaşma yolunu kısaltır ve dayanıklılığı artırır.
• GeoDNS, ziyaretçiyi en uygun web sunucusuna ya da bölgesel siteye yönlendirir.
• İkisini aynı sağlayıcıda birlikte kullanabilirsiniz, ancak her biri ayrı ayarlanır.

Çok dilli ve çok bölgeli sitelerde ikisinin karışması sık yaşanır. Örneğin bir e-ticaret markası Almanya ve Türkiye için ayrı sunucular kullanıyorsa, ziyaretçiyi doğru sunucuya GeoDNS veya bir CDN yönlendirir. Anycast ise bu yönlendirmeyi yapan DNS hizmetinin kendisini hızlı ve ayakta tutar.

Anycast DNS isteği neden "en yakın" düğüme yönlendirir, yakın ne demektir?

Burada "yakın", coğrafi mesafe değil yönlendirme açısından yakınlık demektir. RFC 4786 bu konuda net: yönlendirme sisteminde topolojik olarak yakın olmak, genel olarak gidiş-dönüş süresinin kısa olmasıyla örtüşmez. RFC 7094 de aynı uyarıyı yapar.

Örnek bir senaryo kuralım (örnek hesap değil, kavramsal anlatım). İstanbul'daki bir kullanıcı için Frankfurt ve Sofya'da iki düğüm olsun. Kullanıcının internet sağlayıcısı Frankfurt'taki düğümün bulunduğu ağla doğrudan bağlantı kurmuşsa, harita üzerinde daha uzak olan düğüm yönlendirme açısından daha cazip görünebilir.

Bu yüzden anycast sağlayıcıları, düğümlerini yalnızca şehirlere değil, yoğun trafik alışverişi yapılan ağ noktalarına da yerleştirir. Aynı kaynağın paketlerinin farklı zamanlarda farklı düğüme ulaşabilmesi de normaldir. RFC 7094 bunu gecikmenin her zaman en iyi olmamasının sebebi olarak sayar.

Anycast DNS çözümleme süresini gerçekten kısaltır mı?

Kısaltabilir, ancak etkisi her zaman büyük değildir. Anycast, çözümleyici ile yetkili ad sunucusu arasındaki gidiş-dönüş süresini düşürür. Bu süre yalnızca çözümleyicinin önbelleğinde kayıt yoksa devreye girer.

Ölçek hakkında fikir vermesi için resmi kaynaklara bakalım. web.dev'e göre bir DNS çözümlemesi tipik olarak 20 ile 120 ms arasında sürer. Google Public DNS dokümanı ise önbellekte olmayan sorgularda zaman aşımları ve hatalar dahil uçtan uca çözümlemenin ortalama 300 ile 400 ms'yi bulabildiğini anlatır.

Sonuç olarak anycast'in kazancı şu durumlarda belirginleşir:

• Ziyaretçileriniz birden fazla ülkeden ya da kıtadan geliyorsa.
• Kayıtlarınızın TTL değeri kısaysa ve çözümleyiciler sık sık yetkili sunucuya dönüyorsa.
• Sayfanız çok sayıda üçüncü taraf alan adına bağlanıyorsa.

Sayfa hızının genel resmi için site hızının SEO'yu nasıl etkilediğini anlattığımız yazıya da bakabilirsiniz.

Anycast DNS DDoS saldırılarına karşı neden daha dayanıklıdır?

Çünkü saldırı trafiği tek bir noktaya değil, saldırganın bulunduğu ağa yakın düğümlere dağılır. RFC 4786 bunu iki fayda olarak sayar: dağıtık olmayan hizmet engelleme saldırılarının zararını tek bir düğümde sınırlamak ve dağıtık saldırıları bölgelere hapsetmek.

Üstelik toplam kapasite, düğüm sayısıyla birlikte artar. Tek bir sunucunun bant genişliğini doldurmak kolaydır. Onlarca lokasyona yayılmış bir adresin tamamını doldurmak ise çok daha fazla trafik ister.

Yine de bu bir garanti değildir. RFC 4786 anycast'in saldırıyı yok etmediğini, hasarı yerelleştirdiğini söyler. Bir lokasyondaki düğüm aşırı yüklenirse o bölgedeki kullanıcılar etkilenir. Bu nedenle sağlayıcı seçerken yalnızca "anycast kullanıyoruz" ifadesine değil, düğüm sayısına, kapasiteye ve saldırı yönetim sürecine de bakın.

Ayrıca saldırı sırasında sağlayıcının neyi, ne kadar hızlı yaptığı da önemlidir. Örneğin bazı sağlayıcılar saldırı altındaki düğümün duyurusunu geri çekerek trafiği diğer lokasyonlara kaydırır. Bu karar, o bölgedeki kullanıcıları başka bir düğüme taşır, ama sistemin tamamını ayakta tutar. Sağlayıcınıza bu tür bir prosedürün yazılı olup olmadığını sormak yerinde olur.

Bir anycast düğümü arızalanınca trafik nereye gider?

Düğüm sağlıklıyken BGP duyurusunu sürdürür. Hizmet bozulduğunda ise duyuruyu geri çekmesi gerekir; böylece yönlendiriciler o yolu listelerinden çıkarır ve trafik sıradaki en iyi düğüme kayar. RFC 4786, duyurunun hizmet sağlığına bağlanmasını açıkça önerir.

Bu geçişin sırası genelde şöyledir:

1. Sağlık kontrolü DNS hizmetinin yanıt vermediğini fark eder.
2. Düğüm, BGP duyurusunu geri çeker.
3. Komşu yönlendiriciler bu bilgiyi yayar ve yeni en iyi yol seçilir.
4. Yeni sorgular başka bir düğüme düşer.

Geçiş anlık değildir, çünkü yönlendirme bilgisinin yayılması zaman alır. Neyse ki DNS istemcileri bu aralığı kısmen telafi eder. Alan adınızın birden fazla NS kaydı varsa çözümleyici, yanıt alamadığında diğer ad sunucusunu dener. Bu yüzden iyi bir kurulumda hem anycast hem de birden fazla bağımsız NS adresi bir arada bulunur.

Bu nedenle "anycast var, yedeğe gerek yok" yaklaşımı riskli bir varsayımdır. Çünkü aynı sağlayıcının tüm düğümleri ortak bir yazılım hatasından ya da yanlış bir yapılandırma güncellemesinden etkilenebilir. RFC 4786 bu yüzden düğümlerin birbirinden bağımsız ve kendi başına yeterli olmasını önerir.

Anycast DNS'in riskleri ve sınırları nelerdir?

Anycast her sorunun ilacı değildir. RFC 4786 ve RFC 7094 belgeleri sınırları açıkça yazar. Bunları bilmek, sağlayıcıya doğru soruları sormanızı sağlar.

• Durumlu bağlantılar: Bir TCP bağlantısının paketleri farklı düğümlere giderse bağlantı kopar. DNS'in çoğu sorgusu kısa UDP paketleridir, bu yüzden uygun bir kullanım alanıdır. Büyük yanıtlarda TCP'ye geçilebileceğini unutmayın.
• Eşit maliyetli yollar: Yönlendiriciler paketleri eşit yollara bölerse çok paketli işlemler bozulabilir.
• Rota dalgalanması: Bir düğüm sürekli duyuru verip geri çekerse ceza puanları yayılır ve sağlıklı düğümler bile etkilenebilir.
• Kaçırma riski: Meşru düğümlerin yönlendirme sisteminde görünür olması, sahte düğümü fark etmeyi zorlaştırabilir.

RFC 4786 sonuç bölümünde anycast'in internetin her hizmeti için genel bir çözüm olmadığını, ancak sınırlı sayıda kritik hizmetin dağıtımı için yararlı kaldığını söyler.

Kök DNS sunucuları anycast'i nasıl kullanıyor?

Kök sunucular anycast'in en bilinen örneğidir. root-servers.org sayfasına göre kök ad sunucusu sistemi 13 kimlikten oluşur ve bunları 12 bağımsız kuruluş işletir. Aynı sayfa, 3 Ekim 2026 itibarıyla sistemde 2045 çalışan örnek (instance) bulunduğunu bildirir.

Yani 13 adres, yüzlerce şehre yayılmış binlerce sunucuya karşılık gelir. IPv4 ve IPv6 adres sayısını 13 ile sınırlı tutmanın pratik sebepleri vardı; anycast ise bu sınırı kapasite açısından aşmayı mümkün kıldı. RFC 7094, 2007 itibarıyla 13 kök sunucunun en az 10'unun anycast kullandığını not eder.

Bu örnek bize iki şey öğretir. Birincisi, anycast yıllardır internetin temel altyapısında çalışan olgun bir teknik. İkincisi, çok sayıda düğüm ancak sıkı bir izleme ve yönetim ekibiyle ayakta kalıyor.

Kök sunucuların yayınladığı veri bir de şunu gösterir: aynı harf adı altında çalışan örnekler, dünyanın farklı bölgelerine yayılmış olabilir. Yani b.root-servers.net gibi bir ad, tek bir makineyi değil, bir dağıtım ağını temsil eder. Alan adı sahibi olarak sizin kök sunucularla doğrudan bir işiniz yoktur. Yine de bu yapı, aynı mantığı kendi ad sunucularınızda aramanız için güçlü bir gerekçedir.

Anycast DNS hangi durumlarda gerçekten fark yaratır?

Fark, ziyaretçilerinizin nerede olduğuna, trafiğinizin ne kadar dalgalandığına ve kesintinin size maliyetine bağlıdır. Aşağıdaki tablo ölçüm değil, genel bir değerlendirme sunar; kendi sitenizde karar vermeden önce gerçek verilere bakmalısınız.

Özetle, anycast DNS ne kadar uluslararası ve ne kadar kesintiye duyarlı bir iş yürütüyorsanız o kadar değer üretir.

Anycast DNS e-ticarette ve kampanya dönemlerinde neden önemlidir?

E-ticarette bir kesintinin bedeli doğrudan ciroya yansır. DNS ise sitenin önündeki ilk kapıdır; kapı kapalıysa en hızlı sunucunun da bir anlamı kalmaz. Bu yüzden kampanya öncesi kontrol listenizde DNS dayanıklılığı bulunmalı.

Basit bir örnek hesapla düşünelim. Bu rakamlar gerçek veri değil, yalnızca mantığı göstermek için uydurulmuş örnektir. Günlük 100.000 TL cirosu ve 20.000 TL reklam bütçesi olan bir mağaza düşünün. Trafik gün içinde eşit dağılmasa da ortalama olarak 30 dakikalık bir erişilemezlik yaklaşık 2.083 TL ciro ve yaklaşık 417 TL reklam harcamasının boşa gitmesi demektir.

Kampanya saatinde trafik yoğunlaştığı için gerçek kayıp bu ortalamanın üstüne çıkabilir. Ayrıca kesinti sırasında kaybettiğiniz yalnızca satış değildir; reklamdan gelen ziyaretçi markaya olan güvenini de yitirebilir. Anycast tek başına bu riski sıfırlamaz, ancak DNS katmanının tek bir arızada çökmesini zorlaştırır. Sayfa hızı ile satış ilişkisini e-ticarette sayfa hızı satışları etkiler mi yazımızda ayrıca ele aldık.

Küçük bir kurumsal site için anycast DNS gerekli mi?

Çoğu zaman kendi başınıza anycast kurmanız gerekmez, çünkü yönetilen DNS hizmetleri bunu sizin yerinize sunar. Sizin işiniz, kullandığınız DNS sağlayıcısının bu altyapıya sahip olup olmadığını öğrenmek ve alan adınızı ona yönlendirmektir.

Alan adı firmanızın varsayılan ad sunucuları da anycast kullanıyor olabilir. Bunu varsayım olarak bırakmayın, sağlayıcının dokümanına ya da destek ekibine sorun. Ardından DNS sorgulama aracıyla ad sunucularınızın IP adreslerine bakıp ağ bilgisini inceleyebilirsiniz.

Küçük bir site için asıl risk anycast eksikliği değil, tek bir ad sunucusuna bağlı kalmaktır. Hosting seçerken DNS ve altyapı sorularını da masaya koymanız için hosting nasıl seçilir yazımıza göz atın.

Anycast DNS sağlayıcısı seçerken nelere bakmalısınız?

Sağlayıcının pazarlama sayfasındaki "global ağ" ifadesi tek başına bir şey söylemez. Aşağıdaki soruları sorarak somut cevap isteyin.

• Düğümler hangi şehirlerde ve hangi bağlantı noktalarında bulunuyor, hedef kitlenizin bölgesini kapsıyor mu?
• Alan adınıza birden fazla ad sunucusu adresi atanıyor mu ve bunlar bağımsız ağlardan mı yayılıyor?
• IPv6 (AAAA) kayıtlarını ve ad sunucularının kendi IPv6 adreslerini destekliyor mu? IPv6 testi aracıyla sitenizin durumunu kontrol edebilirsiniz.
• DNSSEC ve gerekli kayıt türleri (CNAME, MX, TXT, CAA) desteklenecek mi?
• Bir durum sayfası, kesinti bildirimi ve yazılı hizmet seviyesi taahhüdü var mı?
• Kayıtları hızlı değiştirebileceğiniz bir arayüz ve API sunuyor mu?

Bu listede "kaç düğüm var?" sorusunu bilerek ilk sıraya koymadık. Düğüm sayısı tek başına kaliteyi göstermez; bağlantı kalitesi ve izleme süreci en az onun kadar önemlidir.

DNS sağlayıcınızı değiştirirken nelere dikkat etmelisiniz?

Sağlayıcı değiştirmek, yanlış yapılırsa e-postanın ve sitenin kısa süre erişilemez olmasına yol açar. Bu nedenle işlemi bir plana bağlayın ve yoğun saatlerin dışında yapın. Sıra genellikle şöyledir:

1. Mevcut DNS bölgesindeki tüm kayıtları (A, AAAA, CNAME, MX, TXT, CAA) dışa aktarın ve yeni sağlayıcıda aynen oluşturun.
2. TTL değerlerini birkaç gün önceden kısaltın.
3. Yeni sağlayıcıda kayıtların doğru yanıtladığını, ad sunucusuna doğrudan sorgu atarak test edin.
4. Alan adı kayıt firmanızın panelinde ad sunucularını değiştirin.
5. Eski sağlayıcıdaki bölgeyi hemen silmeyin, çözümleyiciler yeni bilgiye geçene kadar bekleyin.

Özellikle DNSSEC açıksa dikkatli olun. DS kaydı yanlış yönetilirse alan adı birçok çözümleyicide hiç çözülmeyebilir. Bu adımı, hem eski hem yeni sağlayıcının belgesine göre sırayla uygulayın. Emin değilseniz işlemi sağlayıcının destek ekibiyle birlikte yürütün.

Kendi anycast DNS ağınızı kurmak mantıklı mı, ne zaman hosting sağlayıcısına bırakmalısınız?

Çoğu web sitesi ve e-ticaret sahibi için cevap hayır. Kendi anycast ağınızı kurmak, bir DNS yazılımı kurmaktan çok bir ağ operatörü olmak demektir. Bunu başkasına bırakmak çoğu zaman daha akıllıca bir karardır.

Gerekenler kabaca şöyle:

• Kendi AS numaranız ve duyurabileceğiniz bir IP öneki.
• Farklı lokasyonlarda, internete BGP ile bağlanan sunucular.
• Her düğümün sağlık durumuna bağlı duyuru yönetimi.
• Dağıtık noktalardan izleme ve saldırı anında müdahale edecek bir ekip.

RFC 4786 düğümlerin birbirinden olabildiğince bağımsız çalışması gerektiğini vurgular. Bu bağımsızlığı sağlamak maliyetlidir. Bir yazılımcıysanız ve kendi VPS'inizde ad sunucusu çalıştırıyorsanız bile anycast adımını sağlayıcıya bırakın. Gerçekten gerekiyorsa bunu bir ağ mühendisiyle birlikte planlayın.

Anycast DNS'i dig ve DNS sorgulama aracıyla nasıl kontrol edersiniz?

Önce alan adınızın hangi ad sunucularını kullandığına bakın. Ardından her birine doğrudan soru sorup yanıt süresini ölçebilirsiniz. Aşağıdaki komutlar, dig aracının resmi dokümanında bulunan seçeneklerle çalışır. Örnek alan adı ve ad sunucusu kurgusaldır.

dig example.com NS +short
dig @ns1.example.com example.com A +stats
dig @ns1.example.com example.com A +nsid
dig example.com +trace

İlk komut ad sunucularını kısa biçimde listeler. İkincisi seçtiğiniz sunucuya sorar ve sonda sorgu süresini gösterir. Üçüncüsü, sunucu destekliyorsa EDNS ad sunucusu kimliği (NSID) ister; bazı sağlayıcılar buradan yanıt veren düğümü belirtir. Dördüncüsü kök sunuculardan başlayarak delegasyon yolunu izler.

Unutmayın, tek bir noktadan yaptığınız sorgu yalnızca size en yakın düğümü gösterir. Farklı ülkelerdeki sonuçları görmek için dağıtık noktalardan ölçüm gerekir; RFC 4786 de izlemenin dağıtık problarla yapılmasını önerir. Hızlı bir kontrol için DNS sorgulama aracımızı, ad sunucularının IP bilgisi için IP sorgulama aracımızı ve kayıt firması bilgisi için WHOIS sorgulamayı kullanın.

Anycast DNS ile TTL ve DNS önbelleği nasıl birlikte çalışır?

TTL, bir kaydın çözümleyicilerde ne kadar süre saklanabileceğini söyler. TTL uzunsa çözümleyici yetkili sunucuya az gider, bu yüzden anycast'in hız etkisi azalır. TTL kısaysa daha sık sorgu gelir ve yakın bir düğüme ulaşmak daha değerli olur.

Google Public DNS dokümanı da düşük TTL değerlerinin önbellek ıskalamalarını artırdığını hatırlatır. Bu, kısa TTL'in bedelsiz olmadığı anlamına gelir. Dolayısıyla TTL'i yalnızca gerçek bir ihtiyaç varsa düşürün.

Örneğin site taşıma ya da IP değişikliği öncesinde TTL'i geçici olarak kısaltmak, değişikliğin çözümleyicilere daha hızlı ulaşmasını sağlar. İşlem bittikten sonra eski değere dönmek mantıklıdır. Taşıma sürecinin SEO tarafı için SEO migration kontrol listemize göz atın.

DNS kesintisi SEO ve reklam performansını nasıl etkiler?

DNS çalışmıyorsa ziyaretçi sitenize hiç ulaşamaz. Arama motoru botları da aynı kaderi paylaşır. Google Search Console'daki tarama istatistikleri raporu bu durumu ayrı bir metrikle gösterir: DNS çözümleme hataları, ad sunucunuzun alan adını tanımadığı ya da tarama sırasında yanıt vermediği anları listeler.

Aynı raporun robots.txt bölümü de önemlidir. Google'ın belirttiğine göre robots.txt isteği geçerli bir dosya ya da 404 döndürmezse Google sitenizi taramayı yavaşlatır veya durdurur. DNS sorunu bu isteği de engelleyebilir.

Reklam tarafında da durum açık. Reklama tıklayan kullanıcı sayfayı göremezse bütçe boşa gider. Kesinti riski yüksek olan dönemlerde, örneğin büyük kampanya günlerinde, DNS dayanıklılığını kontrol listenize eklemek mantıklıdır. Google Ads yönetimi ve SEO danışmanlığı çalışmalarımızda altyapı sağlığını da bu yüzden gündemde tutuyoruz.

DNS dayanıklılığı e-posta teslimatını da etkiler mi?

Evet, çünkü e-posta da alan adı kayıtlarına bağlıdır. Gönderen sunucu, size posta iletmeden önce alan adınızın MX kayıtlarını sorgular. Ad sunucularınıza ulaşılamazsa bu sorgu yanıtsız kalır.

Çoğu posta sunucusu böyle bir durumda iletiyi hemen silmez, kuyruğa alıp daha sonra yeniden dener. Ancak bu davranış her sistemde aynı değildir. Ayrıca SPF, DKIM ve DMARC doğrulamaları da TXT kayıtlarına dayanır; DNS yanıt vermezse bu kontroller başarısız olabilir.

Bu yüzden kurumsal e-posta kullanan bir işletme için DNS dayanıklılığı yalnızca web sitesi meselesi değildir. Örneğin teklif e-postasının geç ulaşması, sipariş onayının spam klasörüne düşmesi ya da müşteri yanıtının kaybolması gibi sonuçlar doğurabilir. Alan adı uzantılı e-posta kurulumunu kurumsal e-posta altyapısı yazımızda adım adım anlattık.

Anycast DNS hakkında yaygın yanlışlar nelerdir?

Konu teknik olduğu için pazarlama dili kolayca yanlış beklenti yaratır. En sık karşılaşılan yanlış anlamalar şunlardır.

• "Anycast bir CDN'dir." Hayır. Anycast bir yönlendirme tekniğidir; CDN ise içerik önbellekleme hizmetidir. İkisi birlikte kullanılabilir ama aynı şey değildir.
• "Anycast DDoS'a karşı tam koruma sağlar." Hayır. RFC 4786'ya göre hasarı yerelleştirir, ortadan kaldırmaz.
• "Anycast her zaman daha hızlıdır." Hayır. RFC 7094, yönlendirme açısından yakın olanın en düşük gecikmeli olmayabileceğini belirtir.
• "Anycast DNS kurunca sitem de hızlanır." Kısmen. Yalnızca DNS çözümleme adımı kısalır; sunucu yanıt süresi ve sayfa ağırlığı aynı kalır.

Sitenizin gerçek hız sorunlarını bulmak için Core Web Vitals metriklerine ve Lighthouse testine bakmak çoğu zaman daha kısa yoldur.

Anycast DNS için hangi adımları izlemelisiniz?

Sürecin özü basit: önce mevcut durumu öğrenin, sonra gerçekten ihtiyacınız varsa iyileştirin. Aşağıdaki sıra, çoğu web sitesi ve e-ticaret sahibi için yeterlidir.

1. Alan adınızın ad sunucularını listeleyin ve kimin işlettiğini öğrenin.
2. Sağlayıcıdan anycast kullanıp kullanmadığını ve düğümlerin hangi bölgelerde olduğunu yazılı isteyin.
3. En az iki bağımsız ad sunucusu adresinin tanımlı olduğunu doğrulayın.
4. Ziyaretçilerinizin geldiği bölgelerden sorgu süresini ölçün.
5. TTL değerlerini bilinçli seçin ve taşıma öncesinde geçici olarak düşürün.
6. Search Console'daki tarama istatistiklerinde DNS hatalarını düzenli kontrol edin.

Altyapı kararlarınızı pazarlama hedefleriyle birlikte düşünmek isterseniz web tasarım ve e-ticaret danışmanlığı hizmetlerimizle size destek olabiliriz. Kendi VPS'inizi yönetiyorsanız ve DNS tarafında emin değilseniz, ad sunucusu işini güvenilir bir sağlayıcıya bırakmak çoğu zaman en doğru karardır.