🥇A Chromium egyik funkciója hatalmas terhelést okoz a gyökér DNS-szervereken

A Chromium böngésző, amely a Google Chrome és az új Microsoft Edge aktívan fejlődő nyílt forráskódú szülője, komoly negatív figyelmet kapott egy olyan funkció miatt, amelyet jó szándékkal terveztek: ellenőrzi, hogy a felhasználó szolgáltatója nem "lopja-e el" a keresési lekérdezések nem létező eredményeit az domainek számára.

Intranet Redirect Detector, amely hamis kéréseket generál véletlenszerű "domainekből", amelyek létezése statisztikailag nagyon valószínűtlen, körülbelül a globális gyökér DNS-szerverek összes forgalmának felét teszi ki. A Verisign mérnöke, Matt Thomas kiterjedt bejegyzés bejegyzést írt az APNIC blogban a problémáról és annak mértékéről.

Hogyan történik a DNS-átalakítás

Ezek a szerverek a legfelsőbb hatóság, amelyhez kell fordulni a .com, .net és hasonlók feloldásához, hogy közöljék, hogy frglxrtmpuf - nem a legfelső szintű domain (TLD).

A DNS, vagy Domain Name System ("domain névrendszer") egy olyan rendszer, amely lehetővé teszi, hogy a számítógépek emlékezetbarát domain neveket, mint például arstechnica.com, sokkal kevésbé felhasználóbarát IP-címekké alakítsanak, például 3.128.236.93. DNS nélkül az Internet nem létezhetne emberi értelemben, így a legfelső szintű infrastruktúrára nehezedő felesleges terhelés valós problémát jelent.

Egyetlen modern weboldal betöltéséhez hihetetlen mennyiségű DNS-keresési műveletre lehet szükség. Például, amikor az ESPN főoldalát elemeztük, 93 különböző domainnevet számoltunk össze, a a.espncdn.com-tól a z.motads.com-ig. Mindegyik szükséges a teljes oldal betöltéséhez!

Ahhoz, hogy a keresőrendszer, amelynek a világ egészét ki kell szolgálnia, elviselje ezt a terhelést, a DNS egy többrétegű hierarchiaként lett megtervezve. Ennek a piramisnak a csúcsán találhatók a gyökérszerverek - minden legfelső szintű domain, például a .com, saját szervercsaládot birtokol, amely a legfelsőbb hatóság minden alatta lévő domain számára. Egy lépéssel feljebb ezek a szerverek állnak maguk a gyökérszerverek, a a.root-servers.net tól m.root-servers.net.

Milyen gyakran történik ez?

A DNS-infrastruktúra többrétegű gyorsítótárazásának köszönhetően a gyökérszerverekhez eljutó DNS-kérések globálisan nagyon csekély arányúak. A legtöbb felhasználó a DNS-nyomozót közvetlenül a szolgáltatójától kapja meg. Amikor a felhasználó készülékének meg kell tudnia, hogyan érje el egy adott weboldalt, a kérés először a helyi szolgáltató által üzemeltetett DNS-szerverhez kerül.

Ha sem a helyi szolgáltató DNS-szerverének, sem a konfigurációjában megadott „továbbító szervereknek” nincs cache-elt válasza, a kérés közvetlenül a domain jogosult szerveréhez emelkedik. fentebb amelyet éppen próbál átalakítani. Domaik esetén domain.com ez azt jelenti, hogy a kérés magának a domainnek a jogosult szervereire irányul. com, amelyek a következő címen találhatóak: gtld-servers.net.

Rendszer gtld-servers, amelyhez a kérés érkezett, válaszol egy listával a domain domain.com jogosult névszervereiről, valamint legalább egy hivatkozó rekorddal, amely az egyik ilyen névszerver IP-címét tartalmazza. Ezután a válaszok lefelé haladnak a láncban – minden továbbító szerver átadja ezeket a válaszokat annak a szervernek, amely kérte őket, 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. Ezek mind cache-elik a választ, hogy ne kelljen folyamatosan az magasabb szintű rendszereket zargatni.

A legtöbb esetben a névszerverrekordok már cache-elve lesznek ezen továbbító szerverek egyikén, így a gyökérszervereket senki sem zavarja. Azonban, amíg a megszokott URL-re van szó – amely át van alakítva egy hagyományos weboldallá. A Chrome kérései a következő szinthez tartoznak: domain.com itt, a klaszterek szintjén. fentebb root-servers.net A Chromium és az NXDomain eltérítés ellenőrzése..

A Chromium ellenőrzései, hogy „ez a DNS-szerver nem csap be engem?” a gyökér DNS-szerver klaszterekhez érkező teljes forgalom majdnem felét teszik ki a Verisign számára.

A Chromium ellenőrzések "ez a DNS-szerver nem csal meg engem?" forgalma szinte a teljes forgalom felét teszi ki, amely eléri a Verisign gyökér DNS-szerver klaszterét.

A Chromium böngésző, amely a Google Chrome, az új Microsoft Edge és számtalan kevésbé ismert böngésző alapjául szolgál, az egyszerű keresést szeretné biztosítani a felhasználóknak egy mezőben, amit néha "Omnibox"-nak hívnak. Más szavakkal, a felhasználó egy szöveges mezőbe beírja a valódi URL-eket és a keresési lekérdezéseket egyaránt a böngésző ablakának tetején. A még egyszerűbbé tétel érdekében nem kényszeríti a felhasználót, hogy beírja az URL egy részét. http:// vagy LETS_ENCRYPT_STAGING.

Bár ez kényelmes, ez a megközelítés megköveteli, hogy a böngésző megértse, mit kell URL-ként kezelni, és mit keresési lekérdezésként. A legtöbb esetben ez elég nyilvánvaló — például egy szóközöket tartalmazó szöveg nem lehet URL. De a dolgok bonyolultabbá válhatnak, ha figyelembe vesszük az intraneteket — olyan privát hálózatokat, amelyek szintén használhatnak privát legfelsőbb szintű domaineket valódi webhelyek feloldásához.

Ha a felhasználó a cég intranetjén beírja a "marketing" szót, és az intraneten van egy belső webhely ezzel a névvel, akkor a Chromium egy értesítési ablakot jelenít meg, amely megkérdezi a felhasználót, hogy szeretné-e keresni a "marketing" kifejezésre, vagy át szeretne lépni a https://marketing. Ez még elfogadható, de sok internetszolgáltató és a nyilvános Wi-Fi hálózatok "elcsábítják" az összes tévesen beírt URL-t, átirányítva a felhasználót egy reklámokkal telepakolt oldalra.

Véletlenszerű generálás

A Chromium fejlesztői nem akarták, hogy a felhasználóknak minden kereséskor megjelenjen egy értesítési ablak, amely megkérdezi, hogy mit is érthettek; ezért tesztet valósítottak meg: amikor a böngészőt elindítják, vagy amikor hálózatot változtatnak, a Chromium három véletlenszerűen generált legfelső szintű "domaint" keres DNS-néven, amelyek hossza hét és tizenöt karakter között van. Ha ezek közül bármelyik két kérés azonos IP címmel tér vissza, akkor a Chromium azt feltételezi, hogy a helyi hálózat "elcsábítja" a hibákat, NXDOMAIN, amelyeket meg kellene kapnia, ezért a böngésző további értesítésig minden egy szóból álló lekérdezést keresési próbálkozásnak tekint.

Sajnos azokban a hálózatokban, amelyek nem elcsábítják a DNS-keresések eredményeit, ezek a három művelet általában a legmagasabb szintre emelkedik, a legfőbb névszerverekig: a helyi szerver nem tudja, hogyan kell átalakítani qwajuixk, ezért ezt a kérést a továbbító szerverének továbbítja, amely ugyanúgy jár el, amíg végül a.root-servers.net vagy egyik „testvére” nem kénytelen azt mondani: „Sajnálom, de ez nem egy domain”.

Mivel hozzávetőleg 1,67*10^21 lehetséges hamis domain név létezik, amely héttől tizenöt karakterig terjed, gyakrabban mindegyik ezek a „tisztességes” hálózaton végzett tesztjei eljutnak a gyökérszerverhez. Ez az összesen felét jelenti a gyökér DNS-ek általános terhelésének, ha hihetünk a Verisign által nyújtott statisztikáknak. A Chromium és az NXDomain eltérítés ellenőrzése., amely a Verisign cégéhez tartozik.

A történelem megismétli önmagát

Ez nem az első eset, hogy a legjobb szándékkal létrehozott projekt megbukott vagy majdnem megbukott a közszolgáltatáson, felesleges forgalommal — ez azonnal eszünkbe juttatta a D-Link és a NTP-szerver (Network Time Protocol) Poul-Henning Kamp hosszú és szomorú történetét a 2000-es évek közepén.

2005-ben a FreeBSD fejlesztője, Poul-Henning, aki Dániának az egyetlen Stratum 1 szintű NTP-szerverét is birtokolta, váratlan és magas számlát kapott a forgalomért. Röviden, az volt az oka, hogy a D-Link fejlesztői a Stratum 1 NTP-szerverek, köztük Kamp szerverének címét a vállalat switcheinek, routereinek és hozzáférési pontjainak firmware-jébe írták. Ez kilencszeresére növelte Kamp szerverének forgalmát, ezért a Danish Internet Exchange (Dán Internet-forgalmi csomópont) megváltoztatta az árát „Ingyen”-ről „9 000 dollár évente”-ra.

A problémát nem az jelentette, hogy túl sok D-Link router volt, hanem hogy „megsértették a hierarchiát”. Szinte ahogy a DNS-működés is, az NTP-nek is hierarchikus formában kell működnie — a Stratum 0 szintű szerverek információkat közvetítenek a Stratum 1 szintű szerverek felé, amelyek továbbítják az információkat a Stratum 2 szerverekhez, és így tovább, lefelé a hierarchiában. Azok a tipikus otthoni routerek, switchek vagy hozzáférési pontok, amelyeket a D-Link az NTP-szerverek címeivel látott el, a Stratum 2 vagy Stratum 3 szerverekhez kellett volna, hogy elküldjék a kéréseiket.

A Chromium projekt, valószínűleg a legjobb szándékkal, megismételte az NTP problémát egy DNS problémaként, túlterhelve az Internet gyökérszervereit olyan kérésekkel, amelyeket soha nem kellett volna kezelniük.

Van remény a gyors megoldásra

A Chromium projekt nyitott hiba, amelynek megoldásához az Intranet Redirect Detector alapértelmezett letiltása szükséges. Elismerést érdemel a Chromium projekt: a hibát felfedezték azután, hogy Matt Thomas a Verisign-től hatalmas figyelmet keltett a a blogban közzétettünk egy videót. Az elején volt egy részlet a Harcosok Klubjából – Tyler Durdenra utalva, aki arra gondolt, hogy 25-ös képkockát vágjon filmekbe, miközben mozikban dolgozott. APNIC blogján. A hibát júniusban fedezték fel, de Thomas posztjáig a feledés homályába merült; a poszt után szorosabb figyelem irányult rá.

Van remény arra, hogy a probléma hamarosan megoldódik, és a gyökér DNS szervereknek nem kell naponta körülbelül 60 milliárd hamis kérdésre válaszolniuk.