TTL'imi 24 saatten 5 dakikaya değiştirdim. Kayıtları değiştirmeden önce 24 saat beklemem gerekir mi?

37

Uygulamamızı Rackspace ta özel bir sunucudaki bir bulut sunucusundan geçiriyorum.

Verileri bulut sunucusundan özel sunucuya kopyalamak için uygulamayı ~ 5 dakika süreyle aşağıya bırakmak istiyorum, bu yüzden verileri kopyaladıktan sonra eski sunucuya giden istekleri istemiyorum.

DNS kaydını yeni sunucuya yönlendirmek istiyorum, ancak TTL 24 saate ayarlandı. 300 saniyeye değiştirdim. Alan adının verileri işaret ettiği / kopyaladığı ipi güncellemeden önce 24 saat beklemem gerekir mi?

domain-name-system rackspace ttl

— wobbily_col
kaynak

9

BTW, TTL'yi bekleseniz bile, orada daha fazla güncelleme kabul edilmeyeceğinden emin olmak için eski sunucudaki yapılandırmayı düzenlemenizi şiddetle tavsiye ediyorum. Tüm DNS çözümleyicileri aslında standartları takip etmiyor.

— Peter Green

5

Bir web uygulamasını bir barındırma sağlayıcısından bir başkasına taşırken yaptığım şey, yeni sunucuya yönlendirilen eski IP'yi kullanan ziyaretçilerin ziyaret etmesini sağlamak için bir ssh portu yönlendirmesi kullanmaktı.

— kasperd

58

Etki alanı kaydının önbelleğe alınmış bir kopyasına sahip olan kimse 24 saat boyunca güncellemekten rahatsız olmaz, bu nedenle evet, niyetiniz en fazla 5 dakikalık bir kullanılabilirlik penceresine sahip olmaksa, bekleyen tüm önbelleklerin daha fazla yaşamak için güncellenmesini beklemelisiniz 5 dakikadan fazla.

— Jeff Meden
kaynak

23

... 24 saat boyunca since they last cached it. Bu 1 ila 86399 saniye arasında herhangi bir şey olabilir.

— user9517,

6

@Iain En kötüsünü üstlenmelisin, çünkü herhangi biri veya hepsi değişiklikten hemen önce önbelleğe alabilirdi.

— Barmar

6

@Barmar Bir şey varsaymayın. Çok sayıda ISS sadece TTL'yi görmezden geldi.

— user9517, 3:16

13

@Iain Akamai için çalışmıştım, yük dengelemesi için kısa TTL'leri (60 saniye gibi) yoğun şekilde kullanan bir CDN. Bir çalışma yaptığımızı ve çoğu ISS'nin TTL'lere uyduğunu tespit ettiğimi hatırlıyorum.

— Barmar

1

Bir web barındırma şirketi için çalışıyorum, deneyimlerimiz düşük TTL'lerin daha yüksek göz ardı edilme ihtimalinin yüksek olması.

— Henrik,

39

Bundan daha da kötüsü (potansiyel olarak) bile - tüm yetkili sunucularınız güncellendikten sonra 24 saat beklemeniz gerekir. Güncellemelerin gerçekleşmesi için normal yol, birincil sunucudaki bölgede bir değişiklik yapmanız ve ardından ikincillerin her birinin, birincil ile kontrol edildiklerinde yeni bölge verilerini aktarmasıdır. Giriş sıklığı, bölgenin SOA kaydındaki yenileme aralığı tarafından kontrol edilir. Bu nedenle, en kötü durumda, bölgenin yenileme aralığını + kaydın TTL'sini beklemeniz gerekir.

Sen olabilir ayrıca fiili kayıt değişiklikler için bu kadar uzun süre beklemek zorunda. 5 dakikalık bir TTL, ikinciller yalnızca 6 saatte bir yenilenirse, pek bir fayda sağlamaz. Bu yüzden muhtemelen bölgedeki yenileme aralığını azaltmak istediğinizde hızlı değişiklikler yapabileceğiniz süreyi azaltmak istersiniz.

Unutmayın, bu kurulumunuz için geçerli olmayabilir. Tüm yetkili sunucuları bir araya getiren bir sisteminiz varsa, bu bir sorun değildir (ve Rackspace'in DNS kurulumuna aşina değilim). Ancak , 24 saatlik geri sayıma başlamadan önce yeni TTL’lere sahip olduklarından emin olmak için tüm yetkili sunucularınızı ayrı ayrı ( dig server.example.com @secondaryserver.example.com) tek tek sorgulamanızı öneririm .

— Gordon Davisson
kaynak

1

Bu kabul edilen cevap olmalı.

— dotancohen

4

Master güncelleştirildikten kısa bir süre sonra bağımlı sunuculara yenileme yapmalarını söyleyen DNS Bildirimi protokolünü görmezden geliyor gibi görünüyorsunuz. Çoğu DNS sunucusu bu özelliği kullanır.

— Barmar

@Barmar: Bu doğru, ancak aynı zamanda master'ın sağlayıcıya bağlı olarak güncellenmesi biraz zaman alabilir. (Örneğin, bazı sağlayıcılar tek modern olanları anında bunu ancak veritabanına her 5 veya 15 dakika mesafede bölgelerini yeniden.)

— grawity

1

Yorumum yalnızca Yenileme aralığını beklemenin konusunu ele alıyordu, bu günümüzde çoğunlukla kullanılmıyor. Kendi master'inizi çalıştırmazsanız, master'in güncellenmesini beklemek geçerlidir. Ancak, her şeyin güncellenmesi güvenli olduğunda tam zamanı ile ilgilenmeleri gerekmeyeceğini düşünüyorum; Ekstra 5-15 dakika fark yaratmamalı. Asıl sorunun amacı, bir gün boyunca beklemeleri gerekip gerekmediğidir.

— Barmar

1

@ GordonDavisson: Güvenmiyorsanız - doğrulayın. dig +nssearch example.comSOA'ları tüm sunucular arasında hızlıca karşılaştırmak için kullanışlı bir araçtır; nsdiff gerçek farklılıkları gösterir.

— Grawity

23

Evet, beklemelisin. Elbette o zaman bile, herkesin TTL'ye saygı göstereceği garanti edilmez.

— Sven
kaynak

6

Herkes TTL'ye uymadığından +1, DNS'lerin değişiminden bir hafta sonra stragglers'ın geldiğini gördüm. Geçmişte ele almamın bir yolu, yeni sitede takma ad olarak yeni bir benzersiz ad oluşturmak ve kullanıcıları eski alandan yeni alanlara yönlendirmek için, www.mycompany'deki gibi eski siteden bir yönlendirme kullanmaktı. .com -> newsite.mycompany.com

— Johnny 20

Evet, ancak birçok kişi yeni bir ad kullanmak zorunda olma fikrini haklı olarak küçümseyecektir. İsimler markadır. Ayrıca, bu sadece HTTP için ve hemen hemen hiçbir şey için işe yaramaz.

— Sven

8

Başka bir seçenek de eski sunucuyu yeni sunucuya ters bir proxy olarak yapılandırmaktır. Daha sonra, anahtardan sonra bir hafta kadar süre bırakabilir ve trafiği geçmediğinde kapatabilirsiniz.

— bdsl

1

TTL'ye uyan DNS sunucularını iyi kullananlar hiçbir zaman yeni etki alanını görmezler. Ve "sadece" HTTP (S) ile çalışırken, HTTP'nin internette oldukça yaygın bir protokol olduğunu göreceksiniz. bdsl'in ters proxy kurma önerisi daha da iyi, ancak daha fazla iş var

— Johnny

@Johnny Yeni bir etki alanı ile ilgili sorun, bu alanı işaretleyen kişilerin riski altında olmanızdır. Yeni etki alanını sonsuza kadar erişilebilir bırakmayı planlamazsan.

— Bob,

5

Çeşitli yorumları ve cevapları bir araya getirmek tüm prosedürü gibi bir şey olurdu.

Yetkili sunucularınızı zamanında güncelleyebildiğinizden emin olun.
TTL'yi azaltın.
Tüm yetkili sunucuların yeni ttl değerlerini kontrol et.
Eski TTL'yi bekleyin, böylece eski TTL ile önbelleklenmiş değerler (çoğunlukla) önbelleklerden elimine edilir (bazı önbelleklerin standartları görmezden gelebileceği için her önbellekten gitmiş olmalarını garanti edemezsiniz).
Siteyi eski sunucuda salt okunur moda getirin (ya da bunu yapamazsanız, "önemsizliğe düşkünüz" sayfasıyla değiştirin).
Eski sunucudan yeni sunucuya son kopyayı gerçekleştirin (yeni sunucuda salt okunur bir siteyle sonuçlanır).
DNS kayıtlarını değiştirin.
Tüm yetkili sunucuların yeni DNS kayıtlarına sahip olduğundan emin olun.
Yeni ttl'yi bekleyin (bazı kullanıcıların siteye katkıda bulunabilmesi ve diğer kullanıcıların bu katkıların sonuçlarını görememesiyle ilgilenmiyorsanız bu adımı atlayabilirsiniz).
Siteyi yeni sunucuya okuma / yazma moduna getirin.
Eski sunucuya eski ve salt okunur bir kopya olduğu ve kullanıcının büyük olasılıkla DNS'yi bozduğuna dikkat edin.
Kayıtların uyumlu olmayan DNS önbelleklerinden çıkarılmasını bekleyin.
Eski sunucunun kullanımdan kaldırılması.

— Peter Green
kaynak

5

Diğer cevaplara ek olarak, DNS kaydınızın neredeyse gerçek zamanlı olarak nasıl yayıldığını kontrol etmek için https://www.whatsmydns.net/ adresini kullanabilirsiniz .

— Madis Nõmme
kaynak