Çoklu Sağlayıcı DNS Nasıl Kurulur? octoDNS ile Zero‑Downtime Geçiş ve Dayanıklılık Rehberi

Giriş: Küçük Bir Kesinti, Büyük Bir Ders

Hiç öğle arasında “bir kahve alıp döneyim” diye kalkıp, masaya geldiğinizde sitenin açılmadığını gördünüz mü? Ben gördüm. O gün aklımın bir köşesinde hep duran “DNS’i tek sepete koyma” fikri koca bir projektörle yüzüme tutuldu. Bir sağlayıcıda yaşanan kısa bir aksama, görünenin aksine e-posta tesliminden webhook’lara, CDN uçlarından ödeme sayfasına kadar bir sürü şeyi peş peşe etkiliyor. Küçücük bir TTL değeri bile bazen kaderi belirleyebiliyor. İşte o günden sonra çoklu sağlayıcı DNS’i bir lüks değil, bir alışkanlık haline getirdim.

Bu yazıda, tek bir DNS sağlayıcısına bağlı kalmadan, iki ya da daha fazla sağlayıcıyı birlikte çalıştırmanın pratik yolunu konuşacağız. Bunu yaparken elimizde çok kullanışlı bir anahtar var: octoDNS. Git tabanlı bir iş akışıyla DNS kayıtlarınızı insan gibi yönetiyor, farklı sağlayıcıları tek bir kaynak dosyadan besliyor ve sıfır kesintiyle geçiş planı kurmayı kolaylaştırıyor. Adım adım ilerleyelim; kavramları sadeleştirelim, küçük örneklerle somutlaştıralım ve en önemlisi, devre dışı kaldığında can yakacak noktaları baştan yumuşatalım. Hadi başlayalım.

Neden Çoklu Sağlayıcı DNS? Kırılganlıktan Esnekliğe

DNS’i her zaman bir şehir haritası gibi düşündüm. Adresleri en iyi bilen tek bir rehberiniz varsa, rehber kaybolduğunda bütün yollar bir anda karışır. Oysa iki rehberiniz olsaydı, biri ayağı takılıp düşünce diğeri “devam” diyebilirdi. Çoklu sağlayıcı DNS tam olarak bu: farklı altyapılarda aynı bölgeyi (zone) yayınlayıp, tek bir kelebeğin kanat çırpışıyla her şeyin yere kapaklanmasını önlemek.

Burada en büyük kazanç dayanıklılık. Bir sağlayıcı bakımdayken ya da kısa bir ağ sorununda diğeri devreye girer. Yönetim tarafında ise tek bir yerde kayıt tutup bunu birden fazla tarafa otomatik yansıtmak var. İş yükünü azaltıyor, sürpriz hataları sınırlıyor ve değişiklikleri izlenebilir kılıyor. Dezavantajları yok mu? Elbette var. Farklı sağlayıcıların desteklediği özellikler birebir aynı değil; bu yüzden “ortak paydayı” tutturmak önemli. Ama biraz disiplin, biraz sabır ve doğru araçlarla bu farklılıkları güzelce yönetebiliyorsunuz.

Mesela şöyle düşünün: Kök alan adınızda bir CNAME olamayacağını biliyorsunuz ama bazı sağlayıcılar bunu ALIAS/ANAME gibi özelliklerle dolaylı çözüyor. Çoklu sağlayıcıda, herkesin anladığı yere inmek gerekiyor. Yani kökte A/AAAA kullanmak, TTL’leri makul tutmak ve “özel” bir şey kullanacaksanız onun eşdeğerini diğer tarafta nasıl anlatacağınızı baştan planlamak. Bu yazının ilerleyen kısımlarında, bu tür küçük ama kritik nüansları tek tek toplayacağız.

octoDNS Nedir, Nasıl Düşünmeliyiz?

octoDNS’i bir çevirmen gibi hayal edin. Elinizde tek bir “gerçek kaynak” var, yani kayıtlarınızı tanımladığınız dosyalar. octoDNS bu tanımları alıyor, farklı DNS sağlayıcılarının dillerine çeviriyor ve senkronize ediyor. En sevdiğim tarafı, Git tabanlı bir akışa cuk oturması. Pull request açıyorsunuz, diff görüyorsunuz, onay sürecinden geçiyor ve komutla ya da CI ile canlıya gidiyor. Böylece “kim, ne zaman, neyi değiştirdi” sorusu her zaman cevap buluyor.

octoDNS ile iki ana kavrama alışıyoruz: provider ve zone. Provider, konuşacağınız hizmet; zone ise alan adınızın bölgesi. Bir dosyada provider’ları tanımlıyorsunuz, bir dosyada da zone içeriğini. Komut satırıyla “ne fark var” diye bakıp, “uygula” diyorsunuz. En tatlı yanı, önce bir “plan” çıktısı alıp, hiçbir şey yayınlamadan yapılacakları görebilmeniz.

Daha fazla detay isterseniz octoDNS projesinin GitHub sayfası ve özellikle octoDNS belgeleri gayet net rehberler sunuyor. DNS kayıt türlerini hızlıca hatırlamak için de DNS kayıt türlerine dair kısa özet hoş bir tazeleme sağlıyor. Ama bu yazıda mümkün olduğunca teknik jargonu düşük tutacağım, çünkü asıl hedefimiz güvenli ve sıfır kesintiye yakın bir geçiş planı kurmak.

Hazırlık: Envanteri Çıkar, Riskleri Not Al, TTL’i Konuşalım

Kurulumdan önce, küçük bir keşif gezisi şart. Önce alan adınızda neler var tek tek yazın: kök A/AAAA, www CNAME, e-posta için MX ve ona bağlı SPF, DKIM, DMARC; API alt alanları; CDN ve WAF arkasındaki uçlar; belki bir load balancer; belki bir static site. Hepsini bir yerde görmek hem eksikleri hem de birbirine dokunan parçaları ortaya çıkarır. Bu aşamada “kime bağımlıyım” sorusunu dürüstçe yanıtlamak önemli. E-posta doğrulamaları, SSL doğrulamaları, üçüncü parti servislerin doğrulama TXT’leri… Bunlar unutulunca üretimde küçük kıvılcımlar çıkar.

İkinci kritik konu TTL. Geçişten önce TTL’leri geçici olarak düşürmek iyi bir alışkanlık. Böylece isim sunucular, yeni kayıtları daha hızlı görür. Sakin zamanlarda 1 saat civarıyla yaşamak güzelken, geçiş günlerinde bunu daha aşağı çekmek işleri hızlandırır. Ama TTL’i çok düşürmek de gereksiz sorgu yükü demek; dengenizi bulun. Geçiş bitince TTL’leri tekrar makul seviyeye geri yükseltmek güzel bir kapanış olur.

Son olarak “özel” kayıtları işaretleyin. Kökte ALIAS kullanıyorsanız, diğer tarafta bunu nasıl anlatacaksınız? SPF’inizde çok fazla include var mı? TXT kayıtlarınızda TTL uyumu önemli mi? Bu soruların her birinin cevabı, birazdan yazacağımız YAML dosyalarına nasıl yaklaşacağımızı belirleyecek.

octoDNS ile İlk Kurulum: Küçük Bir Depo, Temiz Dosyalar

Elimde genelde minik bir Git deposu olur. İçinde config.yaml ve zones/ klasörü. Provider tanımlarını config’e, kayıtları ise zone dosyalarına koyarım. İsimlendirme çok fark etmiyor, net olsun yeter. Aşağıdaki örnek, iki sağlayıcıya aynı zone’u yayınlamak için fikir veriyor:

# config.yaml
providers:
  my-cloudflare:
    class: octodns.provider.cloudflare.CloudflareProvider
    token: env/CLOUDFLARE_API_TOKEN
  my-route53:
    class: octodns.provider.route53.Route53Provider
    access_key_id: env/AWS_ACCESS_KEY_ID
    secret_access_key: env/AWS_SECRET_ACCESS_KEY

zones:
  example.com.:
    sources:
      - config/zones/example.com.yaml
    targets:
      - my-cloudflare
      - my-route53

Zone dosyası ise şöyle yalın olabilir. Kökte A/AAAA, web için www CNAME, e-posta için MX ve SPF. Gerektikçe DMARC, DKIM ve doğrulama TXT’leri eklenir:

# zones/example.com.yaml
---
# Varsayılan TTL: dakika cinsinden değil, saniye cinsinden yazmayı unutmayın.
$ttl: 3600

@:
  A:
    - value: 203.0.113.10
  AAAA:
    - value: 2001:db8::10

www:
  CNAME:
    - value: example.com.

mail:
  A:
    - value: 203.0.113.20

@:
  MX:
    - preference: 10
      exchange: mail.example.com.

@:
  TXT:
    - value: "v=spf1 include:_spf.example.net ~all"

İlk çalıştırmada önce “ne yapacak” diye bakmayı seviyorum. octoDNS’in plan çıktısı güven verir. Bir şey ters gelirse, tam o ekranda fark edilir:

# Sanal (dry-run) plan: ne değişecek?
octodns-validate --config-file=config.yaml
octodns-sync --config-file=config.yaml --dry-run --debug

# Uygulama zamanı
octodns-sync --config-file=config.yaml

Kimlik bilgilerini dosyaya gömmek yerine ortam değişkenleriyle beslemek rahat. Uzun vadede bir gizli yönetimi çözümü kullanmak işleri iyice tatlılaştırır. Küçük ekiplerde bile, “gizli nerede, kim erişir, nasıl rotasyon olur” sorularını erkenden oturtmak, bir gece yarısı gereksizce uykunuzun bölünmesini engeller.

Zero‑Downtime Geçiş: Çift Yayın, Temiz NS Değişimi ve Sakin TTL

Şimdi gelelim asıl kalp atışını hızlandıran ana sahneye: sıfıra yakın kesintiyle geçiş. Burada sihirli iki adım var: çift yayın ve NS değişimi. Önce mevcut sağlayıcınızda yayın devam ederken, yeni sağlayıcıyı da octoDNS ile aynı kayıtlarla besliyorsunuz. Yani iki tarafta da aynı zone var. Bu aşamada TTL’leri geçici olarak düşürmek işinizi kolaylaştırır; planladığınız pencerenin başında düşürüp, iş bitince tekrar yükseltmeyi unutmayın.

İşin omurgası sağlam olunca NS değişimi sakince ilerler. alan adı kayıt operatörünüzden NS kayıtlarını yeni sağlayıcıya doğru güncellersiniz. Ancak burada küçük bir parantez açmak lazım: DNSSEC kullanıyorsanız, DS kaydını da konuşuyoruz demek. NS değişiminde DS uyumunu doğru sırayla yapmak çok önemli. DS’yi yanlış zamanda güncellemek çözülmeyen bir bulmaca gibi davranır. Bu adımı daha önce adım adım anlattığım DS kaydını güvenle güncellemek üzerine yazdığım adım adım rehber bu noktada işinizi kolaylaştırır.

Bu süreçte bence en sevilesi şey, octoDNS’in “tek kaynaktan iki hedefi” beslemesi. Bir yerde düzeltme yapıyorsunuz, her iki sağlayıcıya aynı anda gidiyor. Peki bitti mi? Aslında “gözlem” kısmı var. NS değişiminden sonra bir süre sorguları iki tarafta da izlemek, beklenmedik bir kayıt, yanlış bir TTL ya da eksik bir TXT var mı diye bakmak iyi bir refleks. Sakin sakin bakınca, küçük pürüzler bile nazikçe kendini gösteriyor.

Dayanıklılığı Artırmak: Sağlık Kontrolleri, Yanıt Politikaları ve Basit Oyunlar

Çoklu sağlayıcının gücü, tek bir yerin hasta olduğunda diğeriyle top çevirebilmesi. Bazı sağlayıcılar sağlık kontrolü ve yönlendirme politikaları sunuyor. octoDNS, kayıtlarınızı tanımlayıp yayınlamada harika; canlı sağlık kararlarını ise genelde sağlayıcıların özellikleri veriyor. Bu yüzden kayıtlarınızı tanımlarken “statik gerçek” ile “dinamik davranış” arasındaki ayrımı akılda tutun. Statikler octoDNS’in tatlı dünyasında, dinamikler de sağlayıcıların sahasında.

Basit bir oyun planı şöyle olur: kritik uçlar için iki ayrı IP ya da hedef adres tutmak ve cevapları bölmek. Böylece bir uçtan duman çıkarsa diğeri sahneye çıkar. TTL’leriniz burada yine önemli. Aşırı düşük TTL sorgu yükünü artırır, aşırı yüksek TTL ise değişikliklerin hissedilmesini yavaşlatır. Orta karar, gece uyumanızı sağlar. Bir de “çift yayınlı” günlerde, kayıtların birebir aynı kaldığından emin olmak için düzenli diff almak var; octoDNS bunun için zaten plan çıktılarında net bir tablo veriyor.

Arada ufak testler yapmayı alışkanlık haline getirin. Önemsiz bir alt alanı sahte hedefe yönlendirip, yayılımın nasıl davrandığını izlemek mesela. Bazı günler her şey yolunda gider, bazı günler küçük sürprizler çıkar. Sürprizleri prova ortamında görmek, üretimde kahveyi soğutmamıza engel olur.

Sık Tökezlenen Taşlar: Kökte CNAME, SPF Limitleri, TXT Düzenleri

Şimdi biraz can sıkıcı, ama baştan bilince tatlıya bağlanan detaylar. İlki, kök alanda CNAME olamaması. Bazı hizmetler bu kısıtı ALIAS/ANAME isimleriyle çeviriyor. Çoklu sağlayıcıda bunu ortak paydaya çekmek gerekiyor. Kökte A/AAAA kullanıp, hedef IP’leri yönetilebilir bir yerde tutmak çoğu zaman daha huzurlu. CDN ya da barındırma hedefi değişecekse, bir ara katman üzerinden yönetmek mantıklı.

İkinci konu SPF. Bir yerden sonra “include” zincirleri uzuyor ve DNS sorgu sınırlarına takılma riski beliriyor. SPF metninizi yalın tutmak, gerekiyorsa göndericileri toparlamak işinizi kolaylaştırır. TXT kayıtlarınız çoğalınca, düzene çok önem verin. Bir doğrulama kaydını silmek kolay; ama o kaydın hangi entegrasyonda kullanıldığını hatırlamak her zaman o kadar kolay olmuyor. Bu yüzden zone dosyasına ufak notlar düşmek, kısa açıklamalar koymak ileride altın değerine dönüşüyor.

Bir de CAA kayıtları var. Sertifika otoritesini sınırlarken abartmamak ve güncelleme süreçlerini takip etmek önemli. Sağlayıcıların metin alanı limitleri ve biçim farklılıkları sizi şaşırtabilir; octoDNS burada çoğu zaman akıllı bir çevirmen gibi davranır ama ilk plan çıktılarında dikkatli gözle bakmak şart. Bir şey uyuşmuyor mu, önce sadeleştirin. Sadelik çoğu sorunu daha doğmadan çözer.

Operasyon Akışı: Git, İnceleme, CI ve Küçük Ritüeller

Güzel bir çoklu sağlayıcı DNS kurulumunun sırrı, teknik kurulum kadar operasyonel ritimde saklı. Benim sevdiğim akış şöyle: her değişiklik bir branch, bir pull request. Kod bakışı gibi DNS bakışı. Diff’te yanlış bir nokta var mı, TTL aklımıza yatıyor mu, doğrulama TXT’si gerçekten gerekli mi? Onaydan sonra CI, octoDNS’in planını çalıştırır; plan mantıklıysa uygular. Üretime giderken “–dry-run” çıktısını log’a düşürmek, ileride bir şeyi geriye sararken çok işe yarar.

Gizlileri ortam değişkeniyle vermek, rotasyonu ekip takvimine yazmak ve dönemsel erişim denetimi yapmak moral için birebirdir. Bir de ufak bir staging zone açmak hoş oluyor. Örneğin staging.example.com gibi bir bölgeyi, canlı alanın minyatürü gibi tutup, önce orada dener, sonra prod’a geçirirsiniz. Kısa, hızlı, güvenli.

Son olarak, küçük “yangın tatbikatları” yapın. Bir IP’yi bilerek yanlış gösterip kaç dakika içinde fark ettiğinizi görmeyin demiyorum; ama en azından runbook’ta adımları okuyup bir ekiple sözlü prova yapmak bile çok şey kazandırır. Kim, hangi komutları çalıştırır, hangi panellerden bakar, nerede dur der? Yazılı olduğu sürece, gecenin bir yarısı hafızanıza yüklenmek zorunda kalmaz.

Örnek Senaryo: Canlıda Çift Yayın ve Temiz Kesim

Hayali bir senaryo üzerinden geçelim. Diyelim ki tek sağlayıcıda yaşayan example.com’u iki sağlayıcıya bölmek istiyorsunuz. İlk gün bir depo açıp mevcut kayıtları YAML’a taşıyorsunuz. octoDNS ile plan/dry-run alıp, konsolda “ah, www’ye CNAME noktayı unutmuşum” gibi küçük düzeltmeleri yakalayıp toparlıyorsunuz. Her şey hazır olunca ikinci sağlayıcıya da aynı kayıtları yayınlıyorsunuz. Artık çift yayın var.

Geçişten 24 saat önce TTL’leri yarıya indiriyorsunuz. Ertesi gün kayıt operatörünüzden NS’leri yeni sağlayıcı setine çekiyorsunuz. DNSSEC varsa, DS adımlarını doğru sırayla not etmişsiniz; DS’yi yeni anahtara işaret edecek şekilde güncelliyor ve imzaların sağlıklı göründüğünü kontrol ediyorsunuz. O günün geri kalanında hem sorgu sayacı, hem hata günlükleri, hem de kullanıcı geri bildirimlerine bakıyorsunuz. Bir şey sıkıntı çıkarmazsa, TTL’leri bir üst seviyeye geri alıp “geçiş tamam” diyorsunuz.

Bu akışta en sevdiğim cümle, “kimse fark etmedi” cümlesi. Çünkü iyi bir geçişin alameti, haber bile olmamasıdır. Birkaç gün sonra bir daha plan/diff alıp “iki sağlayıcıda da aynı mıyız” kontrolü, kapanışın tatlı noktasıdır.

Kapanış: Küçük Adımlar, Büyük Huzur

Toparlayalım. Çoklu sağlayıcı DNS, bir gecede değil ama birkaç temiz adımda hayatınıza yerleşebiliyor. İlk gün envanter, ikinci gün octoDNS ile tek kaynak dosya, üçüncü gün çift yayın, dördüncü gün sakin bir NS değişimi… Bu adımların her biri, küçük ama etkili bir ritüel gibi. En büyük kazanç da şu: “Bir şey olursa ne yaparız?” sorusuna artık koro halinde cevap verebiliyor olmak.

Ufak ipuçlarını unutmayın. Geçişten önce TTL’i düşürüp sonra geri yükseltmek, zone dosyalarına kısa notlar eklemek, plan çıktısını bir kenara kaydetmek ve DNSSEC’te DS adımlarını aceleye getirmemek. Takıldığınız yerde nefes alıp, daha sade bir çözümle yola devam etmek. Umarım bu rehber, sizin için de “bir daha o panik olmaz” dedirten bir yol haritasına dönüşür. Sorularınız olursa not alın, bir sonraki yazıda derleyip yanıtlayalım. Şimdilik benden bu kadar; kahve molasında görüşürüz.