DNSSEC Key Rollover (KSK/ZSK) ve DS Kayıt Güncelleme: Sıfır Kesintiyle Anahtar Döndürme Nasıl Yapılır?

Hiç DNSSEC Anahtarı Döndürürken Ellerin Titredi mi?

Bir akşam, ofiste ışıklar yavaş yavaş sönerken bir müşterinin alan adında DNSSEC anahtar döndürmesi yapmam gerekiyordu. Kahve bitti, sessizlik çöktü ve o an düşündüm: “Şimdi tek bir yanlış hamle, geceyi uzatır mı?” Hiç başınıza geldi mi, DS kaydını güncelleyeyim derken bir yerlerde zinciri kırıp doğrulama hatalarıyla boğuştuğunuz? Ben yaşadım. O yüzden bu yazıda, sıfır kesintiyle DNSSEC key rollover işini, adım adım ve içinizi rahat ettirecek bir dille anlatmak istiyorum.

Konuyu şöyle hayal edin: Sitenizin kapısında iki tür güvenlik görevlisi var. Biri “kapının anahtarı” gibi davranan ZSK (zone signing key), diğeri de “ana anahtarın anahtarı” gibi KSK (key signing key). Bir de üst katmanla el sıkışmanızı sağlayan DS kaydı var. İşte öykümüz tam burada başlıyor. Anahtarları değiştirirken kapıyı asla kapatmamak istiyoruz. Yani ziyaretçiler fark etmeden, alttan alttan yeni anahtar devreye girsin, eskisi alnının akıyla emekli olsun.

Devamında şunları konuşacağız: KSK ile ZSK arasındaki rol farklarını, DS kaydının nerede devreye girdiğini, pre-publish ve double-sign gibi sihirli hamleleri, TTL zamanlamasını ve doğrulama adımlarını. Biraz sahadan örnek serpiştireceğim, biraz da pratik ipucu. Sonunda, gece yarısı eliniz daha az titrer hale gelecek.

KSK mi ZSK mı? DS Kayıt Nerede Duruyor?

Önce roller netleşsin. ZSK, alan adınızın içindeki kayıtları imzalayan günlük oyuncu. A, AAAA, CNAME, TXT… hepsi ZSK’nin sahası. KSK ise DNSKEY kayıt setini imzalayan, daha “üst makam” bir oyuncu. KSK’nin izi, DS kaydı olarak bir üst seviyeye yazılıyor; yani registrar veya registry tarafına, alan adınızın “ebeveynine”. Bu DS kaydı zinciri tamamlıyor ve dış dünyaya “Bu alan adının imza anahtarı budur” diyor.

Burada kritik nokta şu: ZSK değiştirirken genellikle alan adınızın içinde dönüp durursunuz. KSK değiştirirken ise üst katmana haber vermeniz gerekir; yani DS kaydını güncellemek şarttır. Mesela şöyle düşünün; apartman anahtarınızı değiştirip aynı evde kalabiliyorsunuz, ama apartmanın giriş anahtarını yenilediğinizde kapıcıya da haber vermek zorundasınız. DS işte o kapıcıya bırakılan not.

ZSK rotasyonu görece sık olur, çünkü daha çok çalışır. KSK daha seyrek dokunulan, ama adım atarken ekstra dikkat gereken anahtardır. Bu fark, bize adımları planlarken farklı ritimler verir. Parlak tarafı şu: İkisini doğru sırayla ve doğru pencerelerde taşırsanız, ziyaretçiler hiç anlamadan geçip gider.

Sıfır Kesintinin Sihri: Pre-Publish ve Double-Sign

İşin kalbi şu iki hamlede: pre-publish ve double-sign. Pre-publish, yeni anahtarı sessizce ilan etmektir. Hemen tek başına bırakmazsınız onu, önce ortama ısınsın. Double-sign ise eski ve yeni anahtarla eş zamanlı imzalamak demek. Bu sayede hangi resolver hangi anahtarla doğruluyorsa doğrulasın, cevaplarınız geçerli kalır.

Mesela ZSK döndürürken önce yeni ZSK’yi DNSKEY setine eklersiniz. Bir süre beklersiniz; burada “birkaç TTL” lafını sık duyacaksınız. Sonra bölgeyi hem eski ZSK hem yeni ZSK ile imzalarsınız. Biraz daha beklersiniz. Her şey sakin göründüğünde eski ZSK’yi imzadan çekersiniz. Son bir pencere daha beklersiniz ve en sonunda eski ZSK’yi tamamen kaldırırsınız. Bu ritim, DNS önbelleklerinin doğası gereği bize nefes alanı tanır.

KSK tarafında da benzer bir dans vardır, ama bir farkla: DS kaydı işin içine girer. Yeni KSK publish edilir, DNSKEY seti hem eski hem yeni KSK ile imzalanır. Uygun zaman geldiğinde DS kaydı ebeveyn tarafta yeni KSK’i işaret edecek şekilde güncellenir. Bu geçişin ardından güç yeni KSK’ye doğru kayar. Eski KSK’yi de yine sakin bir süre bekledikten sonra uğurlarsınız.

Adım Adım: ZSK Döndürme (Rahat Isınma Turu)

Zamanlama ve Hazırlık

ZSK döndürme genelde ilk deneme için idealdir. Çünkü DS ile uğraşmazsınız. Ben genelde şu akışla ilerliyorum: Önce alan adı imzalama süresini gözden geçiririm. TTL’ler çok uzun ise bir süre önceden düşürürüm; abartmadan ama manevra alanı yaratacak kadar. Ardından yeni ZSK’yi üretirim ve yayına “pre-publish” olarak alırım. Bu noktada sisteminize göre komutlar ve konsollar değişir; önemli olan mantık akışı.

Pre-publish sonrası birkaç TTL kadar beklemek, ağın beynindeki “eski fotoğraf”ların yenilenmesine izin verir. Beklerken “dig +dnssec alanadiniz.com DNSKEY” gibi ufak kontrollerle yeni anahtarın göründüğünü doğrularım. DNSSEC doğrulamasını kontrol etmek için “delv” veya farklı resolver’larla testler de faydalıdır. Hatalar genelde sabırsızlıktan çıkar; acele edilmezse yol akıcıdır.

Çifte İmzayla Güvenli Geçiş

Double-sign aşamasına geldiğinizde, bölge kayıtlarını hem eski ZSK hem yeni ZSK ile imzalarsınız. Bu dönem bir tür “ikili dönem”dir. Çoğu kullanıcı için hiçbir şey değişmez; ama biz biliriz ki sahnede iki sanatçı var. Bu pencere de birkaç TTL yaşamayı hak eder. Ben bu sırada DNSViz ile alan adının zincirini görsel olarak kontrol etmeyi seviyorum; grafikte kırmızı veya turuncu bir halka görürsem, önce onu sakin sakin düzeltirim.

Son perdede, eski ZSK’yi imzadan çekersiniz. Hemen silmezsiniz, bekler ve yeniden test edersiniz. Her şey yolundaysa, eski ZSK’yi tamamen kaldırırsınız. Bu akışın en güzel tarafı, kullanıcıların hiçbir şey fark etmemesi. Tüm konser bitmiş, alkışlar toplanmış, perde kapanmıştır; ama dışarıdakiler müziğin hiç kesilmediğini söyler.

Adım Adım: KSK Döndürme ve DS Güncelleme (Sahneye Ebeveyn de Dahil)

Pre-Publish: Yeni KSK’yi Sessizce Tanıtma

KSK döndürürken, aynı pre-publish yaklaşımıyla başlamak en sakin yöntem. Yeni KSK’yi DNSKEY setine eklersiniz ve DNSKEY setini hem eski hem yeni KSK ile imzalarsınız. Bu noktada dış dünya hâlâ eski DS kaydını takip etmektedir; problem değil. Biz zinciri koparmadan yeni anahtarı tanıtmış oluyoruz.

Bu tanıtım döneminde tanıdık kontroller işe yarar. “dig +dnssec alanadiniz.com DNSKEY” ile yeni KSK’nin göründüğünü görmek, sonraki adıma güven verir. Ayrıca ICANN’in KSK/ZSK açıklayıcı sayfası rol farklarını hatırlamak için hoş bir başucu notudur. Amacımız herkesin yeni KSK’yi duyması, ama henüz ona bağlanmak zorunda kalmaması.

DS Kaydının Güncellenmesi: Kapıcıya Haber

Şimdi işin kalbi: DS güncellemesi. Registrar panelinize girip, DS kaydını yeni KSK’nin bilgisi ile güncellersiniz. Bazı paneller “ekle-sil” akışını tek adımda vermez; önce yeni DS’yi ekleyip, bir süre sonra eskisini silmek daha sağlıklıdır. Çünkü DS ebeveyn tarafta yaşar; TTL ve yayın pencereleri sizin alan adınızdaki TTL’lerden bağımsız akabilir.

DS güncellemesinden sonra, birkaç TTL beklemek yine en iyi dostunuz. Bu arada DNSSEC doğrulamasını farklı resolver’lardan kontrol etmek, hatta mümkünse mobil ağ üzerinden de denemek, beklenmeyen önbellek davranışlarını yakalamanıza yardımcı olur. Eğer bir yerde kopukluk olursa genelde ya zamanlama yetersizdir ya da DS’de yanlış parmak izi seçilmiştir. Panik yok; doğrulayıp, gerekirse geri alıp, tekrar ve doğru şekilde ilerlemek mümkün.

Eski KSK’nin Uğurlanması

Yeni DS her yere sindiğinde, sisteminiz yeni KSK üzerinde kararlı çalışır hale gelir. Bundan sonra eski DS kaldırılır, ardından da KSK tarafında eski anahtar emekliliğe ayrılır. Ben bu aşamada tekrar tekrar test etmeyi, bir iki gün arayla doğrulamayı alışkanlık edindim. Çünkü DNS’in tabiatı gereği, köşelerde kalmış bir önbellek veya gecikmiş bir geçiş sizi şaşırtabilir. Sabır ve tekrar, bu işin gizli malzemeleridir.

Algoritma Değişimi, Çoklu İmzacı ve Acil Durum Senaryoları

Bazen sadece anahtarı değil, algoritmayı da değiştirmeniz gerekir. Bu, biraz daha dikkat isteyen bir turdur. Eski algoritma ile yeni algoritmayı bir süre birlikte yayınlamak, yani DNSKEY setinde her iki tarafı da görünür kılmak, sonra da imzaları çift taraflı üretmek güvenli bir yoldur. Son aşamada DS kaydı da yeni algoritmanın KSK’sine döner. Bu taktik, kapıdan giren herkesi sessizce yeni düzene alıştırır. Ek ayrıntılar merak uyandırırsa, RFC 6781’deki operasyonel pratikler güzel bir çerçeve sunar.

Çoklu imzacı (multi-signer) düzenleri de güncel hayatta karşımıza çıkar. İçerik dağıtım ağlarıyla (CDN) veya farklı DNS platformlarıyla çalıştığınızda, zinciri birden fazla tarafta sağlam tutmak gerekir. Burada da mantık değişmez: Her yerde pre-publish, her yerde double-sign ve tüm taraflarda tutarlı DS geçişi. Fark yalnızca orkestrasyondadır; herkes aynı notadan çalmalıdır.

Acil durumlar da olur. Anahtar sızdı veya şüpheli bir durum var; hızla rotasyon gerekli. Böyle anlarda ideal akıştaki bekleme pencerelerini minimuma indirip güvenliği öncelemek gerekir. Bu, küçük kesinti riskini artırsa da bazı zamanlar tek doğru hareket budur. O yüzden rutin zamanlarda provalar yapmak, bekleme sürelerini ve panel davranışlarını iyi tanımak, acil günde hayat kurtarır.

Otomasyon, Gözlem ve Sakinlik: Döndürmeyi Rutine Çevirmek

El yordamıyla yapılan her iş, bir gün yorgunlukla karışır ve küçük hatalar büyüyebilir. DNSSEC rotasyonunu da ufak otomasyonlarla rutine çevirmek mümkün. Açık konuşayım, ben değişiklikleri önceden “kuru koşu” ile test etmeyi seviyorum: Sahte bir alan adı, kısa TTL’ler, hızlı geri dönüş planı. Sonra prod’a geldiğimde her tık, daha önce duyduğum bir sesten ibaret oluyor.

Bu noktada altyapı otomasyonuna dokunmak güzel bir kaldıraç sağlar. DNS, bulut ve dağıtım süreçlerini aynı orkestrada yönetmek isterseniz, Terraform ile DNS otomasyonu üzerine sahadan anlattığımız yazı pratiğe çok yardımcı olur. Değişiklikleri kodla tarif etmek, geri almayı da kolaylaştırır. Hem ekip içinde bilginin bir kişide toplanmasını engeller, hem de “bu adımı atlamış mıydık?” endişesini azaltır.

Gözlem katmanı da şart. Basit sağlık kontrolleri, DNSSEC doğrulama testleri, çakışan anahtar veya yanlış DS uyarıları… Bunların bir kısmı e-posta ile, bir kısmı dashboard üzerinde akar. Rutin bildirimler bile iyi gelir; çünkü sistemin nabzını her gün tutarsınız. Rotasyon günü geldiğinde zaten her şey sizi tanır hale gelmiştir.

Sık Yapılan Hatalar ve Küçük Tüyolar

İlk hata genelde sabırsızlık. Pre-publish var, double-sign var; ama bu iki sihri etkili kılan şey zaman. TTL pencerelerini hafife alırsanız, zincir bir yerde kırılır. İkinci hata, DS parmak izini yanlış kopyalamak. Registrar panelinde küçük bir karakter farkı bile doğrulama sorunları yaratır. Bu yüzden kopyalayıp doğrulamak, hatta farklı bir cihazda ikinci kez bakmak iyi bir alışkanlık.

Bir diğeri de sadece tek yerden test etmek. Yerel resolver’ınız farklı davranabilir, ofis DNS’i beklenmedik önbellek politikaları uygulayabilir. Mobil ağdan veya farklı bir ISS’den denemek, bazen saatler sürecek bir sorunu dakikalar içinde görünür yapar. Bu arada zinciri görselleyen araçlar, örneğin DNSViz, stresinizi düşürür; çünkü hatayı resimle konuşursunuz.

Son olarak, algoritma değişimlerinde kelime oyunlarına sıkışıp kalmayın; mantığı takip edin. Yeni anahtarı sessizce tanıt, ikili dönemde çifte imzala, DS’yi doğru anahtara çevir, sonra eskisini uğurla. Bunu ezbere değil, nedenleriyle anladığınızda, her marka panelde, her altyapıda yolunuzu bulursunuz.

Gerçek Hayattan Minik Bir Gece Operasyonu

Bir e-ticaret sitesinde, gece yarısı KSK döndürmemiz gerekiyordu. Kampanya haftası yaklaşıyordu ve herkesin eli biraz daha titriyordu. Önce pre-publish yaptık; yeni KSK’yi DNSKEY setine ekledik, çifte imzayı devreye aldık. Birkaç TTL bekledik; bu bekleme süresini, küçük bir saatlik pencerede, daha az trafikli zamanların içine yerleştirdik. Bu sırada DNSViz ve dig testleri ile zincirin sorunsuz aktığını gördük.

Sonra registrar paneline geçip DS kaydını dikkatle güncelledik. Bu noktada aceleci olmayı sevmem; güncellemeden sonra bir nefes daha bekledik. Farklı ağlardan doğrulama yaptık; mobil şebekeden bile bakmak işe yarıyor. Her şey sakin kalınca, eski DS’yi kaldırdık ve bir süre sonra eski KSK’yi emekli ettik. Sabah olduğunda ekipten biri “Gece bir şey oldu mu?” diye sordu. “Oldu,” dedim, “ama kimse duymadı.”

Kapanış: Zinciri Koparmadan Akışta Kalmak

DNSSEC key rollover, dışarıdan bakınca ürkütücü görünebilir. İçeriden baktığınızda ise tekrarlayan birkaç adım ve dikkatli zamanlamadan ibarettir. ZSK döndürürken alan adınızın içinde sakince gezersiniz; KSK döndürürken DS kaydını ebeveyn tarafa doğru ve net bir şekilde çevirirsiniz. Her iki senaryoda da pre-publish, double-sign, doğru DS güncellemesi ve test, sizi sıfır kesintiye yaklaştırır.

Pratik bir yol haritası akılda kalsın: Değişiklikten önce TTL’leri gözden geçir, yeni anahtarı sessizce tanıt, çifte imza ile güvenli bir ikili dönem yaşat, DS’yi doğru zamanda ve dikkatle güncelle, sonra eski anahtarları nazikçe uğurla. Her adımda test et; dig ve görselleştirici araçlar iyi yol arkadaşıdır. Detay merak edersen, ICANN’in KSK/ZSK anlatımları ve operasyonel pratikleri toparlayan belgeler de elinin altında olsun. Hatta, otomasyonla işi rutine bağlamak istersen, Terraform ile DNS katmanını koda dökmek uzun vadede çok rahat ettirir.

Umarım bu yazı, gece vakti yapacağınız bir anahtar döndürme operasyonunda omzunuza görünmez bir el gibi dokunur. Takıldığınız bir noktada sakin kalın, zamanlamaya güvenin ve zincirin nerede aktığını gözden kaçırmayın. Sorularınız olursa her zaman yazın; bir sonraki yazıda başka bir altyapı düğümünü beraber çözelim. Bu arada ayrıntıları kurcalamak isterseniz, operasyonel pratiklere dair RFC ve ICANN’in KSK/ZSK açıklamaları her zaman açık. Yolunuz açık, imzalarınız sağlam olsun.