Düşük DNS gecikmesi, hızlı internette gezinmenin anahtarıdır. Bunu en aza indirmek için DNS sunucularını dikkatlice seçmek önemlidir ve . Ancak ilk adım gereksiz sorgulardan kurtulmaktır.
DNS'nin başlangıçta yüksek oranda önbelleğe alınabilir bir protokol olarak tasarlanmasının nedeni budur. Bölge yöneticileri, bireysel girişler için bir geçerlilik süresi (TTL) ayarlar ve çözümleyiciler, gereksiz trafiği önlemek için girişleri bellekte saklarken bu bilgiyi kullanır.
Önbelleğe alma etkili midir? Birkaç yıl önce yaptığım küçük araştırma bunun mükemmel olmadığını gösterdi. Gelin mevcut duruma bir göz atalım.
Yamaladığım bilgileri toplamak için Yanıtın TTL değerini kaydetmek için. Gelen her istek için kayıtlarının minimum TTL'si olarak tanımlanır. Bu, gerçek trafiğin TTL dağıtımına ilişkin iyi bir genel bakış sağlar ve ayrıca bireysel isteklerin popülerliğini de hesaba katar. Sunucunun yamalı sürümü birkaç saat çalıştı.
Ortaya çıkan veri seti 1 kayıttan (ad, qtype, TTL, zaman damgası) oluşur. Genel TTL dağılımı şöyledir (X ekseni saniye cinsinden TTL'dir):
86'deki küçük bir yükselişin (çoğunlukla SOA kayıtları için) dışında, TTL'lerin düşük aralıkta olduğu oldukça açık. Hadi daha yakından bakalım:
Tamam, 1 saatten uzun TTL'ler istatistiksel olarak anlamlı değil. O halde 0−3600 aralığına odaklanalım:
Çoğu TTL 0 ila 15 dakika arasındadır:
Büyük çoğunluğu 0 ila 5 dakika arasındadır:
Bu hiç iyi değil.
Kümülatif dağılım sorunu daha da belirgin hale getiriyor:
DNS yanıtlarının yarısının TTL'si 1 dakika veya daha az, dörtte üçünün TTL'si ise 5 dakika veya daha az.
Ama bekleyin, aslında daha da kötü. Sonuçta bu yetkili sunuculardan gelen TTL. Ancak istemci çözümleyiciler (örn. yönlendiriciler, yerel önbellekler) yukarı akış çözümleyicilerden bir TTL alır ve bu her saniye azalır.
Böylece müşteri, yeni bir istek göndermeden önce her girişi ortalama olarak orijinal TTL'nin yarısı kadar kullanabilir.
Belki de bu çok düşük TTL'ler popüler web siteleri ve API'ler için geçerli değil, yalnızca olağandışı istekler için geçerli olabilir? Bir göz atalım:
X ekseni TTL, Y ekseni sorgu popülerliğidir.
Ne yazık ki, en popüler sorgular aynı zamanda önbelleğe alınması en kötü sorgulardır.
Yakınlaştıralım:
Karar: gerçekten kötü. Daha önce de kötüydü ama daha da kötüleşti. DNS önbelleğe alma neredeyse işe yaramaz hale geldi. Daha az kişi ISP'nin DNS çözümleyicisini kullandıkça (iyi nedenlerden dolayı), gecikmedeki artış daha belirgin hale gelir.
DNS önbelleğe alma, yalnızca kimsenin ziyaret etmediği içerik için kullanışlı hale geldi.
Lütfen ayrıca yazılımın Düşük TTL'leri yorumlayın.
Neden ki?
DNS kayıtları neden bu kadar düşük bir TTL'ye ayarlandı?
- Eski yük dengeleyiciler varsayılan ayarlarla bırakıldı.
- DNS yük dengelemenin TTL'ye bağlı olduğuna dair efsaneler var (bu doğru değil - Netscape Navigator günlerinden bu yana, istemciler bir dizi RR'den rastgele bir IP adresi seçtiler ve bağlanamazlarsa şeffaf bir şekilde başka birini denediler)
- Yöneticiler değişiklikleri hemen uygulamak isterler, böylece planlama yapmak daha kolay olur.
- Bir DNS sunucusunun veya yük dengeleyicinin yöneticisi, görevinin siteleri ve hizmetleri hızlandırmak değil, kullanıcıların istediği yapılandırmayı verimli bir şekilde dağıtmak olduğunu görür.
- Düşük TTL'ler size gönül rahatlığı sağlar.
- İnsanlar başlangıçta test için düşük TTL'ler belirlediler ve sonra bunları değiştirmeyi unutuyorlar.
Listeye "yük devretme"yi eklemedim çünkü giderek daha az alakalı hale geliyor. Kesinlikle her şey bozulduğunda bir hata sayfası görüntülemek için kullanıcıları başka bir ağa yönlendirmeniz gerekiyorsa, 1 dakikadan fazla bir gecikme muhtemelen kabul edilebilir.
Ayrıca bir dakikalık TTL, yetkili DNS sunucularının 1 dakikadan uzun süre engellenmesi durumunda başka hiç kimsenin bağımlı hizmetlere erişemeyeceği anlamına gelir. Sebebin bir yapılandırma hatası veya bir hack olması durumunda yedeklilik yardımcı olmayacaktır. Öte yandan, makul TTL'lerle birçok istemci önceki yapılandırmayı kullanmaya devam edecek ve hiçbir şey fark etmeyecektir.
CDN hizmetleri ve yük dengeleyiciler, özellikle CNAME'leri düşük TTL'lerle ve eşit derecede düşük (ancak bağımsız) TTL'lere sahip kayıtları birleştirdiklerinde, düşük TTL'lerden büyük ölçüde sorumludur:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
CNAME veya A kayıtlarından herhangi birinin süresi dolduğunda yeni bir istek gönderilmelidir. Her ikisinin de 30 saniyelik bir TTL'si var, ancak aynı değil. Gerçek ortalama TTL 15 saniye olacaktır.
Fakat bekle! Daha da kötü. Bazı çözümleyiciler bu durumda ilişkili iki düşük TTL ile çok kötü davranırlar:
$ matkap raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 CNAME'DE github.map.fastly.net. github.map.fastly.net. 1 151.101.16.133 İÇİNDE
Level3 çözümleyici muhtemelen BIND'de çalışıyor. Bu isteği göndermeye devam ederseniz esasen her zaman 1 TTL döndürülür. raw.githubusercontent.com hiçbir zaman önbelleğe alınmaz.
Çok popüler bir alanla ilgili böyle bir duruma başka bir örnek:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
En az üç CNAME kaydı. Evet. Birinin iyi bir TTL'si var, ancak tamamen işe yaramaz. Diğer CNAME'lerin başlangıç TTL'si 60 saniyedir ancak alanlar için akamai.net maksimum TTL 20 saniyedir ve hiçbiri aynı fazda değildir.
Apple cihazlarını sürekli yoklayan alan adlarına ne dersiniz?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Firefox ve TTL ile aynı sorun, Level1 çözümleyiciyi kullanırken çoğu zaman 3 saniyede takılıp kalacaktır.
Dropbox'ı mı?
$ matkap client.dropbox.com @8.8.8.8 client.dropbox.com. 7 CNAME'de client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ matkap client.dropbox.com @4.2.2.2 client.dropbox.com. 1 CNAME client.dropbox-dns.com'da. client.dropbox-dns.com. 1 162.125.64.3'TE
Kayıt sırasında safebrowsing.googleapis.com TTL değeri Facebook domainleri gibi 60 saniyedir. Ve yine müşterinin bakış açısından bu değerler yarıya iner.
Minimum TTL'yi ayarlamaya ne dersiniz?
Adı, istek türünü, TTL'yi ve başlangıçta saklanan zaman damgasını kullanarak, süresi dolmuş bir önbellek girişi nedeniyle gönderilen gereksiz isteklerin hacmini tahmin etmek için bir önbellek çözümleyicisinden geçen 1,5 milyon isteği simüle eden bir komut dosyası yazdım.
Taleplerin %47,4'ü mevcut kaydın süresi dolduktan sonra yapıldı. Bu makul olmayacak kadar yüksek.
Minimum TTL ayarlanırsa önbelleğe alma üzerindeki etkisi ne olacaktır?
X ekseni minimum TTL değerleridir. Kaynak TTL'leri bu değerin üzerinde olan kayıtlar etkilenmez.
Y ekseni, halihazırda önbelleğe alınmış bir girişi olan ancak süresi dolmuş ve yeni bir istekte bulunan bir istemciden gelen isteklerin yüzdesidir.
Minimum TTL'nin 47 dakikaya ayarlanmasıyla "ekstra" isteklerin payı %36'den %5'ya düşürülür. Minimum TTL'nin 15 dakikaya ayarlanmasıyla bu isteklerin sayısı %29'a düşüyor. Minimum 1 saatlik TTL bunları %17'ye düşürür. Önemli fark!
Sunucu tarafında hiçbir şeyi değiştirmemek yerine istemci DNS önbelleklerinde (yönlendiriciler, yerel çözümleyiciler) minimum TTL'yi ayarlamaya ne dersiniz?
Gereken talep sayısı minimum 47 dakikalık TTL'de %34'den %5'e, minimum 25 dakikalık TTL'de %15'e ve minimum 13 saatlik TTL'de %1'e düşer. Belki 40 dakika en uygunudur.
Bu küçük değişikliğin etkisi çok büyüktür.
Sonuçları nelerdir?
Elbette hizmet, müşterilerin en son DNS kayıtlarını kullanmasını gerektirecek şekilde yeni bir bulut sağlayıcısına, yeni sunucuya, yeni ağa taşınabilir. Ve oldukça küçük bir TTL, böyle bir geçişin sorunsuz ve fark edilmeden yapılmasına yardımcı olur. Ancak yeni altyapıya geçişle birlikte hiç kimse istemcilerin 1 dakika, 5 dakika veya 15 dakika içinde yeni DNS kayıtlarına geçmesini beklemiyor. Minimum TTL'yi 40 dakika yerine 5 dakikaya ayarlamak kullanıcıların hizmete erişimini engellemeyecektir.
Ancak bu, gereksiz isteklerden kaçınarak gecikmeyi önemli ölçüde azaltacak ve gizliliği ve güvenilirliği artıracaktır.
Elbette RFC'ler TTL'ye kesinlikle uyulması gerektiğini söylüyor. Ancak gerçek şu ki, DNS sistemi çok verimsiz hale geldi.
Yetkili DNS sunucularıyla çalışıyorsanız lütfen TTL'lerinizi kontrol edin. Gerçekten bu kadar gülünç derecede düşük değerlere ihtiyacınız var mı?
Elbette DNS kayıtları için küçük TTL'ler ayarlamanın iyi nedenleri vardır. Ancak DNS trafiğinin neredeyse hiç değişmeden kalan %75'i için durum böyle değil.
Ve herhangi bir nedenle DNS için gerçekten düşük TTL'ler kullanmanız gerekiyorsa, aynı zamanda sitenizde önbelleğe almanın etkin olmadığından da emin olun. Aynı nedenlerden dolayı.
Çalışan bir yerel DNS önbelleğiniz varsa, örneğin Minimum TTL'leri ayarlamanıza olanak tanıyan bu işlevi kullanın. Bu iyi. Kötü bir şey olmayacak. Minimum TTL'yi yaklaşık 40 dakika (2400 saniye) ve 1 saate ayarlayın. Oldukça makul bir aralık.
Kaynak: habr.com