DNS kayıtlarındaki bir değişiklik, web sitesi ziyaretçilerinin, e-posta trafiğinin ve diğer ağ isteklerinin hangi hedefe yönlendirileceğini doğrudan etkileyebilir. Bu nedenle DNS kayıt yönetimi yalnız doğru değeri panele girmekten ibaret değildir. Kaydı kullanan hizmetin sorumlusunu, değişikliğin nedenini, onay verecek kişiyi ve hata durumunda kullanılacak geri alma yöntemini de önceden belirleyin.

DNS yanıtlarının kaynağını ve bütünlüğünü dijital imzalarla doğrulamaya yarayan DNSSEC, yanlış girilmiş bir kaydın hizmetiniz için doğru olduğunu göstermez. Hesap güvenliği, değişiklik onayı ve hizmetin çalıştığını kontrol etme adımları, DNSSEC kullanıldığında da gereklidir.

DNS Kayıtlarında Sorumluluk ve Hesap Güvenliği

Her DNS bölgesi için sorumlu bir kişi veya ekip belirleyin. Bu sorumlu, hangi kayıtların hangi hizmetleri desteklediğini, değişiklik taleplerini kimin onaylayacağını ve sorun halinde kimin müdahale edeceğini belirler. Kritik kayıtların sorumluluğunu yalnız “DNS ekibi”ne bırakmak, hizmetin gerçek sahibinin ve teknik bağımlılıkların zamanla unutulmasına neden olabilir.

DNS yönetim paneli, alan adı kayıt kuruluşu hesabı ve kayıtları yazılımla değiştiren API erişimleri için gereken yetkileri ayrı ayrı belirleyin. Kayıt kuruluşu hesabındaki bir değişiklik, alan adının hangi yetkili DNS sunucularına yönlendirildiğini etkileyebilirken DNS sağlayıcısındaki erişim bölge içeriğini değiştirebilir. Aynı kuruluş her iki hizmeti sunuyorsa bile kullanıcı ve otomasyon yetkilerini görevleriyle sınırlandırın. Yönetici hesaplarında parolaya ek bir doğrulama gerektiren çok faktörlü kimlik doğrulama kullanın; mümkün olduğunda değişikliği yapan kişiyle onaylayan kişiyi ayırın ve her hesabın işlem geçmişini izleyin.

  • Ortak yönetici hesabı kullanmayın; her yönetici için ayrı hesap açın.
  • Yalnız kayıtları görüntüleyecek kullanıcıların değişiklik yetkisine ihtiyacı yoktur.
  • API anahtarlarını yalnız gereken bölgeler ve işlemlerle sınırlandırın.
  • Bir çalışan veya yüklenici ayrıldığında ve bir otomasyon devreden çıktığında ilgili erişimleri gecikmeden kaldırın.
  • Acil durum hesaplarını normal işlemlerde kullanmayın ve her kullanımdan sonra işlem geçmişini ayrıca inceleyin.

Yetkileri sınırlandırmak, yalnız hesap sayısını azaltmak anlamına gelmez. Her kullanıcıya yalnız ihtiyaç duyduğu bölgelerde, kayıt türlerinde ve işlemlerde yetki vermek, hatalı veya yetkisiz bir değişikliğin etki alanını küçültür.

Kayıt Envanteri ve Değişiklik Geçmişi

DNS bölgesi yalnız teknik değerlerden oluşan bir liste olarak tutulduğunda eski bir kaydın neden var olduğu anlaşılamaz. Güncel bir envanter, her kaydın hangi hizmete bağlı olduğunu gösterir ve sorumlusu kalmayan kayıtları bulmayı kolaylaştırır.

Envantere en az kayıt adını, türünü, değerini veya hedefini, önbellekten normal kullanım süresini saniye olarak belirten TTL değerini, hizmet sahibini, teknik sorumluyu, kullanım amacını, ortam bilgisini ve bağımlı sistemleri yazın. Geçici kayıtlar için silinme veya yeniden değerlendirme tarihini de belirtin. Envanter iç sistem adlarını ve hizmet ilişkilerini de gösterebileceği için bu listeye erişimi sınırlandırın.

Her değişiklik kaydına talep sahibini, gerekçeyi, risk değerlendirmesini, onaylayan kişiyi, önceki ve yeni değerleri, uygulama zamanını ve doğrulama sonucunu ekleyin. DNS sağlayıcısının işlem günlüğü yararlı olsa da değişikliğin iş gerekçesini tek başına açıklamayabilir. DNS sağlayıcısının işlem kayıtlarını kurumun değişiklik kaydıyla birlikte değerlendirin.

DNS Kayıt Değişikliklerinin Planlanması ve Uygulanması

DNS kaydını değiştirme süreci, yeni değeri panele girmeden önce başlar ve yeni DNS yanıtlarının doğru olduğu ve hizmetin kararlı çalıştığı doğrulandıktan sonra tamamlanır. Süreç aşağıdaki sırayla ilerler:

  1. Talebi tanımlayın: Değiştirilecek kayıtları, hedeflenen sonucu, etkilenen hizmetleri ve işlemin gerekçesini yazın.
  2. Bağımlılıkları inceleyin: Aynı hedefi kullanan diğer alan ve alt alan adlarını, sertifika veya güvenlik kontrollerini, alt alanların yetkili sunucularını belirleyen delegasyonları ve otomasyonları belirleyin.
  3. Teknik ön kontrol yapın: Yeni hedefin çalıştığını, kayıt türünün doğru seçildiğini ve girilecek değerin bu kayıt türünün gerektirdiği biçime uygun olduğunu kontrol edin.
  4. Onayı tamamlayın: Değişikliğin riskine göre hizmet sahibinden veya ikinci bir teknik yetkiliden onay alın.
  5. Önceki durumu saklayın: Eski kayıt değerlerini, TTL bilgilerini ve gerekiyorsa bölge dosyasının yedeğini geri alma sırasında kullanmak üzere kaydedin.
  6. Değişikliği uygulayın: Değişiklik yetkisi bulunan bir hesap veya yalnız gerekli izinlere sahip otomasyon kullanın ve aynı işlem içinde ilgisiz kayıtları değiştirmeyin.
  7. Sonucu doğrulayın: Yetkili DNS sunucularından gelen yanıtları, bölge tutarlılığını, hizmete erişimi ve gerekiyorsa DNSSEC güven zincirini kontrol edin.
  8. Etkisini izleyin: Beklenen geçiş süresi boyunca hata oranlarını ve kullanıcıların karşılaştığı sorunları takip edin; sonuçları değişiklik kaydına ekleyip işlemi kapatın.

Acil değişikliklerde daha hızlı bir onay süreci kullanılabilir, ancak yapılan işlemleri yine kaydedin. Acil işlem tamamlandıktan sonra değişikliğin gerekçesini, uygulanan değerleri, ortaya çıkan etkileri ve kalıcı bir düzeltme gerekip gerekmediğini inceleyin.

DNS Değişikliğinde TTL ve Geri Alma Planı

TTL, bir DNS kaydının normal koşullarda yeniden sorgulanmadan önbellekten kullanılabileceği süreyi saniye cinsinden belirtir. Planlı bir geçişte TTL değerini düşürmek gerekiyorsa bunu asıl kayıt değişikliğinden önce yapın. Düşük değerin bütün yetkili DNS sunucularında yayımlandığını doğruladıktan sonra en az önceki TTL kadar bekleyin. Bu değişiklik, eski yanıtı önbelleğe almış recursive resolver (özyinelemeli DNS çözümleyicisi) hizmetlerindeki mevcut süreyi geriye dönük olarak kısaltmaz.

Bekleme süresi dolunca kayıt değerini değiştirin ve bütün yetkili sunuculardaki sonucu doğrulayın. TTL dolması, kaydın her önbellekte hemen yenilendiği anlamına gelmez; yeniden sorgulama çoğunlukla kayda ihtiyaç duyulduğunda yapılır. Bazı recursive resolver hizmetleri yeni yanıt alamadığında süresi dolmuş veriyi geçici olarak kullanabilir. İstemci ve uygulama önbellekleri de geçişi etkileyebileceği için TTL, bütün kullanıcıların aynı anda yeni kaydı göreceğini garanti etmez.

Sürekli çok düşük TTL kullanmak her ortam için doğru değildir. Düşük değerler yetkili DNS sunucularına gönderilen sorgu sayısını artırabilir ve kısa kesintiler sırasında normal önbellek süresinden yararlanma olanağını azaltabilir. Değişiklik kararlı duruma geldikten ve hızlı geri dönüş ihtiyacı kalmadıktan sonra TTL değerini, hizmetin değişim sıklığına ve kesinti toleransına uygun normal düzeyine geri alın.

Geri alma planını yalnız “eski kaydı geri yazın” ifadesiyle sınırlamayın. Önceki değerleri, önceki TTL değerini, uygulanacak sırayı, geri alma kararını verecek kişiyi ve doğrulama adımlarını açıkça yazın. Eski değerin yeniden yayımlanması önbellekteki mevcut yanıtları anında değiştirmez; bu nedenle önceki kayda dönüş her kullanıcıya aynı anda yansımayabilir.

Yetkili DNS Sunucularında Tutarlılık ve Kesintiye Karşı Dayanıklılık

Bir alan adı birden fazla yetkili DNS sunucusu kullanıyorsa hepsinin güncel yapılandırmayı uyguladığını doğrulayın. Sabit kayıtların sunucular arasında farklı olması aktarım veya dağıtım sorununa işaret edebilir. Ancak konuma, yük dengelemeye veya iç ve dış ağ ayrımına göre tasarlanmış yanıt farklılıkları tek başına hata değildir; yanıtları ilgili sorgu koşulları için beklenen kayıtlarla karşılaştırın.

  • Değişiklikten sonra bütün yetkili DNS sunucularından gelen kayıt yanıtlarını karşılaştırın.
  • Üst bölgenin yetkili sunucuları bildiren NS kayıtlarıyla DNS bölgesindeki NS kayıtlarının uyumunu kontrol edin. Delegasyon değişiyorsa geçiş sırasında kullanılacak eski ve yeni sunucuları birlikte değerlendirin.
  • Alan adının kendi altındaki DNS sunucuları kullanılıyorsa bu sunucuların IP adreslerini içeren glue kayıtlarının güncel olduğunu doğrulayın.
  • DNSSEC kullanılan bölgelerde üst bölgedeki DS kaydının, alt bölgenin açık anahtarını içeren DNSKEY kaydıyla eşleşmesini ve imzaların geçerliliğini kontrol edin. Yalnız bu iki kaydın eşleşmesi yeterli değildir; doğrulama, güvenilen başlangıç anahtarına kadar uzanan zincirin tamamını kapsamalıdır. DNSSEC anahtarları veya DNS sağlayıcısı değiştiğinde bu kontrolü yineleyin.
  • İkincil yetkili DNS sunucularını mümkün olduğunda aynı ağa, tesise veya aynı arızanın etkileyebileceği tek bir altyapıya bağımlı bırakmayın.

Yetkili DNS sunucularının sayısını artırmak tek başına çeşitlilik sağlamaz. Bütün sunucular aynı ağ bağlantısına ve aynı altyapı bileşenine bağlıysa veya aynı yapılandırma ve yönetim hatasından birlikte etkileniyorsa birden fazla sunucu kullanmak beklenen dayanıklılığı sağlamayabilir.

Sahipsiz ve Eski Kayıtların Temizlenmesi

DNS bölgelerinde zamanla kapanmış projelere, taşınmış sunuculara ve artık kullanılmayan doğrulama işlemlerine ait kayıtlar birikebilir. Bu kayıtlar yönetimi zorlaştırabilir, trafiği eski hedeflere gönderebilir veya artık kontrol edemediğiniz üçüncü taraf hizmetlerine yönlendirebilir.

  • Artık kullanılmayan IPv4 adreslerini bildiren A ve IPv6 adreslerini bildiren AAAA kayıtlarını kaldırın.
  • Bir adı başka bir alan adına bağlayan CNAME kayıtlarının hedeflerini inceleyin; hedefin silinmiş veya başka bir kuruluşun denetimine geçmiş olmadığını doğrulayın.
  • Sahibi bulunamayan alt alan delegasyonlarını ve NS kayıtlarını, kullanım dışı olduklarını doğruladıktan sonra kaldırın.
  • Metin değeri taşıyan TXT kayıtlarından geçici doğrulama için eklenenleri kullanım süresi sonunda yeniden değerlendirin. Sahipliği koruyan veya doğrulamayı yenilemek için gereken kayıtları, sağlayıcının gereksinimi sürdükçe silmeyin.
  • Eski yük dengeleyici, CDN veya barındırma hedeflerine ait yinelenen kayıtları temizleyin.

Kayıt silmek de kontrollü bir değişikliktir. Bir kaydı yalnız eski göründüğü için silmeyin; önce trafik verilerini ve uygulama yapılandırmalarını inceleyin, ardından hizmet sahibinden onay alın. Silmeyi düşündüğünüz kaydın sahibini ve hangi hizmetler tarafından kullanıldığını belirleyin. Kaydı silmenin olası etkisini bu bilgilerle değerlendirin ve gerektiğinde kaydı geri ekleyebileceğiniz bir geri alma planı hazırlayın. Bir hizmeti kapatırken önce onu gösteren DNS kaydını kaldırın veya yeni hedefe yönlendirin. Bütün yetkili sunucularda değişikliği doğrulayıp önceki TTL süresini ve istemcilerin geçişini izledikten sonra eski kaynağı serbest bırakın; DNS kaydını artık denetlemediğiniz bir hedefe bağlı bırakmayın.

DNS Değişikliğinden Sonra Doğrulama ve Olay Takibi

Doğrulama için yalnız genel bir recursive resolver hizmetinden alınan yanıta güvenmeyin. Değişiklikten hemen sonra yetkili DNS sunucularını doğrudan kontrol edin; recursive resolver hizmetlerinin önbellekten döndürdüğü yanıtları ise değişikliğin kullanıcılara ne zaman yansıdığını izlemek için kullanın.

DNS Sağlık Kontrolü aracında alan adını sorgulayarak delegasyon ve yetkili DNS yanıtlarıyla ilgili bulguları inceleyebilirsiniz. Sonuçları amaçlanan yapılandırmayla karşılaştırın; tek bir sorgu, bütün önbelleklerin yenilendiğini veya uygulamanın sorunsuz çalıştığını kanıtlamaz.

A veya AAAA kaydını değiştirmeden önce hedef IP adresinin ilgili hizmete gerçekten ulaştığını doğrulayın. Bir cihazın internete çıkarken kullandığı IP adresi, hizmetin dışarıdan erişilen adresiyle aynı olmak zorunda değildir. Üçüncü taraf barındırma, yük dengeleme veya CDN hizmetlerinde hedef değeri ilgili hizmetin size verdiği resmi yapılandırmadan alın.

İzleme sistemini beklenmeyen kayıt değişiklikleri, yönetici oturumları, başarısız girişler, NS veya DS uyumsuzlukları ve yetkili DNS sunucuları arasındaki beklenmeyen farklılıklar için uyarı verecek biçimde yapılandırın. Uyarıyı kimin inceleyeceğini, hangi durumda geri alma yapılacağını ve hangi olayların güvenlik vakası sayılacağını önceden belirleyin.

Yetkisiz bir değişiklikten şüpheleniyorsanız ilgili hesapların erişimini sınırlandırın, API anahtarlarını devre dışı bırakın veya yenileyin, değişiklik geçmişini koruyun ve DNS bölgesindeki kayıtları daha önce doğrulanmış bir kayıt kopyasıyla karşılaştırın. Yalnız tek kaydı düzeltmek yeterli olmayabilir; alan adının kayıt kuruluşunda tanımlı DNS sunucularını, üst bölgedeki DS kaydını ve diğer yönetici erişimlerini de kontrol edin.