Sunucunuz çalışıyor, siteniz sağlam, hosting hesabınızda hiçbir sorun yok. Ama kimse sitenize ulaşamıyor — çünkü alan adınızı çözümleyen sunucular yanıt vermiyor.
Bu yazı, DNS katmanındaki yedekliliği ele alıyor.
Gözden Kaçan Tek Arıza Noktası
Altyapı planlaması genellikle DNS'i atlar:
- Sunucu yedekli. Birden fazla makine.
- Veritabanı yedekli. Çoğaltma var.
- Ağ yedekli. İki sağlayıcı.
- DNS? Genellikle tek sağlayıcı.
Dördüncü satırdaki boşluk her şeyi geçersiz kılar: alan adınız çözümlenemiyorsa, arkasındaki tüm yedekli altyapının hiçbir anlamı kalmaz — kullanıcı sunucunuza ulaşamaz bile.
DNS, zincirin ilk halkasıdır. Orada bir kopma, geri kalan her şeyi erişilemez kılar.
Bu risk düşük olasılıklıdır ama gerçekleştiğinde etkisi tamdır. Büyük DNS sağlayıcılarında yaşanan kesintiler, aynı anda çok sayıda siteyi erişilemez hâle getirmiştir.
Zaten Yedekli Değil mi?
Her alan adının birden fazla ad sunucusu vardır ama bu yeterli olmayabilir:
| Durum | Koruma seviyesi |
|---|---|
| Aynı sağlayıcının iki sunucusu | Sunucu arızasına karşı |
| Aynı sağlayıcı, farklı lokasyon | Lokasyon arızasına karşı |
| Farklı iki sağlayıcı | Sağlayıcı kesintisine karşı |
Aradaki fark kritiktir: aynı sağlayıcının dört ad sunucusu, o sağlayıcı genelinde bir sorun yaşandığında hep birlikte devre dışı kalır.
Yaşanan büyük kesintilerin çoğu tek bir sunucunun arızası değil, sağlayıcı çapında bir sorundu. Bu senaryoya karşı tek koruma üçüncü satırdır.
İkincil DNS Nasıl Kurulur?
İki sağlayıcı ile çalışmanın yolları:
- Bölge aktarımı ile eşitleme. Klasik yöntem.
- API ile çift yazma. Her iki tarafa da yazılır.
- Yapılandırma dosyasından dağıtım.
Birinci yöntem en az bakım gerektirendir: birincil sunucuda yapılan değişiklik, bölge aktarımı sayesinde ikincil sağlayıcıya otomatik yayılır ve kayıtları iki yerde ayrı ayrı güncellemeniz gerekmez.
Bu yöntem için her iki sağlayıcının da bölge aktarımını desteklemesi gerekir. Tüm sağlayıcılar bunu sunmaz.
İkinci yöntem daha esnektir ama otomasyon yazmayı gerektirir. Kayıt değişiklikleri bir betik aracılığıyla her iki tarafa da uygulanır.
Üçüncü yöntem ise altyapıyı kod olarak yöneten ekipler için doğaldır. Tek bir kaynak dosyadan iki sağlayıcıya dağıtım yapılır.
Kayıt Kuruluşu Tarafında Tanımlama
İkincil sağlayıcı kurulduktan sonra:
- Her iki sağlayıcının sunucularını da tanımlayın.
- Genellikle dört ad sunucusu olur.
- Sıralamanın önemi yoktur.
- Tanım kayıt kuruluşunda yapılır.
Üçüncü madde sık sorulan bir sorunun cevabıdır: çözümleyiciler ad sunucularını sırayla denemez, aralarından seçim yapar — bu nedenle "birincil" ve "ikincil" ayrımı çözümleme açısından anlamsızdır.
Her iki sağlayıcı da aynı sıklıkta sorgu alır. Bu, ikincil sağlayıcının da gerçekten güncel veri tutması gerektiği anlamına gelir.
Dördüncü madde ise değişikliğin nerede yapıldığını netleştirir. Ad sunucusu tanımı DNS panelinde değil, alan adının kayıt kuruluşu panelinde yapılır.
Tutarlılık Riski
İki sağlayıcı kullanmanın kendine özgü riski vardır:
| Risk | Sonuç |
|---|---|
| Eşitleme bozulur | Farklı yanıtlar döner |
| Bir tarafa elle kayıt eklenir | Ayrışma başlar |
| Özel kayıt türleri desteklenmez | Kısmi çalışma |
| DNSSEC yapılandırması karmaşıklaşır | Ek dikkat gerekir |
Birinci satır sinsi bir arıza üretir: eşitleme sessizce bozulduğunda site çalışmaya devam eder, ama kullanıcıların bir kısmı eski kayıtları alır ve sorun aralıklı görünür.
Bu nedenle iki sağlayıcının aynı yanıtı verdiği düzenli olarak kontrol edilmelidir.
Üçüncü satır ise sağlayıcıya özgü kayıt türlerini etkiler. Kökte takma ad davranışı gibi standart dışı özellikler her sağlayıcıda bulunmaz.
İzleme Kurmak
Yedeklilik ancak izlenirse işe yarar:
- Her ad sunucusunu ayrı sorgulayın.
- Yanıtları karşılaştırın.
- Farklılık olursa alarm üretin.
- Yanıt süresini de ölçün.
Birinci madde standart izleme araçlarının yapmadığı şeydir: sıradan bir site izleme servisi alan adını normal yolla çözümler ve hangi ad sunucusundan cevap aldığını umursamaz — bir sunucunun bozuk olduğunu fark etmez.
Ad sunucusu bazlı izleme, bu boşluğu kapatır ve sorunu kullanıcılardan önce görmenizi sağlar.
Dördüncü madde ise performans tarafıdır. Yavaş yanıt veren bir ad sunucusu, sayfa açılış süresini doğrudan uzatır.
Kimin İhtiyacı Var?
- Kesintinin maliyeti yüksekse. Gerekli.
- E-ticaret veya çevrimiçi hizmet. Önerilir.
- Kurumsal API sunuyorsanız. Önerilir.
- Kişisel blog veya tanıtım sitesi. Gerekmez.
Dördüncü madde dürüst bir değerlendirmedir: tek başına iki DNS sağlayıcısı yönetmek ek karmaşıklık getirir ve düşük riskli bir site için bu karmaşıklık faydadan büyüktür.
Bu durumda daha basit bir önlem yeterlidir: güvenilir bir DNS sağlayıcısı seçmek ve ad sunucularının farklı lokasyonlarda olduğunu doğrulamak.
Alan adınızın hangi ad sunucularını kullandığını ve kaç farklı sağlayıcıya dağıldığını görmek için domain kayıt hizmetleri kapsamındaki sorgulama ekranından kontrol edebilirsiniz.
Sonuç
DNS, altyapı planlamasında en sık atlanan tek arıza noktasıdır — alan adınız çözümlenemiyorsa arkasındaki tüm yedekli altyapının anlamı kalmaz. Aynı sağlayıcının dört ad sunucusu, o sağlayıcı çapında bir sorunda hep birlikte devre dışı kalır; gerçek koruma farklı iki sağlayıcı kullanmaktır. İki sağlayıcı kullanıyorsanız tutarlılığı izleyin: eşitleme sessizce bozulduğunda site çalışmaya devam eder ama kullanıcıların bir kısmı eski kayıtları alır. Düşük riskli siteler için bu karmaşıklık gerekli değildir.
Sıkça Sorulan Sorular (SSS)
Zaten iki ad sunucum var, yeterli değil mi?
Aynı sağlayıcıya aitse yalnızca sunucu arızasına karşı korur. Yaşanan büyük kesintilerin çoğu tek sunucu arızası değil, sağlayıcı çapında sorunlardı — bu senaryoda aynı sağlayıcının dört sunucusu da birlikte devre dışı kalır. Gerçek koruma farklı iki sağlayıcıdır.
İki sağlayıcıyı nasıl eşitlerim?
En az bakım gerektiren yöntem bölge aktarımıdır: birincil sunucudaki değişiklik ikincile otomatik yayılır ve kayıtları iki yerde ayrı güncellemeniz gerekmez. Her iki sağlayıcının da bunu desteklemesi gerekir. Alternatifler API ile çift yazma veya tek kaynak dosyadan dağıtımdır.
Hangisi birincil olacak?
Çözümleme açısından fark etmez. Çözümleyiciler ad sunucularını sırayla denemez, aralarından seçim yapar — her iki sağlayıcı da aynı sıklıkta sorgu alır. Bu, ikincil sağlayıcının da gerçekten güncel veri tutması gerektiği anlamına gelir.
Normal site izlemem yeterli mi?
Hayır. Sıradan bir izleme servisi alan adını normal yolla çözümler ve hangi ad sunucusundan cevap aldığını umursamaz — bir sunucunun bozuk olduğunu fark etmez. Her ad sunucusunu ayrı sorgulayan ve yanıtları karşılaştıran bir izleme kurmanız gerekir.
