Yetkili DNS'te Yüksek Erişilebilirlik Nasıl Planlanır?

Sesli Dinle — Makale

Yetkili DNS hizmetinde yüksek erişilebilirlik, internete açık bir DNS bölgesinin tek bir sunucu, ağ, veri merkezi veya yönetim hatası yüzünden bütünüyle yanıtsız kalmamasını hedefler. Bunun için aynı bölgeyi birden fazla yetkili sunucuda yayımlamak, bu sunucuları bağımsız hata alanlarına dağıtmak ve her birinin aynı ve doğru veriyi sunduğunu sürekli doğrulamak gerekir.

Yalnızca bölgenin yetkili sunucularını gösteren NS kayıtlarının sayısını artırmak yeterli değildir. Sunucular aynı ağ bağlantısına, aynı kontrol paneline veya aynı hatalı bölge kaynağına bağlıysa ortak bir arıza hepsini aynı anda etkileyebilir.

Kapsamlı bir plan, sunucu yerleşimini, üst bölgedeki delegasyonu, SOA ve NS tutarlılığını, DNSSEC bağımlılıklarını, dış izlemeyi, kapasiteyi ve geri dönüş adımlarını tek işletim modeli içinde ele alır.

Yetkili DNS'te Yüksek Erişilebilirlik Planının Temeli

• İnternete açık bölgeyi en az iki erişilebilir yetkili sunucuda yayımlayın; çoğu kurumsal planda üç sunucu, bakım sırasında bir sunucunun devre dışı kalmasına daha fazla tolerans sağlar.
• Sunucuları yalnız farklı makinelerde değil, mümkün olduğunca farklı ağ, tesis, enerji ve yönetim hata alanlarında konumlandırın.
• Üst bölgedeki delegasyon NS kayıtlarını, bölge tepesindeki NS kayıtlarını ve üst bölgede tutulan gerekli glue kayıtlarını birbiriyle tutarlı tutun.
• Tüm yetkili sunucuların aynı bölge sürümünü ve geçerli DNSSEC verisini sunduğunu doğrudan sorgularla doğrulayın.
• Değişiklik, izleme, kapasite, felaket kurtarma ve geri dönüş süreçlerini üretici bağımsız bir çalışma planına bağlayın.

Yetkili DNS ve Recursive Resolver (Özyinelemeli DNS Çözümleyicisi) Sürekliliği

Yetkili DNS sunucusu, yönettiği bölgeye ilişkin DNS sorgularını kendi bölge verisiyle yanıtlar. Recursive resolver ise istemci adına DNS hiyerarşisini takip eder, farklı yetkili sunuculara sorgu gönderir ve sonuçları önbelleğe alır.

Kurum içinde çalışan recursive resolver sistemlerinin, DNS forwarder (DNS yönlendirici) hizmetlerinin ve istemci DNS ayarlarının yedekliliği, kamusal bölgenin yetkili DNS sürekliliğinden farklıdır. Bu bileşenlerin çalışması, internete açık yetkili bölgenin doğru ve erişilebilir olduğu anlamına gelmez.

Ortak Arıza Riskini Azaltan Hata Alanı Ayrımı

Yüksek erişilebilirlik planı, tek bir arızanın birden fazla yetkili sunucuyu nasıl aynı anda etkileyebileceğini açıkça göstermelidir. Aynı fiziksel ana bilgisayarda çalışan, aynı omurga yönlendiricisine bağlı olan veya aynı yönetim hesabından kontrol edilen sanal makineler ortak arızalardan etkilenebilir.

Aşağıdaki tablo, yaygın ortak arızaları ve bunlara karşı kurulabilecek üretici bağımsız ayrımları gösterir.

Sunucu Sayısının Risklere Göre Belirlenmesi

Sunucu sayısı tek başına erişilebilirlik ölçüsü değildir. İki sunucu temel yedeklilik sağlayabilir; çoğu kurumsal DNS bölgesi için üç sunucu, bakım ve tekil arıza sırasında daha fazla hareket alanı verir. Daha fazla sunucu ise ancak yeni bir hata alanı ayrımı veya kapasite katkısı getiriyorsa anlamlıdır; aksi halde yapılandırma sapması ve izleme yükü artar.

Listelenen her NS adı, internet üzerinden erişilebilir bir IPv4 veya IPv6 adresine çözülmeli; bu adresteki DNS sunucusu ilgili bölge için yetkili yanıt vermelidir. Güvenlik duvarı tarafından engellenen, yalnız kurum içinden erişilen veya artık hizmet vermeyen bir sunucuyu gösteren NS kaydı yedeklilik sağlamaz.

Birincil ve İkincil Sunucu Rollerinin Kurulması

En sade üretici bağımsız model, tek bir doğrulanmış bölge kaynağından birden fazla ikincil yetkili sunucuya veri dağıtmaktır. Birincil sunucunun delegasyondaki NS listesinde yer alması zorunlu değildir; gizli birincil yaklaşımı, yazma ve imzalama işlemlerini dışarıdan gelen sorgu trafiğinden ayırabilir.

Bu modelde hatalı veri tüm ikincillere hızla yayılabilir. Birincil sunucu doğrulanmış tek kaynak olsa bile hizmetin tek hata noktası olmamalıdır; bölge dosyası veya eşdeğer yapılandırma sürümlenmeli, değişiklik öncesinde doğrulanmalı ve geri yüklenebilir olmalıdır.

Anycast'in Tek Başına Gideremediği Yetkili DNS Riskleri

Anycast, aynı yetkili sunucu adresini birden fazla ağ noktasından duyurarak sorguları farklı hizmet noktalarına dağıtabilir. Bu yaklaşım coğrafi erişim ve kapasite için yararlı olabilir, ancak bozuk bölge verisi, yanlış DNSSEC imzası veya ortak kontrol düzlemi hatası bütün noktalara aynı anda yayılabilir.

Bu nedenle anycast, bağımsız NS hizmetleri ve veri doğrulama süreçlerinin yerine geçmez. Dağıtım biçimi seçilirken ağ yolunun kaybı kadar ortak yazılım, otomasyon ve yönetim arızaları da hesaba katılmalıdır.

Delegasyon ile Bölge Verisinin Tutarlılığı

Recursive resolver sistemleri bölgeye üst bölgedeki delegasyon üzerinden ulaşır. Yetkili sunucuların bölgeyi doğru sunması, üst bölgedeki NS ve adres bilgilerinin yanlış veya eski olması halinde yeterli değildir.

Üst Bölge, NS ve Glue Kayıtlarının Eşleşmesi

Alan adının üst bölgesindeki delegasyon NS kayıtları ile bölge tepesinde yayımlanan NS kayıtları aynı aktif sunucu kümesini göstermelidir. Bir sunucunun adı delegasyon yapılan bölgenin altında bulunuyorsa, çözümleme döngüsünü kırmak için üst bölgede gerekli glue A veya AAAA kayıtları bulunmalı ve gerçek sunucu adresleriyle eşleşmelidir.

Üst bölgedeki NS kayıtlarında listelenen sunucu ilgili bölge için yetkili değilse sorgular yanlış sunucuya yönlendirilir. Bu durum geleneksel olarak lame delegation diye adlandırılır; terim erişim sorunları için de kullanıldığından, izleme raporunda sunucuya erişilemediği mi yoksa sunucunun bölge için yetkili olmadığı mı açıkça belirtilmelidir. Değişiklik planı, alan adı kayıt kuruluşu veya üst bölge panelindeki işlemleri yetkili bölge değişikliklerinden ayrı bir onay ve doğrulama adımıyla izlemelidir.

SOA Seri Numarası ve Bölge Verisinin Dağıtımı

İkincil sunucular, bölgenin değişip değişmediğini SOA seri numarası üzerinden değerlendirir. Her yayımlanan sürümün seri numarası, DNS seri numarası aritmetiğine göre mevcut sürümden daha yeni olmalıdır. Eski içeriğe geri dönerken de eski seri numarasını kullanmak yerine doğru içeriği daha yeni kabul edilen bir seri numarasıyla yayımlayın. Bu karşılaştırma sıradan sayısal büyüklükle aynı değildir; 32 bitlik alanın sonuna ulaşıldığında değer başa dönebilir.

Standart aktarım modelinde AXFR tam bölge aktarımı, IXFR değişen kayıtların aktarımı, DNS NOTIFY ise ikincilleri yeni SOA sürümünü daha erken kontrol etmeye yönlendirmek için kullanılabilir. Aktarım yalnız yetkili ikincil sunucularla sınırlandırılmalıdır. Aktarımın tamamlanması, sunulan kaydın doğru olduğunu kanıtlamaz; bu nedenle içerik de karşılaştırılmalıdır.

Birden fazla yönetilen DNS hizmetinin standart bölge aktarımı yerine ayrı API veya panellerle güncellendiği modelde, yönetilen bölge kayıtlarının tüm DNS sağlayıcılarına aynı değişiklik planıyla uygulanması gerekir. İşlem kimliği, beklenen seri veya sürüm, değişiklik özeti ve DNS sağlayıcıları arasındaki kayıt farkı izlenmeden yapılan paralel güncellemeler sessiz tutarsızlık üretebilir.

DNSSEC Zincirini Yetkili Sunucularda Geçerli Tutma

DNSSEC, DNS verisinin kaynağını ve bütünlüğünü doğrulamaya yardımcı olur; gizlilik sağlamaz. İmzalı bir bölgede yalnız kayıtların erişilebilir olması yetmez: DNSKEY, RRSIG ve üst bölgedeki DS verileri birlikte geçerli bir doğrulama yolu oluşturmalıdır.

Tek imzalayıcıdan ikincillere dağıtım, işletim açısından daha sade bir başlangıçtır. Birden fazla DNS sağlayıcısının bağımsız imza ürettiği çoklu imzalayıcı modelinde DNSKEY ve DS kümeleri, anahtar geçişleri ve imza süreleri DNS sağlayıcıları arasında koordineli yönetilmelidir; aksi halde bir yetkili sunucudan gelen yanıt doğrulanırken diğerinden gelen yanıt hatalı kabul edilebilir. Bağımsız imzalayıcıların RRSIG kayıtlarının birebir aynı olması gerekmez; önemli olan her sunucunun yanıtının geçerli bir DNSSEC zinciriyle doğrulanabilmesidir.

İzleme, yaklaşan RRSIG süre sonlarını, ikincillerin güncel imzalı bölgeyi alıp almadığını ve SOA kaydındaki expire süresi dolmadan önce müdahale edilebilecek zamanı kontrol etmelidir. Expire süresi, ikincil sunucunun güncelleyemediği bölgeyi ne zaman sunmayı bırakacağını belirler. Sunucuların saat eşitlemesi de izlenmelidir; yanlış saat, imzalama ve doğrulama işlemlerini bozabilir.

Yetkili DNS Sunucularını Doğrudan ve Dışarıdan İzleme

Yüksek erişilebilirlik, yalnız arıza olduğunda diğer sunucunun yanıt vermesi değildir. İzleme sistemi, her sunucunun doğru veriyi beklenen protokoller ve adres aileleri üzerinden sunabildiğini sürekli kontrol etmelidir.

İzleme, yalnız genel kullanıma açık bir recursive resolver üzerinden alan adını sorgulamakla sınırlı kalmamalıdır. Delegasyonda listelenen her yetkili sunucu, bölge tepesindeki SOA ve NS kayıtları, bölgenin kritik kayıtları ve varsa DNSSEC verisi için doğrudan sorgulanmalı; bu sorgularda recursive çözümleme istenmemelidir. NS adlarının A veya AAAA kayıtları ise bu adlardan sorumlu yetkili sunucularda ayrıca kontrol edilmeli, gerekli glue adresleri üst bölgedeki delegasyon yanıtından doğrulanmalıdır. NS adı başka bir bölgede bulunuyorsa, bu adres kayıtlarını denetlenen bölgenin sunucusundan yetkili yanıtla almak mümkün olmayabilir.

Kontroller en az iki bağımsız dış ağ noktasından yapılmalı; UDP ve TCP üzerinden DNS erişimi, yayımlanmış IPv4 ve IPv6 adresleri, yanıt kodu, yetkili yanıt işareti, SOA seri numarası ve beklenen kayıt içeriği izlenmelidir. TCP 53 erişimi yalnız bölge aktarımı için değil, büyük veya kesilmiş DNS yanıtlarının yeniden alınabilmesi için de gereklidir.

Gecikme ve hata oranı, kullanıcı deneyimini ve kapasite baskısını anlamaya yardımcı olur; ancak tek bir ölçüm noktası küresel erişilebilirliği veya SLA’ya (Service Level Agreement) uyumu kanıtlamaz. Alarm eşikleri bölgenin normal trafik ve yanıt boyutu dağılımına göre belirlenmelidir.

Yetkili DNS'te Arıza Anındaki Sorgu Yüküne Göre Kapasite

Her yetkili sunucu, başka bir sunucu veya hizmet noktası devre dışı kaldığında kendisine yönelen ek sorgu yükünü taşıyabilmelidir. Normal sorgu hacmi, ani yükselişler, DNSSEC nedeniyle büyüyen yanıtlar, TCP bağlantıları ve olumsuz yanıtların oranı ayrı ayrı gözlenmelidir.

Oran sınırlama ve saldırı azaltma mekanizmaları meşru recursive resolver trafiğini engellemeyecek biçimde test edilmelidir. Kapasite hedefi yalnız işlemci kullanımına göre değil; ağ paket hızı, bant genişliği, bağlantı tabloları, yanıt boyutu ve dış yönlendirme sınırlarıyla birlikte değerlendirilmelidir.

DNS Değişikliklerini Tutarlı Biçimde Yayımlama

DNS değişiklikleri için hazırlanacak yazılı planda şu adımlar bulunabilir:

1. Değişikliğin sahibini, kapsamını, beklenen kaydı ve geri dönüş koşulunu belirleyin.
2. Mevcut bölgeyi, delegasyon NS ve glue durumunu, DNSSEC anahtar ve imza durumunu güvenli biçimde kaydedin.
3. Sözdizimi, kayıt ilişkileri, seri numarası, DNSSEC ve beklenen yanıtları yayın öncesinde doğrulayın.
4. Değişikliği tek doğrulanmış kaynaktan uygulayın; çoklu DNS sağlayıcısı modelinde aynı işlem paketini tüm hedeflere dağıtın.
5. Her yetkili sunucuyu ve üst bölge delegasyonunu dış ağlardan karşılaştırın.
6. Hata halinde doğru içeriği yeni bir sürüm ve uygun seri numarasıyla geri yayımlayın; sonuç doğrulanana kadar yeni değişiklikleri durdurun.

Kayıtların önbellekte tutulabileceği süreyi belirleyen TTL değerini değişiklikten yeterince önce düşürmek, eski kayıtların önbellekte kalma süresini azaltabilir; yetkili NS sunucularının arızaya dayanıklılığını tek başına sağlamaz. NS seçimi ve yeniden deneme davranışı recursive resolver uygulamasına, önbelleğe ve erişilebilir ağ yollarına bağlıdır.

Felaket Kurtarma ve Geri Dönüş Planı

Felaket kurtarma planı yalnız sunucu kurulum notlarından oluşmamalıdır. Bölgenin doğrulanmış kaynağı, üst bölge delegasyon bilgileri, gerekli glue adresleri, DNSSEC anahtarlarının güvenli yedeği veya yeniden kurma prosedürü, erişim yetkileri, dış hizmet bağımlılıkları ve sorumlu kişilerin iletişim sırası birlikte tutulmalıdır.

Plan en az şu arıza senaryolarını içermelidir:

• Tek yetkili sunucunun veya tüm bir tesisin erişilemez olması
• Bir internet servis sağlayıcısı, yönlendirme yolu veya adres ailesinin kaybı
• Birincil kaynağa erişilememesi ve ikincillerin SOA kaydındaki expire süresine yaklaşması
• Hatalı kaydın veya bozuk otomasyonun tüm sunuculara yayılması
• DNSSEC imzasının süresinin dolmak üzere olması, yanlış DS kaydı veya başarısız anahtar geçişi
• Yönetim hesabının kilitlenmesi, API anahtarının iptali veya kontrol düzlemi kesintisi

Geri dönüş sırasında önce en az bir doğru yetkili yanıt yolunu koruyun, ardından değişiklikleri dondurun ve bilinen son doğru bölge sürümünü belirleyin. Delegasyonu, bölge verisini ve DNSSEC zincirini aynı kurtarma sırasıyla ele alın; doğrudan yetkili sorgular başarılı olmadan yalnız genel recursive resolver sonuçlarına bakıp işlemi tamamlamayın.

Tatbikatlar üretim kesintisi yaratmadan masa başı senaryo, yalıtılmış kopya ve kontrollü hizmet dışı bırakma aşamalarıyla yapılabilir. Tatbikattan sonra eksik yetkiyi, güncel olmayan belgeyi, erişilemeyen yedeği ve gerçekçi olmayan müdahale süresini ayrı ayrı kaydedin.