Browser Chromium, induk sumber terbuka Google Chrome lan Microsoft Edge sing anyar, wis entuk perhatian negatif sing signifikan kanggo fitur sing dimaksudake kanthi tujuan sing apik: mriksa manawa ISP pangguna "nyolong" asil pitakon domain sing ora ana. .
, sing nggawe pitakon palsu kanggo "domain" acak sing sacara statistik ora ana, tanggung jawab kanggo kira-kira setengah saka total lalu lintas sing ditampa dening server DNS root ing saindenging jagad. Verisign engineer Matt Thomas wrote dhowo ing blog APNIC njlèntrèhaké masalah lan netepke ukuran sawijining.
Kepiye resolusi DNS biasane ditindakake
Server-server iki minangka panguwasa paling dhuwur sing kudu sampeyan hubungi kanggo ngatasi .com, .net, lan liya-liyane supaya sampeyan bakal ngandhani yen frglxrtmpuf dudu domain tingkat paling dhuwur (TLD).
DNS, utawa Sistem Jeneng Domain, minangka sistem sing komputer bisa ngatasi jeneng domain sing ora bisa dilalekake kaya arstechnica.com dadi alamat IP sing kurang ramah pangguna kaya 3.128.236.93. Tanpa DNS, Internet ora bakal ana kanthi cara sing bisa digunakake manungsa, tegese beban sing ora perlu ing infrastruktur tingkat ndhuwur dadi masalah nyata.
Ngunggah siji kaca web modern bisa mbutuhake jumlah panelusuran DNS sing luar biasa. Contone, nalika nganalisa homepage ESPN, kita ngetung 93 jeneng domain sing kapisah, saka a.espncdn.com nganti z.motads.com. Kabeh mau perlu supaya kaca bisa dimuat kanthi lengkap!
Kanggo nampung jinis beban kerja iki kanggo mesin telusur sing kudu nglayani kabeh jagad, DNS dirancang minangka hierarki multi-level. Ing sisih ndhuwur piramida iki ana server root - saben domain tingkat paling dhuwur, kayata .com, duwe kulawarga server dhewe sing dadi otoritas paling dhuwur kanggo saben domain ing ngisor iki. Siji langkah munggah iki server iku server ROOT dhewe, saka a.root-servers.net kanggo m.root-servers.net.
Sepira kerepe kedadeyan iki?
Thanks kanggo hierarki caching multi-level saka infrastruktur DNS, persentase cilik saka pitakon DNS ing donya tekan server root. Umume wong njaluk informasi DNS resolver langsung saka ISP. Nalika piranti pangguna kudu ngerti carane menyang situs web tartamtu, panjalukan dikirim menyang server DNS sing dikelola dening panyedhiya lokal kasebut. Yen server DNS lokal ora ngerti jawaban kasebut, panjaluk kasebut diterusake menyang "penerus" dhewe (yen kasebut).
Yen server DNS panyedhiya lokal utawa "server penerusan" sing ditemtokake ing konfigurasi kasebut ora duwe respon cache, panyuwunan kasebut langsung menyang server domain sing duwe wewenang luwih sing arep dikonversi. kapan Π΄ΠΎΠΌΠ΅Π½.com iki tegese panyuwunan kasebut dikirim menyang server kuoso saka domain kasebut dhewe com, kang dumunung ing gtld-servers.net.
sistem gtld-servers, sing njaluk panjaluk kasebut, nanggapi kanthi dhaptar server jeneng sing duwe wewenang kanggo domain domain.com, uga paling ora siji rekaman link sing ngemot alamat IP siji server jeneng kasebut. Sabanjure, tanggapan kasebut mudhun ing rantai - saben forwarder ngirim tanggapan kasebut menyang server sing dijaluk, nganti tanggapan kasebut tekan server panyedhiya lokal lan komputer pangguna. Kabeh mau nyimpen respon iki supaya ora ngganggu sistem tingkat sing luwih dhuwur.
Ing kasus paling, jeneng server cathetan kanggo domain.com bakal wis di-cache ing salah siji saka forwarder iki, supaya server ROOT ora bakal Kagodha. Nanging, saiki kita ngomong babagan jinis URL sing kita kenal - sing diowahi dadi situs web biasa. Panjaluk Chrome ana ing level luwih iki, ing langkah saka klompok dhewe root-servers.net.
Kromium lan NXDomain mriksa maling
Chromium mriksa "apa server DNS iki ngapusi aku?" akun kanggo meh setengah saka kabeh lalu lintas tekan Verisign kang kluster saka root DNS server.
Browser Chromium, proyek induk Google Chrome, Microsoft Edge anyar, lan browser sing kurang dikenal, pengin nyedhiyakake pangguna kanthi gampang nggoleki ing kothak siji, kadhangkala disebut "Omnibox." Ing tembung liyane, pangguna ngetik URL nyata lan pitakon mesin telusur menyang kolom teks sing padha ing sisih ndhuwur jendhela browser. Njupuk langkah liyane kanggo nyederhanakake, iku uga ora meksa pangguna kanggo ngetik bagean saka URL karo http:// utawa https://.
Minangka trep kaya iki, pendekatan iki mbutuhake browser kanggo mangerteni apa sing kudu dianggep minangka URL lan apa sing kudu dianggep minangka pitakonan telusuran. Umume kasus iki cukup jelas - contone, senar kanthi spasi ora bisa dadi URL. Nanging samubarang bisa dadi luwih angel nalika sampeyan nganggep intranet-jaringan pribadi sing uga bisa nggunakake domain tingkat paling dhuwur pribadi kanggo mutusake masalah situs web nyata.
Yen pangguna ing intranet perusahaan jinis "pemasaran" lan intranet perusahaan duwe situs web internal kanthi jeneng sing padha, Chromium nampilake kothak informasi sing takon pangguna apa dheweke pengin nggoleki "marketing" utawa pindhah menyang https://marketing. Iki bisa uga ora kedadeyan, nanging akeh ISP lan panyedhiya Wi-Fi umum "nyembajak" saben URL sing salah eja, ngarahake pangguna menyang sawetara kaca sing diisi spanduk.
Generasi acak
Pangembang Chromium ora pengin pangguna ing jaringan biasa ndeleng kothak informasi sing takon apa tegese saben-saben nggoleki tembung siji, mula dheweke nindakake tes: Nalika mbukak browser utawa ngganti jaringan, Chromium nindakake telusuran DNS ing telung tingkat ndhuwur "domain" kanthi acak, dawane pitu nganti limalas karakter. Yen ana loro panjaluk kasebut bali kanthi alamat IP sing padha, Chromium nganggep yen jaringan lokal "mbajak" kesalahan kasebut. NXDOMAIN, sing kudu ditampa, supaya browser nganggep kabeh pitakon siji tembung sing dilebokake minangka upaya panelusuran nganti kabar luwih lanjut.
Sayange, ing jaringan sing ora nyolong asil pitakon DNS, telung operasi iki biasane munggah menyang ndhuwur, kabeh menyang server jeneng root dhewe: server lokal ora ngerti carane ngatasi qwajuixk, supaya nerusake panjalukan iki kanggo forwarder sawijining, kang mengkono padha, nganti pungkasanipun a.root-servers.net utawa salah siji saka "sedulur" ora bakal dipeksa ngomong "Ngapunten, nanging iki dudu domain."
Amarga ana kira-kira 1,67*10^21 jeneng domain palsu sing dawane saka pitung nganti limalas karakter, sing paling umum saben saka tes iki dileksanakake ing jaringan "jujur", iku nemu kanggo server ROOT. Iki jumlahe akeh separo saka beban total ing root DNS, miturut statistik saka bagean kluster kasebut root-servers.net, sing diduweni dening Verisign.
Sejarah mbaleni maneh
Iki dudu sing sepisanan proyek digawe kanthi tujuan sing paling apik utawa meh kebanjiran sumber umum karo lalu lintas rasah - iki langsung ngelingake kita ing sajarah dawa lan sedih D-Link lan Poul-Henning Kamp NTP (Network Time Protocol) server ing agΓͺng-2000s.
Ing taun 2005, pangembang FreeBSD Poul-Henning, sing uga duwe server Stratum 1 Network Time Protocol ing Denmark, nampa tagihan sing ora dikarepke lan gedhe kanggo lalu lintas sing ditularake. Cekakipun, alesan punika pangembang D-Link nulis alamat server Stratum 1 NTP, kalebu server Kampa, menyang perangkat kukuh saka baris perusahaan ngalih, router lan titik akses. Iki langsung nambah lalu lintas server Kampa tikel sanga, nyebabake Denmark Internet Exchange (Denmark Internet Exchange Point) ngganti tarif saka "Gratis" dadi "$9 saben taun."
Masalahe ora amarga akeh router D-Link, nanging "ora ana ing baris". Kaya DNS, NTP kudu beroperasi kanthi bentuk hierarki - Server Stratum 0 ngirim informasi menyang server Stratum 1, sing ngirim informasi menyang server Stratum 2, lan sateruse mudhun ing hirarki. Router omah, saklar, utawa titik akses khas kaya D-Link sing wis diprogram karo alamat server NTP bakal ngirim panjaluk menyang server Stratum 2 utawa Stratum 3.
Proyèk Chromium, mbokmenawa kanthi tujuan sing paling apik, niru masalah NTP ing masalah DNS, ngemot server root Internet kanthi panjaluk sing ora bakal ditindakake.
Ana pangarep-arep kanggo solusi cepet
Proyek Chromium nduweni sumber terbuka , sing mbutuhake mateni Intranet Redirect Detector minangka standar kanggo ngatasi masalah iki. Kita kudu menehi kredit kanggo proyek Chromium: bug kasebut ditemokake sadurunge ikucarane Verisign kang Matt Thomas nggawa wong akèh manungsa waé karo kang ing blog APNIC. Bug ditemokaké ing Juni, nanging tetep lali nganti kirim Thomas; Sawise pasa, dheweke wiwit diawasi kanthi rapet.
Muga-muga masalah kasebut bakal dirampungake, lan server DNS root ora kudu nanggapi 60 milyar pitakon palsu saben dina.
Ing Hak Iklan
Server epik Punika utawa Linux karo prosesor kulawarga AMD EPYC kuat lan drive Intel NVMe cepet banget. Cepet-cepet pesen!
Source: www.habr.com