Google Chrome ve yeni Microsoft Edge'in başarılı açık kaynaklı ebeveyni olan Chromium tarayıcısı, iyi niyetle tasarlanan bir özellik nedeniyle önemli ölçüde olumsuz ilgi gördü: Kullanıcının İSS'sinin var olmayan alan adı sorgu sonuçlarını "çalıp çalmadığını" kontrol ediyor .
İstatistiksel olarak var olma olasılığı düşük olan rastgele "alanlar" için sahte sorgular oluşturan , dünya çapındaki kök DNS sunucuları tarafından alınan toplam trafiğin yaklaşık yarısından sorumludur. Verisign mühendisi Matt Thomas uzun bir yazı yazdı APNIC blogunda sorunu açıklıyor ve ölçeğini değerlendiriyoruz.
DNS çözümlemesi genellikle nasıl gerçekleştirilir?
Bu sunucular, .com, .net vb. alan adlarını çözümlemek için iletişime geçmeniz gereken en yüksek otoritedir, böylece size frglxrtmpuf'un üst düzey bir alan adı (TLD) olmadığını söyleyeceklerdir.
DNS veya Alan Adı Sistemi, bilgisayarların arstechnica.com gibi unutulmaz alan adlarını 3.128.236.93 gibi çok daha az kullanıcı dostu IP adreslerine dönüştürebildiği bir sistemdir. DNS olmasaydı İnternet insanların kullanabileceği şekilde var olamazdı, bu da üst düzey altyapıya gereksiz yük gelmesinin gerçek bir sorun olduğu anlamına geliyor.
Tek bir modern web sayfasını yüklemek inanılmaz sayıda DNS araması gerektirebilir. Örneğin ESPN'in ana sayfasını incelediğimizde a.espncdn.com'dan z.motads.com'a kadar 93 ayrı alan adı saydık. Sayfanın tam olarak yüklenmesi için bunların hepsi gereklidir!
Tüm dünyaya hizmet vermesi gereken bir arama motorunun bu tür iş yükünü karşılamak için DNS, çok düzeyli bir hiyerarşi olarak tasarlanmıştır. Bu piramidin tepesinde kök sunucular bulunur; .com gibi her üst düzey etki alanı, altlarındaki her etki alanı için en yüksek otorite olan kendi sunucu ailesine sahiptir. Bir adım yukarı bunlar sunucular kök sunucuların kendileridir, a.root-servers.net karşı m.root-servers.net.
Bu ne sıklıkla oluyor?
DNS altyapısının çok seviyeli önbellekleme hiyerarşisi sayesinde dünyadaki DNS sorgularının çok küçük bir yüzdesi kök sunuculara ulaşır. Çoğu kişi DNS çözümleyici bilgilerini doğrudan ISP'lerinden alır. Bir kullanıcının cihazının belirli bir web sitesine nasıl ulaşacağını bilmesi gerektiğinde, öncelikle o yerel sağlayıcı tarafından yönetilen bir DNS sunucusuna bir istek gönderilir. Yerel DNS sunucusu cevabı bilmiyorsa, isteği kendi "ileticilerine" (belirtilmişse) iletir.
Yerel sağlayıcının DNS sunucusunda veya yapılandırmasında belirtilen "iletme sunucularında" önbelleğe alınmış bir yanıt yoksa, istek doğrudan yetkili etki alanı sunucusuna iletilir. yukarıda dönüştürmeye çalıştığınız kişi. Ne zaman домен.com bu, isteğin alan adının yetkili sunucularına gönderildiği anlamına gelir comadresinde bulunan gtld-servers.net.
Sistem gtld-serversTalebin yapıldığı , domain.com etki alanı için yetkili ad sunucularının bir listesinin yanı sıra böyle bir ad sunucusunun IP adresini içeren en az bir bağlantı kaydıyla yanıt verir. Daha sonra yanıtlar zincirde aşağıya doğru ilerler; her iletici bu yanıtları, bunları talep eden sunucuya iletir, ta ki yanıt en sonunda yerel sağlayıcının sunucusuna ve kullanıcının bilgisayarına ulaşana kadar. Daha üst düzey sistemleri gereksiz yere rahatsız etmemek için hepsi bu yanıtı önbelleğe alır.
Çoğu durumda, ad sunucusu kayıtları alan.com zaten bu ileticilerden birinde önbelleğe alınmış olacak, böylece kök sunucular etkilenmeyecek. Ancak şimdilik aşina olduğumuz URL türünden bahsediyoruz; normal bir web sitesine dönüştürülen URL. Chrome istekleri aynı düzeyde yukarıda bu, kümelerin kendi adımlarında root-servers.net.
Chromium ve NXDomain hırsızlığı kontrolü
Chromium "bu DNS sunucusu beni kandırıyor mu?" diye kontrol ediyor. Verisign'ın kök DNS sunucuları kümesine ulaşan tüm trafiğin neredeyse yarısını oluşturur.
Google Chrome'un ana projesi olan Chromium tarayıcı, yeni Microsoft Edge ve daha az bilinen sayısız tarayıcı, kullanıcılara bazen "Çok Amaçlı Adres Çubuğu" olarak da adlandırılan tek bir kutuda arama kolaylığı sağlamak istiyor. Başka bir deyişle, kullanıcı tarayıcı penceresinin üst kısmındaki aynı metin alanına hem gerçek URL'leri hem de arama motoru sorgularını girer. Basitleştirmeye doğru bir adım daha atarak kullanıcıyı URL'nin bir kısmını şununla girmeye zorlamaz: http:// veya https://.
Her ne kadar kullanışlı olsa da bu yaklaşım, tarayıcının neyin URL, neyin arama sorgusu olarak kabul edilmesi gerektiğini anlamasını gerektirir. Çoğu durumda bu oldukça açıktır; örneğin, boşluk içeren bir dize URL olamaz. Ancak intranetleri (gerçek web sitelerini çözümlemek için özel üst düzey etki alanlarını da kullanabilen özel ağlar) düşündüğünüzde işler daha da karmaşıklaşabilir.
Şirketinin intranetindeki bir kullanıcı "pazarlama" yazarsa ve şirketin intranetinde aynı adı taşıyan dahili bir web sitesi varsa Chromium, kullanıcıya "pazarlama" kelimesini mi aramak istediğini yoksa şu adrese mi gitmek istediğini soran bir bilgi kutusu görüntüler: https://marketing. Durum böyle olmayabilir, ancak birçok İSS ve halka açık Wi-Fi sağlayıcısı, yanlış yazılan her URL'yi "ele geçirerek" kullanıcıyı banner'larla dolu bir sayfaya yönlendirir.
Rastgele nesil
Chromium geliştiricileri, normal ağlardaki kullanıcıların, tek bir kelimeyi her aradıklarında ne demek istediklerini soran bir bilgi kutusu görmelerini istemediler, bu nedenle bir test uyguladılar: Bir tarayıcı başlattıklarında veya ağları değiştirdiklerinde Chromium, üç bilgisayarda DNS araması gerçekleştirir. rastgele oluşturulmuş "alanlar" üst seviyesi, yedi ila on beş karakter uzunluğunda. Bu isteklerden herhangi ikisi aynı IP adresiyle dönerse Chromium, yerel ağın hataları "ele geçirdiğini" varsayar NXDOMAIN, bu nedenle tarayıcı, girilen tüm tek kelimelik sorguları bir sonraki bildirime kadar arama denemeleri olarak kabul eder.
Maalesef ağlarda hayır DNS sorgularının sonuçlarını çaldığınızda, bu üç işlem genellikle en üstte, kök ad sunucularına kadar yükselir: yerel sunucu nasıl çözüleceğini bilmez qwajuixk, bu talebi ileticisine iletir, o da aynısını yapar ve sonunda a.root-servers.net ya da “kardeşlerinden” biri “Kusura bakmayın ama burası bir alan adı değil” demek zorunda kalmayacak.
Yedi ila on beş karakter uzunluğunda yaklaşık 1,67*10^21 olası sahte alan adı olduğundan, en yaygın olanı her “dürüst” ağ üzerinde gerçekleştirilen bu testlerden kök sunucuya ulaşır. Bu şu kadara denk geliyor yarım Kümelerin o kısmından alınan istatistiklere göre, kök DNS üzerindeki toplam yükün oranı root-servers.netVerisign'a aittir.
Tarih tekerrür ediyor
Bu, bir projenin iyi niyetlerle yaratıldığı ilk sefer değil ya da neredeyse bir kamu kaynağını gereksiz trafikle dolduruyordu - bu bize hemen D-Link ve Poul-Henning Kamp'ın NTP (Ağ Zaman Protokolü) sunucusunun 2000'li yılların ortalarındaki uzun ve üzücü geçmişini hatırlattı.
2005 yılında, Danimarka'nın tek Stratum 1 Ağ Zaman Protokolü sunucusunun da sahibi olan FreeBSD geliştiricisi Poul-Henning, iletilen trafik için beklenmedik ve büyük bir fatura aldı. Kısacası bunun nedeni, D-Link geliştiricilerinin Kampa sunucusu da dahil olmak üzere Stratum 1 NTP sunucularının adreslerini şirketin anahtar, yönlendirici ve erişim noktaları serisinin donanım yazılımına yazmalarıydı. Bu, Kampa'nın sunucu trafiğini anında dokuz kat artırdı ve Danimarka İnternet Değişim Noktası'nın (Danimarka İnternet Değişim Noktası) tarifesini "Ücretsiz"den "yılda 9 $"a değiştirmesine neden oldu.
Sorun çok fazla D-Link yönlendiricisinin olması değil, bunların "hat dışı" olmasıydı. DNS'ye çok benzer şekilde, NTP de hiyerarşik bir biçimde çalışmalıdır - Stratum 0 sunucuları bilgileri Stratum 1 sunucularına aktarır, onlar da bilgileri Stratum 2 sunucularına aktarır ve hiyerarşinin alt kısımlarında bu şekilde devam eder. D-Link'in NTP sunucu adresleriyle programladığı gibi tipik bir ev yönlendiricisi, anahtarı veya erişim noktası, Stratum 2 veya Stratum 3 sunucusuna istek gönderir.
Chromium projesi, muhtemelen en iyi niyetlerle, NTP sorununu DNS sorununda kopyaladı ve İnternet'in kök sunucularına, hiçbir zaman işlemeyecekleri istekler yükledi.
Hızlı bir çözüm için umut var
Chromium projesinin açık kaynağı var Bu sorunu çözmek için Intranet Yönlendirme Algılayıcısının varsayılan olarak devre dışı bırakılmasını gerektirir. Chromium projesinin hakkını vermeliyiz: hata bulundu önceVerisign'dan Matt Thomas, ona nasıl bu kadar dikkat çekti? APNIC blogunda. Hata haziran ayında keşfedildi ancak Thomas'ın gönderisine kadar unutuldu; Orucun ardından yakın gözetim altında tutulmaya başlandı.
Sorunun yakında çözüleceği ve kök DNS sunucularının artık her gün tahmin edilen 60 milyar sahte sorguya yanıt vermek zorunda kalmayacağı umulmaktadır.
Reklam gibi
Epik sunucular - Mı veya güçlü AMD EPYC ailesi işlemcilere ve çok hızlı Intel NVMe sürücülere sahip Linux. Sipariş vermek için acele edin!
Kaynak: habr.com