A Google Chrome és az új Microsoft Edge nyílt forráskódú szülője, a Chromium böngésző jelentős negatív figyelmet kapott egy jó szándékkal készült funkció miatt: ellenőrzi, hogy a felhasználó internetszolgáltatója nem „lopja-e el” a nem létező domain lekérdezések eredményeit. .
, amely hamis lekérdezéseket hoz létre véletlenszerű "tartományokhoz", amelyek statisztikailag valószínűtlen, hogy létezzenek, és a gyökér DNS-kiszolgálók által világszerte fogadott teljes forgalom körülbelül feléért felelős. Matt Thomas, a Verisign mérnöke hosszasat írt az APNIC blogon a problémát leírva és annak mértékét felmérve.
Hogyan történik a DNS-feloldás általában
Ezek a szerverek a legmagasabb hatóság, amellyel kapcsolatba kell lépnie a .com, .net stb. feloldása érdekében, hogy közöljék, hogy az frglxrtmpuf nem felső szintű tartomány (TLD).
A DNS vagy Domain Name System egy olyan rendszer, amellyel a számítógépek az olyan megjegyezhető tartományneveket, mint az arstechnica.com, sokkal kevésbé felhasználóbarát IP-címekké alakíthatják, mint például a 3.128.236.93. DNS nélkül az internet nem létezne úgy, ahogyan azt az emberek használhatnák, vagyis a felső szintű infrastruktúra szükségtelen terhelése valós probléma.
Egyetlen modern weboldal betöltése hihetetlen számú DNS-keresést igényelhet. Például amikor az ESPN kezdőlapját elemeztük, 93 különálló domain nevet számoltunk, az a.espncdn.com-tól a z.motads.com-ig. Mindegyik szükséges az oldal teljes betöltéséhez!
A DNS-t többszintű hierarchiaként tervezték, hogy az ilyen típusú munkaterheléshez alkalmazkodjon egy olyan keresőmotor számára, amelynek az egész világot ki kell szolgálnia. Ennek a piramisnak a tetején a gyökérszerverek állnak – minden legfelső szintű tartománynak, például a .com-nak megvan a maga kiszolgálócsaládja, amelyek az alattuk lévő tartományok legmagasabb felhatalmazásai. Egy lépéssel feljebb ezek közül A szerverek maguk a gyökérkiszolgálók a.root-servers.net a m.root-servers.net.
Milyen gyakran fordul elő ez?
A DNS-infrastruktúra többszintű gyorsítótárazási hierarchiájának köszönhetően a világ DNS-lekérdezésének nagyon kis százaléka jut el a gyökérkiszolgálókhoz. A legtöbb ember közvetlenül az internetszolgáltatótól kapja meg a DNS-feloldó információit. Amikor a felhasználó eszközének tudnia kell, hogyan juthat el egy adott webhelyre, először egy kérést küld a helyi szolgáltató által kezelt DNS-kiszolgálóhoz. Ha a helyi DNS-szerver nem tudja a választ, akkor továbbítja a kérést saját „továbbítóinak” (ha meg van adva).
Ha sem a helyi szolgáltató DNS-kiszolgálója, sem a konfigurációjában megadott „továbbító szerverek” nem rendelkeznek gyorsítótárazott válaszokkal, a kérés közvetlenül a mérvadó tartománykiszolgálóhoz érkezik. felett akit át akarsz alakítani. Amikor домен.com ez azt jelenti, hogy a kérés magának a tartománynak a mérvadó szervereihez kerül elküldésre com, amelyek a címen találhatók gtld-servers.net.
Rendszer gtld-servers, amelyre a kérés érkezett, válaszol a domain.com domain mérvadó névszervereinek listájával, valamint legalább egy hivatkozásrekorddal, amely egy ilyen névszerver IP-címét tartalmazza. Ezután a válaszok lefelé haladnak a láncon – minden továbbító továbbítja ezeket a válaszokat annak a szervernek, amelyik kérte, amíg a válasz végül el nem éri a helyi szolgáltató szerverét és a felhasználó számítógépét. Mindegyik gyorsítótárazza ezt a választ, hogy ne zavarja szükségtelenül a magasabb szintű rendszereket.
A legtöbb esetben a névszerver rekordok a domain.com már gyorsítótárazott lesz az egyik továbbítón, így a gyökérkiszolgálók nem lesznek zavarva. Egyelőre azonban az általunk ismert URL-típusról beszélünk – arról, amelyet normál webhelypé alakítanak át. A Chrome-kérelmek szinten vannak felett ezt maguknak a klasztereknek a lépcsőjén root-servers.net.
Chromium és NXDomain lopásellenőrzés
A Chromium ellenőrzi: „Ez a DNS-szerver becsap engem?” a Verisign gyökér DNS-kiszolgálóinak fürtjét elérő forgalom közel felét teszik ki.
A Chromium böngésző, a Google Chrome szülőprojektje, az új Microsoft Edge és számtalan kevésbé ismert böngésző egyszerű keresést kíván biztosítani a felhasználóknak egyetlen mezőben, amelyet néha "Omniboxnak" is neveznek. Más szóval, a felhasználó a valódi URL-eket és a keresőmotor lekérdezéseit is beírja ugyanabba a szövegmezőbe a böngészőablak tetején. Újabb lépést tesz az egyszerűsítés felé, és nem kényszeríti a felhasználót az URL egy részének megadására http:// vagy https://.
Bármilyen kényelmes is ez, ez a megközelítés megköveteli a böngészőtől, hogy megértse, mit kell tekinteni URL-nek, és mi tekinthető keresési lekérdezésnek. A legtöbb esetben ez elég nyilvánvaló – például a szóközöket tartalmazó karakterlánc nem lehet URL. De a dolgok bonyolultabbá válhatnak, ha figyelembe vesszük az intraneteket – olyan magánhálózatokat, amelyek privát legfelső szintű domaineket is használhatnak valódi webhelyek megoldására.
Ha egy felhasználó cége intranetjén a „marketing” kifejezést írja be, és a vállalat intranetjén van egy belső webhely ugyanezzel a névvel, akkor a Chromium egy információs mezőt jelenít meg, amelyben megkérdezi a felhasználót, hogy a „marketing” kifejezésre szeretne-e rákeresni, vagy https://marketing. Lehet, hogy nem ez a helyzet, de sok internetszolgáltató és nyilvános Wi-Fi szolgáltató „eltérít” minden hibásan elírt URL-t, és átirányítja a felhasználót valamilyen szalaghirdetéssel teli oldalra.
Véletlenszerű generálás
A Chromium fejlesztői nem akarták, hogy a rendszeres hálózatokon a felhasználók egy információs mezőt lássanak, amely megkérdezi, mire gondolnak, valahányszor egyetlen szóra kerestek, ezért végrehajtottak egy tesztet: Amikor elindítanak egy böngészőt vagy hálózatot váltanak, a Chromium három DNS-keresést hajt végre. véletlenszerűen generált "domain" legfelső szintű, hét-tizenöt karakter hosszú. Ha a kérések közül bármelyik kettő ugyanazzal az IP-címmel tér vissza, akkor a Chromium azt feltételezi, hogy a helyi hálózat „eltéríti” a hibákat. NXDOMAIN, amelyet meg kell kapnia, így a böngésző további értesítésig minden beírt egyszavas lekérdezést keresési kísérletnek tekint.
Sajnos a hálózatokban az nincs ellopni a DNS-lekérdezések eredményeit, ez a három művelet általában a legtetejére emelkedik, egészen a gyökér névszerverekig: a helyi szerver nem tudja, hogyan oldja meg qwajuixk, így továbbítja ezt a kérést továbbítójának, aki ugyanezt teszi, míg végül a.root-servers.net vagy az egyik „testvére” nem lesz kénytelen azt mondani, hogy „Sajnálom, de ez nem egy domain”.
Mivel körülbelül 1,67*10^21 lehetséges hamis domain név hét és tizenöt karakter között van, a leggyakoribb minden ezekből a „becsületes” hálózaton végzett tesztekből jut el a gyökérkiszolgálóhoz. Ez annyit tesz ki fél a gyökér DNS teljes terhelésétől a fürtök azon részének statisztikái szerint root-servers.net, amelyek a Verisign tulajdonában vannak.
A történelem megismétli önmagát
Nem ez az első eset, hogy egy projekt a legjobb szándékkal jött létre vagy csaknem eláraszt egy közforrást a felesleges forgalom – ez rögtön eszünkbe juttatta a D-Link és Poul-Henning Kamp NTP (Network Time Protocol) szerverének hosszú és szomorú történetét a 2000-es évek közepén.
2005-ben a FreeBSD fejlesztője, Poul-Henning, aki Dánia egyetlen Stratum 1 Network Time Protocol szerverét is birtokolta, váratlan és nagy számlát kapott a továbbított forgalomért. Röviden az ok az volt, hogy a D-Link fejlesztői beírták a Stratum 1 NTP szerverek, köztük a Kampa szerver címét a cég kapcsolóinak, útválasztóinak és hozzáférési pontjainak firmware-ébe. Ez azonnal kilencszeresére növelte a Kampa szerverforgalmát, aminek következtében a Danish Internet Exchange (Dániai Internet Exchange Point) tarifáját "ingyenes"-ről "évi 9 dollárra" változtatta.
A probléma nem az volt, hogy túl sok volt a D-Link router, hanem az, hogy „kilógtak a sorból”. A DNS-hez hasonlóan az NTP-nek is hierarchikus formában kell működnie – a Stratum 0 szerverek információt adnak át a Stratum 1 szervereknek, amelyek továbbítják az információkat a Stratum 2 szervereknek, és így tovább a hierarchiában. Egy tipikus otthoni útválasztó, kapcsoló vagy hozzáférési pont, mint amilyen a D-Link NTP-szervercímekkel programozott, kéréseket küld a Stratum 2 vagy Stratum 3 szervernek.
A Chromium projekt, valószínűleg a legjobb szándékkal, megismételte az NTP-problémát a DNS-problémában, és olyan kérésekkel töltötte be az Internet gyökérkiszolgálóit, amelyeket soha nem kellett volna kezelniük.
Van remény a gyors megoldásra
A Chromium projekt nyílt forráskódú , amelyhez a probléma megoldásához alapértelmezés szerint le kell tiltani az Intranet Redirect Detectort. A Chromium projektet érdemeljük: a hibát megtaláltuk azelőtthogy Verisign Matt Thomasa sok figyelmet keltett az övéivel az APNIC blogon. A hibát júniusban fedezték fel, de Thomas bejegyzéséig feledésbe merült; A böjt után szoros felügyelet alatt állt.
Remélhetőleg hamarosan megoldódik a probléma, és a root DNS-kiszolgálóknak már nem kell válaszolniuk a napi 60 milliárd hamis lekérdezésre.
A Reklám Jogairól
Epic szerverek - Van vagy Linux erőteljes AMD EPYC család processzorokkal és nagyon gyors Intel NVMe meghajtókkal. Siess rendelni!
Forrás: will.com