DNS Kaydını ve Sağlayıcısını Kesintisiz Değiştirmek: TTL Sırası, Negatif Önbellek, NS Geçişi ve DNSSEC

Bir servisi yeni bir sunucuya, yeni bir yük dengeleyiciye ya da yeni bir DNS sağlayıcısına taşırken asıl iş genellikle DNS kaydını değiştirmekten ibaret görünür. Kayıt değişir, panel "kaydedildi" der ve sonraki birkaç saat boyunca kullanıcıların bir kısmı eski adrese, bir kısmı yenisine gider; bazıları da hiçbir yere gidemez. Bunun sebebi DNS'in bir veritabanı değil, dünyaya dağılmış önbelleklerden oluşan bir sistem olmasıdır. Kaydı siz değiştirirsiniz, ama ne zaman görüleceğine her önbellek kendi sayacıyla karar verir. Kesintisiz geçiş, bu sayaçları önceden yönetmekten geçer.

TTL, değişiklikten önce düşürülür

Bir kaydın TTL değeri, onu soran çözümleyicinin cevabı ne kadar süre saklayabileceğini söyler. TTL'i 86400 olan bir kaydı değiştirdiğinizde, değişiklikten bir dakika önce soran bir çözümleyici eski cevabı bir gün boyunca kullanmakta tamamen haklıdır.

Bu yüzden doğru sıra şudur:

1. Kaydın mevcut TTL değerini öğrenin.
2. TTL'i 60 ya da 300 gibi kısa bir değere indirin.
3. Eski TTL kadar bekleyin. Yeni kısa TTL ancak eski uzun TTL'li cevaplar önbelleklerden düştükten sonra etkili olur.
4. Kaydın değerini değiştirin.
5. Geçiş doğrulandıktan sonra TTL'i normal değerine geri yükseltin.

En sık yapılan hata, TTL'i düşürüp değeri aynı anda değiştirmektir. Bu hiçbir şey kazandırmaz: önbellekteki eski cevap eski TTL ile yaşamaya devam eder.

Kısa TTL'i kalıcı bırakmak da iyi bir fikir değildir. Her sorgu yetkili sunucuya kadar gider, ilk bağlantı gecikmesi artar ve yetkili sunucunuz kısa bir süre erişilemez olduğunda önbellekler sizi koruyamaz. Bir günlük ya da birkaç saatlik TTL, sık değişmeyen kayıtlar için sağlıklı bir varsayılandır.

Yetkili sunucunun ne söylediğini önbelleğe takılmadan görmek için doğrudan ona sorun:

dig +short NS example.com
dig +norecurse @ns1.example.net app.example.com A
dig @1.1.1.1 app.example.com A

İlk komut yetkili sunucuları, ikincisi yetkili sunucunun güncel cevabını, üçüncüsü ise bir genel çözümleyicinin o an önbellekte tuttuğu cevabı ve kalan süresini gösterir. Üçüncü cevaptaki TTL sütunu her sorguda azalıyorsa, gördüğünüz önbellekten geliyordur.

Olmayan kayıt da önbelleğe girer

Yeni bir alt alan adı açacaksanız ve kaydı oluşturmadan önce biri o adı sorgularsa, cevap "böyle bir ad yok" olur ve bu cevap da önbelleğe alınır. Negatif önbellek süresi bölgenin SOA kaydından gelir: SOA kaydının kendi TTL'i ile SOA içindeki son alan (minimum) arasındaki küçük değer kullanılır.

Bu, sırası ters işleyen bir geçişin tipik tuzağıdır. Bir dağıtım betiği yeni adı kaydı oluşturmadan önce test eder, sağlık kontrolü adı sorgular, çözümleyici NXDOMAIN'i saatlerce saklar ve kayıt oluşturulduktan sonra bile bazı kullanıcılar adı çözemez. Önlem basittir: önce kaydı oluşturun, sonra adı kullanan her şeyi başlatın. Bölgenizin SOA minimum değerini de bilin; birkaç saatlik bir değer, yanlış zamanda yapılmış tek bir sorgunun bedelini o kadar uzatır.

dig +short SOA example.com

Sağlayıcı değiştirmek ayrı bir iştir

Kaydın değerini değiştirmek ile bölgeyi başka bir DNS sağlayıcısına taşımak farklı işlerdir. İkincisinde değişen, üst bölgedeki NS kayıtlarıdır ve bu kayıtların TTL'i sizin elinizde değildir. Yaygın genel uzantılarda üst bölgedeki NS kayıtlarının TTL'i iki gün civarındadır ve kayıt operatörü bunu belirler.

Bu yüzden sağlayıcı geçişinde doğru yol, iki sağlayıcının bir süre boyunca aynı içeriği sunmasıdır:

1. Bölgeyi yeni sağlayıcıda eksiksiz kurun. Her kaydı, özellikle MX, TXT ve doğrulama kayıtlarını tek tek karşılaştırın.
2. Yeni sağlayıcının yetkili sunucularına doğrudan sorgu atarak içeriği doğrulayın.
3. Kayıt operatöründe NS kayıtlarını değiştirin.
4. Eski sağlayıcıyı en az üst bölgenin NS TTL'i kadar, tercihen birkaç gün daha açık tutun. Bu sürede iki tarafta da yapılan her değişikliği ikisine birden uygulayın.

Eski sağlayıcıyı NS değişikliğinin hemen ardından kapatmak, önbelleğinde eski NS kayıtları duran çözümleyiciler için bölgenizin tamamen yok olması demektir.

DNSSEC açıksa sıra daha da önemlidir

Bölge DNSSEC ile imzalıysa, üst bölgede sizin anahtarınızı gösteren bir DS kaydı vardır. Yeni sağlayıcı bölgeyi kendi anahtarıyla imzalar ve DS kaydı hâlâ eski anahtarı gösteriyorsa, doğrulama yapan her çözümleyici bölgenize SERVFAIL döner. Bu bir yavaşlık değil, tam kesintidir ve doğrulama yapmayan çözümleyicilerle test eden ekip sorunu göremez.

İki güvenli yol vardır. Basit olanı, DS kaydını önce kaldırmak, DS kaydının TTL'i kadar beklemek, taşımayı imzasız yapmak ve sonra yeni anahtarın DS kaydını eklemektir. Bu sürede bölge DNSSEC korumasız kalır ama kesinti olmaz. Diğeri, iki sağlayıcının birbirinin anahtarlarını yayınladığı çoklu imzacı modelidir; her sağlayıcı bunu desteklemez ve yanlış yapılandırıldığında aynı SERVFAIL'i üretir. Çoğu ekip için ilk yol yeterlidir.

Geçişten sonra doğrulayan bir çözümleyiciyle kontrol edin. dig çıktısındaki bayraklar arasında ad görünüyorsa cevap doğrulanmıştır.

DNS'i dinlemeyen istemciler

DNS doğru yapılandırılsa bile bazı istemciler yeni adresi TTL'e uygun sürede görmez. Bunun sebebi çözümlemenin yalnız çözümleyicide değil, uygulamanın kendisinde de önbelleğe alınmasıdır.

Uzun ömürlü bağlantılar. Bağlantı havuzları, HTTP keepalive, veritabanı ve mesaj kuyruğu istemcileri adı bir kez çözer ve bağlantı açık kaldıkça aynı adresi kullanır. DNS değişikliği bu bağlantıları kapatmaz. Eski sunucuyu, açık bağlantılar boşalana kadar çalışır tutun ve eski taraftaki bağlantı sayısını izleyerek kapatma kararı verin.

Ters vekil sunucular. nginx, proxy_pass satırına sabit yazılmış bir adı yapılandırma yüklenirken çözer ve yeniden yüklenene kadar o adresi kullanır. Yeniden çözümleme istiyorsanız resolver yönergesi tanımlayıp adı bir değişken üzerinden vermeniz gerekir; yeni sürümlerde upstream içindeki sunucu satırları için resolve parametresi de vardır. Kullandığınız vekilin bu konudaki davranışını belgesinden kontrol edin, varsayılanın ne olduğunu tahmin etmeyin.

Çalışma ortamı önbellekleri. JVM, başarılı çözümlemeleri networkaddress.cache.ttl güvenlik özelliğine göre saklar ve bu değer kaydın TTL'inden bağımsızdır. Konteyner ve sistem tarafında da ayrıca önbellek tutan yerel bir çözümleyici bulunabilir. Geçişten önce kendi istemcilerinizin hangi katmanda önbellek tuttuğunu öğrenin.

Kısa TTL'e uymayan çözümleyiciler. Bazı çözümleyiciler, çok kısa TTL'leri bir alt sınıra yükseltecek şekilde yapılandırılır. Bu yüzden 60 saniyelik TTL, herkesin 60 saniyede geçeceği anlamına gelmez; geçiş planınız birkaç dakikalık bir kuyruğu kaldırabilmelidir.

Küçük ama sık görülen tuzaklar

Bölge apex'inde, yani çıplak alan adında CNAME kullanılamaz, çünkü CNAME aynı adda başka kayıtla birlikte bulunamaz ve apex'te SOA ile NS her zaman vardır. Bir yük dengeleyicinin adına yönlendirmek istiyorsanız sağlayıcınızın ALIAS ya da CNAME düzleştirme özelliğini kullanın, olmayan bir kaydı zorlamayın.

İkincil sunuculara bölge aktarımı yapıyorsanız, SOA seri numarasını artırmadan yapılan değişiklik ikincillere hiç ulaşmaz. Yetkili sunucuların hepsine ayrı ayrı sorgu atıp aynı cevabı verdiklerini doğrulayın.

Eski adresi hemen başka bir müşteriye ya da başka bir servise vermeyin. Önbellekte kalan cevaplar ve uzun ömürlü bağlantılar bir süre o adrese gitmeye devam eder; adresi yeniden kullanmak, trafiği ve hatta oturum çerezlerini yanlış yere taşır.

Ne zaman DNS ile geçiş yapmamalı

DNS, saniyeler içinde geri alınması gereken bir geçiş için doğru araç değildir. Geri alma da aynı önbelleklere takılır: bir sorun çıktığında kaydı eski değerine döndürmek, kısa TTL'le bile dakikalar sürer ve uzun ömürlü bağlantıları hiç etkilemez. Trafiği kademeli kaydırmanız ya da anında geri almanız gerekiyorsa, adres sabit kalsın ve geçişi o adresin arkasındaki yük dengeleyicide yapın. DNS'i, adresin gerçekten değiştiği ve birkaç dakikalık bir kuyruğun kabul edilebilir olduğu durumlar için saklayın.