Kurum ağlarında “yavaş internet” şikâyetinin arkasından çoğu zaman DNS çıkar: uygulama aynı, hat aynı; ama resolver uzakta, cache yok, upstream geç yanıtlıyor. DNS’i düzeltmek “bir sunucu daha kuralım” değil, resolver katmanını mimari bir bileşen gibi tasarlamak demektir.
Bu yazıda sahada işleyen yaklaşımı anlatıyorum: edge resolver + Anycast + BGP kontrolü + sağlık sinyali.
1) Önce kavramı netleştir: authoritative değil, recursive resolver
Buradaki hedef:
- Kullanıcı/servis → kurum içi recursive resolver (Unbound/BIND/PowerDNS Recursor vb.)
- Resolver → (gerekirse) upstream (ISP, public resolver, internal authoritative, forwarder)
Anycast’ı genelde authoritative tarafında görürüz; ama kurum içinde recursive resolver’ı Anycast yapmak, şube/POP gecikmesini belirgin azaltır ve cache verimini artırır.
2) Anycast ile ne kazanırsın (ve neyi kaybedebilirsin)?
Kazanımlar
- Şube/POP tarafında daha düşük p95 DNS latency
- Cache daha “yakın” çalıştığı için daha yüksek hit ratio
- Resolver arızasında trafik doğal olarak başka node’a kayabilir (doğru sinyalle)
Riskler
- Yanlış BGP duyurusu → yanlış yere trafik (en pahalı sınıf hata)
- Cache ısınma dalgası (failover sonrası upstream’e yük)
- “Nearest” her zaman “best” değildir (bazı hatlarda en kısa AS-path kötü olabilir)
3) Referans mimari: 2 katmanlı resolver
Benim kurumlarda sevdiğim sade model:
- Edge resolver havuzu (Anycast VIP)
POP/şube yakınında küçük bir havuz: 2–3 node (VM/metal). VIP’yi BGP ile duyurur. - Core upstream
Veri merkezinde/merkezde daha büyük kapasite ve daha zengin politika: internal zone’lar, split-horizon, kayıt yönetimi, logging.
Edge resolver tarafında amaç “her policy burada” değil; yakın cache + hızlı cevap.
4) BGP tasarımı: güvenli varsayılanlar
Anycast resolver’ı BGP ile duyururken, “minimum güvenli set”:
- Prefix: sadece resolver VIP /32 (IPv4) veya /128 (IPv6)
- Scope: iBGP (aynı AS) + kontrollü eBGP (POP’lar arası)
- Guardrail:
- max-prefix limit
- prefix-list + route-map ile sadece o VIP’in duyurulması
- mümkünse RPKI/ROA ve upstream filtre disiplini
Öneri: İlk iterasyonda internet’e anycast etmeyin. Önce kurum içi yönlendirme ile olgunlaştırın.
5) Sağlık sinyali: “DNS çalışıyor mu?” sorusunu routing’e bağla
Anycast’ta kritik parça şudur: Node üzerindeki servis bozulduğunda, route çekilmezse trafik “yakın ama bozuk” node’a akmaya devam eder.
Sağlık kontrolü için pratik yaklaşım:
- Resolver’da local health endpoint veya basit bir script
- Şu soruların yanıtını doğrula:
dig @127.0.0.1 example.com Ap95 < X ms- Internal zone (ör.
corp.local) cevaplıyor mu? - Upstream timeouts artmış mı?
- Sağlıksızsa:
- BGP announcement’ı otomatik çek (BIRD/FRR + healthcheck integration)
- veya route-map ile pref düşür (ikinci opsiyon, daha riskli)
6) Operasyon: ölçmeden Anycast işletilmez
Edge resolver’lar için izlediğim minimum metrik seti:
- DNS latency: p50/p95/p99 (UDP/TCP ayrı)
- RCODE dağılımı: NOERROR/NXDOMAIN/SERVFAIL/REFUSED
- Upstream timeout oranı
- Cache hit ratio + evictions
- QPS + concurrency
- Top query + top NXDOMAIN (anomaliler için)
Alarm örnekleri:
- SERVFAIL oranı 5 dakikada %1 → %10
- Upstream timeout artışı + latency artışı birlikte
- Anycast havuzunda tek node kaldı (redundancy kaybı)
7) Runbook: “DNS yavaş” incident’ında 15 dakikalık triage
- İstemci tarafı: aynı anda kaç POP etkileniyor?
- Resolver katmanı: Anycast VIP’e giden POP’lar aynı mı?
- Resolver node sağlık:
dig @vipvedig @node-ipkıyasla - Upstream: timeout/latency artışı var mı?
- Müdahale seçenekleri:
- En hızlı: problemli node’un BGP ilanını çek
- Orta: resolver cache parametrelerini (serve-stale vb.) devreye al
- Kalıcı: upstream/topoloji iyileştirme
8) Son söz
Anycast DNS, kurum içinde “DNS’i büyütmek” değil; DNS’i yönetilebilir bir platform katmanı haline getirmektir. Routing, observability ve runbook disiplinini birlikte kurduğunuzda; kullanıcı şikâyeti azalır, incident süresi kısalır, altyapı daha sakin çalışır.