Recursive DNS Sunucuları Nasıl Yedekli Çalıştırılır?
Recursive resolver (özyinelemeli DNS çözümleyicisi), istemciden aldığı alan adı sorgusunu önbellekten yanıtlar veya DNS hiyerarşisindeki gerekli sunuculara ulaşarak sonucu bulur. Sorguları başka bir recursive resolver hizmetine de iletebilir. İç ağda bu işi yapan tek sunucu varsa sunucu veya ona ulaşan ağ yolu arızalandığında yeni DNS sorguları yanıtsız kalabilir. Yalnız upstream (üst DNS) hizmeti kesilmişse sunucu önbelleğindeki geçerli yanıtları sunabilir; ancak dışarıdan yeni bilgi alması gereken sorgular başarısız olabilir.
Yedeklilik bu nedenle ikinci bir DNS adresi yazmaktan ibaret değildir. Birden fazla recursive resolver sunucusunun bağımsız hata alanlarında çalışması, aynı erişim ve doğrulama politikalarını uygulaması, adreslerinin istemcilere doğru yöntemle dağıtılması ve gerçek sorgularla izlenmesi gerekir.
Recursive resolver sunucularının yedekliliği, yetkili DNS yedekliliğinden farklıdır. Yetkili DNS için ikincil sunucu, NS delegasyonu veya bölge aktarımı ayrı bir mimariye aittir ve bu planın yerine geçmez.
Recursive Resolver Sunucularını Yedekli Çalıştırmanın Temel Koşulları
- En az iki recursive resolver sunucusunu aynı güç, sanallaştırma, güvenlik duvarı ve ağ yolu arızasından birlikte etkilenmeyecek hata alanlarına yerleştirin.
- Erişim denetimi, yerel bölgeler, yönlendirme kuralları, DNSSEC doğrulaması ve kayıt politikalarını bütün düğümlerde eş tutun.
- İstemcilere birden fazla DNS sunucusu adresi dağıtın veya sağlık denetimiyle çalışan düğümlere yönlendiren bir sanal IP adresi gibi ortak erişim yöntemi kullanın. Geçiş davranışını gerçek istemcilerde doğrulayın.
- Tam recursive DNS çözümlemesi veya DNS forwarder (DNS yönlendirici) kullanımı için üst DNS bağımlılıklarını ve UDP ile TCP ağ erişimini ayrı ayrı denetleyin.
- Yedek sunucuya geçiş kadar kapasite, izleme, bakım, kontrollü geri dönüş ve yeniden kurulum adımlarını da önceden belgeleyin.
Recursive Resolver Sunucularında Bağımsız Hata Alanları
İki DNS sunucusunun farklı IP adreslerine sahip olması tek başına hata toleransı oluşturmaz. Aynı fiziksel sunucuda çalışan iki sanal makine, aynı anahtar üzerinden geçen iki bağlantı veya aynı güvenlik duvarına bağlı iki düğüm ortak bir arızayla birlikte devre dışı kalabilir.
Recursive Resolver Sunucularının Ortak Altyapı Bağımlılıkları
Her recursive resolver düğümü için yalnız sunucuyu değil, hizmet zincirinin tamamını kaydedin. Güç kaynağı, hipervizör, depolama, anahtar, yönlendirici, güvenlik duvarı, NAT çıkışı, internet bağlantısı, zaman eşitleme kaynağı, yapılandırma deposu ve varsa üst recursive resolver hizmeti bu zincirin parçalarıdır.
Amaç, her bileşeni bütünüyle çoğaltmak değil, kritik tek hata noktalarını belirlemektir. Örneğin farklı sunucularda çalışan iki recursive resolver sunucusu aynı çıkış güvenlik duvarından internete ulaşıyorsa sunucu arızasına karşı dayanıklıdır, ancak güvenlik duvarı veya çıkış hattı arızasına karşı değildir.
DNS Sunucusu Arızasında Kalan Düğümlerin Kapasitesi
Normal yükün iki düğüme bölünmesi, düğümlerin her birinin tek başına yükü taşıyabileceği anlamına gelmez. En yoğun saatlerde bir DNS sunucusu devre dışı kaldığında kalan düğümün sorgu hızı, eş zamanlı istekler, TCP bağlantıları, önbellek için gereken bellek ve üst DNS trafiği bakımından kabul edilebilir sınırlar içinde kalması gerekir.
Bu sınırlar için evrensel bir sayı yoktur. Eşikleri gerçek trafik ölçümüne, büyüme payına ve kurumun hizmet hedefine göre belirleyin; bakım sırasında beklenen tek düğüm yükünü ayrıca test edin.
İstemcilere Birden Fazla DNS Sunucusu Adresi Dağıtma
DHCPv4, DHCPv6 ve IPv6 yönlendirici duyuruları istemcilere birden fazla DNS sunucusu adresi sağlayabilir. Bu adreslerin sırası tercih bilgisi taşıyabilse de istemcinin ne zaman diğer adrese geçtiği, sorguları sırayla mı yoksa paralel mi gönderdiği ve başarısız sunucuyu ne kadar süreyle geri planda tuttuğu işletim sistemi, istemcideki DNS bileşeni ve ağ yapılandırmasına göre değişebilir.
Bu nedenle “birinci adres sürekli kullanılır, ikincisi yalnız arızada devreye girer” varsayımıyla tasarım yapılmamalıdır. Bazı istemciler ikinci DNS sunucusunu beklenenden erken kullanabilir; bazıları ise ilk sunucunun yanıt vermemesini belirli bir zaman aşımı boyunca beklediği için kullanıcı gecikme hissedebilir.
DNS Sunucusu Adreslerinin Bütün İstemcilere Ulaşması
Yalnız ana DHCP kapsamını güncellemek yeterli olmayabilir. Statik adresli sunucular, ağ cihazları, VPN istemcileri, misafir ağları, kablosuz denetleyiciler, konteyner platformları ve IPv4 ile IPv6 yapılandırmaları ayrı kaynaklardan DNS bilgisi alabilir.
- Her istemci grubunun aldığı DNS sunucusu adreslerini ve adres sırasını doğrulayın.
- DHCP sunucusunun IP adresini cihaz için ayırdığı süre (DHCP kiralama süresi) dolmadan cihaz kullanım süresini uzatmayı dener. Başarılı yenilemede yeni DNS adreslerini de alabilir; sürenin dolmasını beklemek gerekmez. Henüz yeni ayarları almayan veya DNS adresleri elle tanımlanmış cihazları belirleyin.
- Çoklu ağ arayüzüne sahip cihazlarda kurumsal, VPN ve genel DNS bilgilerinin hangi ad alanları için kullanıldığını test edin.
- Arıza senaryosunu farklı işletim sistemi ve cihaz türlerinde gerçek sorgularla gözlemleyin.
Yedek DNS Sunucularında Yapılandırma ve Politika Uyumu
Yedek recursive resolver sunucusu, aynı istemci grubu için gerekli yerel adları çözemiyor veya farklı erişim ve doğrulama politikaları uyguluyorsa çalışan sunucunun yerini tam olarak tutmaz. Önbelleklerin farklı zamanlarda yenilenmesi ya da dış DNS hizmetinin konuma göre yanıt vermesi ise tek başına yapılandırma hatası değildir. Özellikle yerel ad alanları, koşullu yönlendirme, erişim denetimi ve filtreleme kuralları eşleşmediğinde arıza anında yalnız bazı uygulamalar çalışabilir.
DNS Düğümlerinde Ortak Yapılandırma Ayarları
- Dinleme adresleri, istemci ağları ve recursive sorgu kabul eden erişim listeleri
- Yerel bölgeler, yerel kayıtlar, bölünmüş DNS görünümleri ve koşullu yönlendirme kuralları
- DNSSEC doğrulama durumu, güven çıpası yönetimi ve doğru sistem saati
- Üst recursive resolver adresleri, tercih sırası, şifreli DNS kullanılıyorsa kimlik doğrulama bilgileri
- Yanıt filtreleri, engelleme politikaları, gizlilik ayarları ve günlükleme düzeyi
- UDP ve TCP desteği, kaynak sınırları, önbellek ayarları ve hata yanıtı davranışı
Yapılandırmayı tek bir sürümlü kaynaktan üretmek ve değişiklikleri otomatik testlerden geçirerek dağıtmak, elle yapılan değişikliklerden doğan farkları azaltır. Yeni yapılandırma önce bir düğümde denenebilir; ancak diğer düğüme aktarılmadan önce yerel adlar, DNSSEC ve erişim politikaları bakımından eşdeğer olduğu doğrulanmalıdır.
Önbelleklerin birebir kopyalanması çoğu mimaride gerekli değildir. Buna karşılık yeni başlatılan veya uzun süre devre dışı kalan bir düğümün soğuk önbellekle daha fazla üst DNS sorgusu üretebileceği, kapasite ve geri dönüş planında hesaba katılmalıdır.
Üst DNS Hizmeti ve Ağ Yolu Bağımlılıkları
Tam recursive DNS çözümlemesi yapan sunucular kök, üst düzey alan adı ve yetkili sunuculara erişebilmelidir. Güvenlik duvarında yalnız UDP/53 erişiminin açık olması yeterli değildir; büyük veya kesilmiş yanıtların yeniden alınabilmesi için TCP/53 erişimi de çalışmalıdır.
DNS forwarder kullanan mimaride her yerel düğüm çalışsa bile bütün sorgular aynı tek upstream resolver (üst DNS çözümleyicisi) hizmetine veya aynı çıkış hattına gidiyorsa bu bağımlılık yeni tek hata noktasıdır. Birden fazla üst recursive resolver hizmeti kullanmak, ancak bu hizmetlerin ağ yolu ve işletim altyapısı bakımından gerçekten bağımsız olması halinde yedekliliği artırır.
DNS Düğümleri Arasında Farklı Çözümleme Politikaları
Bir düğümün tam recursive DNS çözümlemesi yapması, diğerinin genel bir DNS hizmetine sorgu ileten DNS forwarder kullanması arıza anında farklı filtreleme, gizlilik, DNSSEC veya içerik yönlendirme sonuçları doğurabilir. Kurum bu farkı bilinçli bir felaket kurtarma seçeneği olarak kabul ediyorsa ağ yönetim ekibi kaybedilebilecek özellikleri belgelemelidir. Normal yedeklilikte iki düğüm aynı erişim, doğrulama ve filtreleme politikasını izlemelidir.
Gerçek DNS Sorgularıyla Sağlık Denetimi
DNS sunucusu yazılımının çalışması veya 53 numaralı porta bağlantı kurulabilmesi yalnız temel erişilebilirliği gösterir. Sağlık denetimi, sunucunun istemci ağından recursive sorgu kabul ettiğini, yanıt ürettiğini ve kurumun erişim, doğrulama ve filtreleme kurallarını uyguladığını ölçmelidir.
Aşağıdaki denetimler, farklı arıza türlerini birbirinden ayırmak için birlikte değerlendirilebilir.
| Denetim | Yakaladığı Sorun | Değerlendirme |
|---|---|---|
| Dış alan adına recursive sorgu | Hizmet, ağ yolu, recursive DNS çözümlemesi ve üst DNS erişimi | Yanıt kodu, RD/RA işaretleri, süre ve beklenen kayıt türü birlikte kontrol edilir. |
| Yerel alan sorgusu | Yerel bölge, koşullu yönlendirme ve politika eşliği | Her düğümün aynı istemci grubuna aynı beklenen yanıtı vermesi aranır. |
| DNSSEC doğrulama senaryosu | Güven çıpası, saat veya doğrulama zinciri sorunu | Geçerli imzalı yanıtların kabulü ve doğrulama hatalarının politika gereği reddi izlenir. |
| UDP ve TCP sorguları | Güvenlik duvarı, durum tablosu veya taşıma yolu engeli | Her iki taşımanın istemci ve dış sorgu yönlerinde çalıştığı doğrulanır. |
| Gecikme ve hata oranı | Kısmi arıza, üst DNS hizmetinin yavaşlığı veya kapasite baskısı | Tek ölçüm yerine zaman içindeki temel değer ve hizmet hedefiyle karşılaştırılır. |
| Kaynak ve kuyruk ölçümleri | CPU, bellek, soket, eş zamanlı sorgu veya TCP bağlantı doygunluğu | Tek düğüm kaybında kalan kapasiteyi tüketmeden önce alarm üretilir. |
Sentetik denetimi yalnız tek bir dış alan adına bağlamak yeni bir bağımlılık oluşturur. Birden fazla kararlı dış hedef, kuruma ait kontrollü bir test kaydı ve yerel ad alanı sorgusu kullanmak, dış dünya arızasıyla yerel recursive resolver sunucusu arızasını ayırmayı kolaylaştırır.
Alarm eşikleri bütün ağlar için aynı olamaz. Önce normal çalışma dönemindeki SERVFAIL ve zaman aşımı oranını, yanıt sürelerinin dağılımını, sorgu hacmini, önbellek başarısını ve kaynak kullanımını ölçün. Alarm kurallarını bu değerlerden anlamlı sapmaları yakalayacak biçimde tanımlayın.
DNS Sunucularında Bakım ve Arıza Sonrası Geri Dönüş
Yedek DNS sunucusuna geçiş planı yalnız arızalı düğümün devreden çıkmasını değil, bakım ve geri dönüş sırasında oluşabilecek yük değişimini de kapsamalıdır. İstemcilerin dağıtılmış DNS adreslerini ne kadar süre tuttuğu değişebileceği için bir adresi DHCP'den kaldırmak bütün cihazların onu hemen bırakacağı anlamına gelmez.
- Bakım öncesinde kalan düğümlerin tek başına beklenen yükü taşıyabildiğini doğrulayın.
- İstemci ve ağ gruplarının iki recursive resolver sunucusuna da erişebildiğini kontrol edin.
- Bir düğümü kontrollü biçimde hizmetten çıkarın; zaman aşımı, hata oranı ve kalan düğüm kapasitesini izleyin.
- Bakım tamamlandığında düğümü önce doğrudan sağlık testlerinden geçirin; yerel kayıt, DNSSEC, UDP, TCP ve üst DNS erişimini doğrulayın.
- Düğümü trafiğe kademeli olarak döndürün ve soğuk önbelleğin oluşturabileceği geçici üst DNS yükünü gözlemleyin.
- Olay kaydı kapatılmadan önce arıza nedenini ve yapılan değişiklikleri belgeleyip iki düğümün yapılandırma eşliğini yeniden karşılaştırın.
Otomatik sağlık denetimi kullanan bir sanal IP adresi, yük dengeleyici veya aynı adresi farklı noktalardan duyuran anycast tasarımı varsa geri alma ve yeniden duyurma koşulları o katmanda tanımlanır. Doğrudan birden fazla recursive resolver sunucusu adresi dağıtılan ağlarda ise istemci davranışı daha belirleyicidir; bu iki modelde yedek sunucuya geçişin aynı sürede tamamlanması gerekmez.
Recursive Resolver İçin Felaket Kurtarma Hazırlığı
Recursive resolver hizmetinin felaket kurtarma planı, bütün recursive resolver sunucularının veya ortak yönetim altyapısının kaybedildiği durumu ele alır. Amaç yalnız yeni bir sunucu başlatmak değil, aynı erişim sınırları ve doğrulama politikasıyla güvenilir hizmeti geri getirmektir.
- Recursive resolver sunucusunun sürümlü yapılandırmasını, yerel bölge verilerini ve politika dosyalarını erişilebilir bir yedekte tutun.
- Ağ adreslerini, güvenlik duvarı kurallarını, üst DNS bağımlılıklarını ve istemci dağıtım kaynaklarını yeniden kurulum sırasına göre belgeleyin.
- DNSSEC güven çıpasının güncel olduğunu ve kullanılan otomatik güncelleme mekanizmasının gerekli yazma erişimine sahip bulunduğunu doğrulayın.
- Şifreli DNS veya yönetim arayüzü kullanılıyorsa gerekli sertifika ve kimlik bilgileri için ayrı kurtarma prosedürü oluşturun.
- Kurtarma süresi hedefini, kabul edilebilir yapılandırma kaybını ve geçici kapasite sınırını hizmet sahibiyle belirleyin.
- Yedekten kurulum testini üretim arızasını beklemeden, izole bir ortamda düzenli olarak tekrarlayın.
