Browserul Chromium, un proiect open-source în continuă dezvoltare de către Google Chrome și noul Microsoft Edge, a atras o atenție negativă serioasă din cauza unei funcții gândite cu bune intenții: aceasta verifică dacă providerul îi „fură” utilizatorului rezultate inexistente ale căutărilor de domenii.
, generând cereri false pentru „domenii” aleatorii, existența cărora este statistic improbabilă, este responsabil pentru aproximativ jumătate din traficul total obținut de serverele DNS rădăcină din întreaga lume. Inginerul Verisign, Matt Thomas, a scris un articol detaliat pe blogul APNIC, descriind problema și evaluând amploarea acesteia.
Cum se efectuează de obicei transformarea DNS
Aceste servere sunt instanța supremă către care trebuie să te adresezi pentru rezolvarea domeniilor .com, .net și altele, pentru a te informa că frglxrtmpuf nu este un domeniu de nivel superior (TLD).
DNS, sau Sistemul de Nume de Domeniu, este sistemul prin care calculatoarele pot transforma nume de domeniu memorabile, precum arstechnica.com, în adrese IP mult mai puțin convenabile, precum 3.128.236.93. Fără DNS, internetul nu ar putea exista într-o formă ușor accesibilă oamenilor, iar astfel, o încărcare inutilă asupra infrastructurii de nivel înalt devine o problemă reală.
Pentru a încărca o singură pagină web modernă, pot fi necesare un număr inimaginabil de operațiuni de căutare DNS. De exemplu, atunci când am analizat pagina principală ESPN, am numărat 93 de nume de domeniu separate, de la a.espncdn.com până la z.motads.com. Toate acestea sunt necesare pentru încărcarea completă a paginii!
Pentru ca un sistem de căutare să poată suporta o asemenea încărcare, având nevoie să servească întreaga lume, DNS este proiectat ca o ierarhie multi-nivel. În vârful acestei piramide se află serverele rădăcină - fiecare domeniu de nivel superior, cum ar fi .com, are propria sa familie de servere care sunt instanța supremă pentru fiecare domeniu de sub ele. O treaptă mai sus aceste servere se află serverele rădăcină în sine, de la a.root-servers.net la m.root-servers.net.
Cât de des se întâmplă asta?
Datorită ierarhiei multilayer de caching a infrastructurii DNS, un procent foarte mic din solicitările DNS globale ajunge la serverele rădăcină. Majoritatea oamenilor primesc informații DNS direct de la furnizorul lor. Când un dispozitiv al utilizatorului trebuie să afle cum să acceseze un anumit site, cererea este trimisă inițial unui server DNS gestionat de acest furnizor local. Dacă serverul DNS local nu știe răspunsul, redirecționează cererea către „serverele de redirecționare” proprii (în cazul în care acestea sunt specificate).
Dacă nici serverul DNS al furnizorului local, nici serverele de redirecționare specificate în configurarea sa nu au răspunsul stocat, cererea este trimisă direct la serverul de autoritate al domeniului mai sus pe care încerci să-l convertești. În cazul domeniului.com asta va însemna că cererea este trimisă către serverele de autoritate ale domeniului însuși com, care se află la adresa gtld-servers.net.
Sistem gtld-servers, la care a fost trimisă cererea, răspunde cu o listă de servere de autoritate ale numelui pentru domeniul domeniu.com, precum și cu cel puțin un înregistrare de legătură care conține IP-ul unuia dintre aceste servere de nume. Apoi, răspunsurile sunt transmise în jos — fiecare server de redirecționare transmite aceste răspunsuri către serverul care le-a solicitat, până când răspunsul ajunge în cele din urmă la serverul furnizorului local și computerul utilizatorului. Toate acestea stochează acest răspuns pentru a nu perturba sistemele de nivel superior fără necesitate.
În cele mai multe cazuri, înregistrările serverelor de nume pentru domeniului.com vor fi deja stocate pe unul dintre aceste servere de redirecționare, astfel că serverele rădăcină nu sunt deranjate. Cu toate acestea, deocamdată discutăm despre forma obișnuită a URL-ului — cea care se convertește într-un site web obișnuit. Cererile Chrome se referă la nivelul mai sus acestuia, la nivelul grupurilor de servere root-servers.net.
Chromium și verificarea furtului NXDomain
Verificările Chromium „acest server DNS nu mă înșală?” constituie aproape jumătate din traficul care ajunge la clusterele serverelor DNS de rădăcină Verisign.
Browserul Chromium, proiectul părinte al Google Chrome, al noului Microsoft Edge și al unui număr incalculabil de browsere mai puțin cunoscute, își propune să ofere utilizatorilor o modalitate simplă de căutare într-un singur câmp, uneori numit „Omnibox”. Cu alte cuvinte, utilizatorul poate introduce atât URL-uri reale, cât și interogări în motorul de căutare într-un singur câmp text aflat în partea de sus a ferestrei browserului. Facând un alt pas în direcția simplificării, acesta nu îi cere utilizatorului să introducă o parte din URL cu http:// sau https://.
Deși poate părea comod, această abordare necesită ca browserul să înțeleagă ce trebuie considerat un URL și ce este o interogare de căutare. În majoritatea cazurilor, acest lucru este destul de evident — de exemplu, o linie cu spații nu poate fi un URL. Dar lucrurile pot fi mai complicate dacă luăm în considerare intranetele — rețele private care pot folosi, de asemenea, domenii de nivel superior private pentru a rezolva adevăratele site-uri web.
Dacă un utilizator în intranetul companiei sale introduce „marketing”, iar în intranetul companiei există un site web intern cu același nume, atunci Chromium afișează un mesaj informativ, întrebând utilizatorul dacă dorește să caute „marketing” sau să acceseze https://marketing. Acesta este un început, dar mulți furnizori de Internet și furnizori de rețele Wi-Fi publice „fura” fiecare URL introdus cu greșeli de tipar, redirecționând utilizatorul către o pagină plină de bannere publicitare.
Generare aleatorie
Dezvoltatorii Chromium nu au dorit ca utilizatorii din rețelele obișnuite să primească un mesaj informativ la fiecare căutare a unui cuvânt, întrebându-i ce au avut în vedere, așa că au implementat un test: când browserul este lansat sau când se schimbă rețeaua, Chromium efectuează operațiuni de căutare DNS pentru trei „domenii” de nivel superior generate aleatoriu, cu lungimi între șapte și cincisprezece caractere. Dacă oricare dintre aceste două cereri se returnează cu același IP, atunci Chromium presupune că rețeaua locală „fură” erorile NXDOMAIN, pe care ar trebui să le primească, așa că browserul consideră, până la o notificare ulterioară, toate cererile introduse dintr-un singur cuvânt ca fiind încercări de căutare.
Din păcate, în rețelele care nu fură rezultatele cererilor DNS, aceste trei operațiuni sunt în general ridicate la cel mai înalt nivel, până la serverele de nume rădăcină: serverul local nu știe cum să transforme qwajuixk, așa că redirecționează această cerere către serverul său de redirecționare, care face același lucru, până când, în cele din urmă, a.root-servers.net sau unul dintre „frații” săi nu va fi obligat să spună „Îmi pare rău, dar acesta nu este un domeniu”.
Deoarece există aproximativ 1,67*10^21 posibile nume de domenii false cu lungimi cuprinse între șapte și cincisprezece caractere, cel mai frecvent fiecare dintre aceste teste, efectuate în rețeaua „corectă”, ajunge la serverul rădăcină. Aceasta reprezintă nu mai puțin de jumătate din încărcătura totală pe DNS-urile rădăcină, dacă ne luăm după statisticile acelei părți a clusterelor root-servers.net, care aparțin companiei Verisign.
Istoria se repetă
Nu este primul caz în care un proiect creat cu cele mai bune intenții sau a fost pe punctul de a eșua o resursă publică cu trafic inutil — ne-a amintit imediat de lunga și tristă poveste a lui D-Link și serverul NTP (Network Time Protocol) al lui Poul-Henning Kamp din mijlocul anilor 2000.
În 2005, dezvoltatorul FreeBSD Poul-Henning, care deținea de asemenea singurul server NTP de nivel Stratum 1 din Danemarca, a primit o factură neașteptată și mare pentru traficul transmis. Pe scurt, motivul a fost că dezvoltatorii D-Link au inclus adresele serverelor NTP de nivel Stratum 1, inclusiv serverul lui Kamp, în firmware-ul liniei de switch-uri, routere și puncte de acces ale companiei. Acest lucru a crescut instantaneu traficul serverului lui Kamp de nouă ori, motiv pentru care Danish Internet Exchange (punctul de schimb de trafic pe Internet al Danemarcei) i-a schimbat tariful de la „Gratuit” la „9000 de dolari pe an”.
Problema nu era că erau prea multe routere D-Link, ci că acestea „încălcau subordonarea”. Aproape ca DNS, NTP trebuie să funcționeze într-o formă ierarhică — serverele de nivel Stratum 0 transmit informații serverelor de Stratum 1, care transmit informații serverelor de Stratum 2 și așa mai departe, în jos pe ierarhie. Un router, switch sau punct de acces obișnuit de acasă, de tipul celor în care D-Link a inclus adresele serverelor NTP, ar fi trebuit să trimită cereri serverelor de Stratum 2 sau Stratum 3.
Proiectul Chromium, având probabil cele mai bune intenții, a repetat problema cu NTP în problema cu DNS, încărcând serverele rădăcină ale Internetului cu cereri pe care nu ar fi trebuit niciodată să le gestioneze.
Există speranțe pentru o soluție rapidă
În proiectul Chromium există un incident deschis , care necesita pentru a remedia această problemă dezactivarea implicită a Intranet Redirect Detector. Trebuie să dăm dreptate proiectului Chromium: bug-ul a fost descoperit înainte de, cum Matt Thomas de la Verisign a atras o mare atenție asupra lui prin în blogul APNIC. Bug-ul a fost raportat în iunie, dar a rămas în uitare până la postarea lui Thomas; după postare, a început să fie monitorizat îndeaproape.
Există speranța că problema va fi rezolvată în curând, iar serverele DNS rădăcină nu vor mai trebui să răspundă zilnic la aproximativ 60 de miliarde de solicitări false.
În numele publicității
Servere epice — acesta este sau Linux cu procesoare puternice din familia AMD EPYC și SSD-uri NVMe Intel foarte rapide. Grăbiți-vă să comandați!
Sursa: habr.com
