{"id":92998,"date":"2020-09-02T01:42:42","date_gmt":"2020-09-01T23:42:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/odna-iz-funkczij-chromium-sozdayot-ogromnuyu-nagruzku-na-kornevye-dns-servery"},"modified":"2020-09-02T01:42:42","modified_gmt":"2020-09-01T23:42:42","slug":"odna-iz-funkczij-chromium-sozdayot-ogromnuyu-nagruzku-na-kornevye-dns-servery","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/odna-iz-funkczij-chromium-sozdayot-ogromnuyu-nagruzku-na-kornevye-dns-servery","title":{"rendered":"Una delle funzioni di Chromium crea un enorme carico sui server DNS di root","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Una
\n
\nIl browser Chromium, in continua evoluzione come progetto open source, genitore di Google Chrome e del nuovo Microsoft Edge, ha attirato l'attenzione negativa a causa di una funzione pensata con buone intenzioni: controlla se il provider dell'utente sta 'rubando' risultati di query per domini inesistenti.<\/p>\n

Rilevatore di Redirect Intranet<\/a><\/noindex>, creando richieste fasulle per 'domini' casuali, la cui esistenza \u00e8 statisticamente improbabile, \u00e8 responsabile di circa met\u00e0 del traffico totale ricevuto dai server DNS di root in tutto il mondo. L'ingegnere di Verisign Matt Thomas ha scritto un lungo post<\/a><\/noindex> nel blog di APNIC descrivendo il problema e valutando la sua portata.
\n<\/a><\/noindex><\/p>\n

Come avviene normalmente la risoluzione DNS<\/h2>\n

\n\"Una
\nQuesti server rappresentano l'istanza suprema a cui ci si deve rivolgere per la risoluzione di .com, .net e cos\u00ec via, per comunicarvi che frglxrtmpuf non \u00e8 un dominio di livello superiore (TLD).<\/i><\/p>\n

Il DNS, o Domain Name System ('sistema dei nomi di dominio'), \u00e8 il sistema che consente ai computer di convertire nomi di dominio memorabili come arstechnica.com in indirizzi IP molto meno pratici, come 3.128.236.93. Senza il DNS, Internet non potrebbe esistere in un formato fruibile per gli esseri umani, quindi il carico non necessario sull'infrastruttura di alto livello \u00e8 un problema reale.<\/p>\n

Per caricare una sola pagina web moderna pu\u00f2 essere necessario un numero incredibile di operazioni di ricerca DNS. Ad esempio, quando abbiamo analizzato la homepage di ESPN, abbiamo contato 93 nomi di dominio distinti, da a.espncdn.com a z.motads.com. Tutti questi sono necessari per il caricamento completo della pagina!<\/p>\n

Affinch\u00e9 un sistema di ricerca possa gestire tale carico, necessario per servire il mondo intero, il DNS \u00e8 progettato come una gerarchia multilivello. Alla sommit\u00e0 di questa piramide ci sono i server di root: ogni dominio di primo livello, ad esempio .com, ha il suo specifico insieme di server, che sono l'istanza superiore per ogni dominio sottostante. Un livello sopra questi<\/em> server ci sono i server di root stessi, da a.root-servers.net<\/code> fino a m.root-servers.net<\/code>.<\/p>\n

Con che frequenza accade?<\/h2>\n

\nGrazie alla gerarchia di caching multi-livello dell'infrastruttura DNS, solo una piccola percentuale delle richieste DNS mondiali raggiunge i server radice. La maggior parte delle persone ottiene le informazioni dal resolver DNS direttamente dal proprio provider. Quando un dispositivo utente deve scoprire come accedere a un determinato sito web, la richiesta viene prima inviata a un server DNS gestito da quel provider locale. Se il server DNS locale non conosce la risposta, reindirizza la richiesta ai propri \"server di inoltro\" (se definiti).<\/p>\n

Se n\u00e9 il server DNS del provider locale n\u00e9 i \"server di inoltro\" specificati nella sua configurazione hanno una risposta memorizzata nella cache, la richiesta viene inviata direttamente al server autoritativo del dominio sopra<\/em> che stai cercando di risolvere. Nel caso di dominio.com<\/code> questo significher\u00e0 che la richiesta viene inviata ai server autoritativi del dominio stesso com<\/code>, che si trovano all'indirizzo gtld-servers.net<\/code>.<\/p>\n

Sistema gtld-servers<\/code>, a cui \u00e8 stata inviata la richiesta, risponde con un elenco di server autoritativi per il dominio dominio.com, oltre a contenere almeno un record di collegamento con l'indirizzo IP di uno di questi server dei nomi. Le risposte vengono quindi trasmesse lungo la catena: ogni server di inoltro trasmette queste risposte al server che le ha richieste, fino a quando la risposta non raggiunge infine il server del provider locale e il computer dell'utente. Tutti memorizzano questa risposta per non dover disturbare i sistemi di livello superiore.<\/p>\n

Nella maggior parte dei casi, i record dei server dei nomi per dominio.com<\/strong> saranno gi\u00e0 memorizzati nella cache su uno di questi server di inoltro, quindi i server radice non vengono disturbati. Tuttavia, mentre parliamo dell'URL che conosciamo \u2014 quello che viene risolto in un normale sito web. Le richieste di Chrome si riferiscono al livello sopra<\/em> di questo, al livello dei cluster stessi root-servers.net<\/code>.<\/p>\n

Chromium e il controllo della cattura NXDomain<\/h2>\n

\n\"Una
\nI controlli di Chromium \"questo server DNS non mi inganna?\" costituiscono quasi la met\u00e0 di tutto il traffico che raggiunge il cluster dei server DNS radice di Verisign.<\/i><\/p>\n

Il browser Chromium, il progetto padre di Google Chrome, del nuovo Microsoft Edge e di un numero incalcolabile di browser meno noti, vuole offrire agli utenti la semplicit\u00e0 di ricerca in un unico campo, talvolta chiamato \u00abOmnibox\u00bb. In altre parole, l'utente inserisce sia gli URL reali che le query nel motore di ricerca nello stesso campo di testo nella parte superiore della finestra del browser. Facendo un ulteriore passo verso la semplificazione, non costringe neanche l'utente a digitare parte dell'URL con http:\/\/<\/code> o https:\/\/<\/code>.<\/p>\n

Per quanto possa essere comodo, questo approccio richiede che il browser capisca cosa considerare un URL e cosa una query di ricerca. Nella maggior parte dei casi \u00e8 abbastanza ovvio - ad esempio, una stringa con spazi non pu\u00f2 essere un URL. Ma la situazione pu\u00f2 complicarsi quando si considerano le intranet, reti private che possono anche utilizzare domini di primo livello privati per risolvere veri siti web.<\/p>\n

Se un utente nella intranet della propria azienda inserisce \u00abmarketing\u00bb e nella intranet dell'azienda c'\u00e8 un sito web interno con lo stesso nome, allora Chromium mostra una finestra informativa che chiede all'utente se desidera cercare \u00abmarketing\u00bb o andare a https:\/\/marketing<\/code>. Questo \u00e8 accettabile, ma molti provider di internet e provider di reti Wi-Fi pubbliche \"rubano\" ogni URL digitato con errori, reindirizzando l'utente a una pagina piena di annunci pubblicitari.<\/p>\n

Generazione casuale<\/h2>\n

\nGli sviluppatori di Chromium non voleva che gli utenti di reti pubbliche vedessero ogni volta una finestra informativa che chiedeva cosa volessero dire, quindi hanno implementato un test: all'avvio del browser o al cambio di rete, Chromium esegue operazioni di ricerca DNS su tre \u00abdomini\u00bb di primo livello generati casualmente, con una lunghezza compresa tra sette e quindici caratteri. Se due di queste richieste restituiscono lo stesso indirizzo IP, allora Chromium presume che la rete locale \"rubi\" gli errori NXDOMAIN<\/code>, che dovrebbe ricevere, quindi il browser considera, fino a nuova comunicazione, tutte le richieste di una sola parola come tentativi di ricerca.<\/p>\n

Sfortunatamente, nelle reti che non<\/em> rubano i risultati delle richieste DNS, queste tre operazioni vengono normalmente elevate al massimo, fino ai server radice dei nomi: il server locale non sa come tradurre qwajuixk<\/code>, quindi inoltra questa richiesta al suo server di inoltro, che fa lo stesso, fino a quando, infine, a.root-servers.net<\/code> o uno dei suoi \u00abfratelli\u00bb \u00e8 costretto a dire \u00abScusa, ma questo non \u00e8 un dominio\u00bb.<\/p>\n

Poich\u00e9 ci sono circa 1,67*10^21 nomi di dominio falsi possibili con una lunghezza compresa tra sette e quindici caratteri, la maggior parte delle volte ognuno<\/em> di questi test, eseguiti in una rete \u00abonesta\u00bb, raggiunge il server radice. Questo rappresenta addirittura met\u00e0<\/em> del carico totale sui DNS radice, se si crede alle statistiche di quella parte dei cluster root-servers.net<\/code>, che appartengono all'azienda Verisign.<\/p>\n

La storia si ripete<\/h2>\n

\nNon \u00e8 il primo caso in cui un progetto creato con le migliori intenzioni \u00e8 fallito<\/a><\/noindex> o ha rischiato di farlo, sommando un traffico non necessario a una risorsa pubblica \u2014 ci ha subito ricordato la lunga e triste storia di D-Link e del server NTP (Network Time Protocol) di Poul-Henning Kamp a met\u00e0 degli anni 2000.<\/p>\n

Nel 2005, il sviluppatore di FreeBSD Poul-Henning, che gestiva anche l'unico server Network Time Protocol di livello Stratum 1 in Danimarca, ricevette una sorprendente e consistente bolletta per il traffico generato. In breve, la ragione era che gli sviluppatori di D-Link avevano inserito gli indirizzi dei server NTP Stratum 1, incluso il server Kampa, nel firmware della loro linea di switch, router e punti di accesso. Ci\u00f2 ha aumentato istantaneamente il traffico del server Kampa di nove volte, portando il Danish Internet Exchange (punto di scambio del traffico Internet in Danimarca) a cambiare la sua tariffa da \"Gratuita\" a \"9 000 dollari all'anno\".<\/p>\n

Il problema non era che ci fossero troppi router D-Link, ma che essi \u00abviolavano la subordinazione\u00bb. Proprio come i DNS, anche i NTP devono funzionare in modo gerarchico \u2014 i server di livello Stratum 0 trasmettono informazioni ai server Stratum 1, che a loro volta le trasmettono ai server Stratum 2, e cos\u00ec via, gi\u00f9 per la gerarchia. Un normale router domestico, switch o punto di accesso, come quelli in cui D-Link ha inserito gli indirizzi dei server NTP, avrebbero dovuto inviare richieste al server Stratum 2 o Stratum 3.<\/p>\n

Il progetto Chromium, probabilmente con le migliori intenzioni, ha ripetuto il problema con gli NTP nel problema con i DNS, sovraccaricando i server radice di Internet con richieste che non avrebbero mai dovuto elaborare.<\/p>\n

C'\u00e8 speranza per una rapida soluzione<\/h2>\n

\nNel progetto Chromium c'\u00e8 un bug aperto bug<\/a><\/noindex>, che richiede per risolvere questo problema di disabilitare per impostazione predefinita Intranet Redirect Detector. Vale la pena menzionare il progetto Chromium: il bug \u00e8 stato trovato prima che<\/em>, Matt Thomas di Verisign attirasse su di esso una enorme attenzione con il suo post separato<\/a><\/noindex> nel blog di APNIC. Il bug \u00e8 stato aperto a giugno, ma \u00e8 rimasto dimenticato fino al post di Thomas; dopo il post ha iniziato a essere monitorato attentamente.<\/p>\n

C'\u00e8 speranza che il problema venga risolto a breve, e i server DNS radice non dovranno pi\u00f9 rispondere quotidianamente a circa 60 miliardi di richieste false.<\/p>\n

<\/p>\n

In base alla pubblicit\u00e0<\/h4>\n

\nServer epici<\/b> \u00e8 VPS su Windows<\/a><\/noindex> o Linux con potenti processori della famiglia AMD EPYC e velocissimi dischi NVMe Intel. Affrettati a ordinare!<\/p>\n

\"Una<\/a><\/noindex>
\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0411\u0440\u0430\u0443\u0437\u0435\u0440 Chromium, \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0449\u0438\u0439\u0441\u044f open-source-\u0440\u043e\u0434\u0438\u0442\u0435\u043b\u044c Google Chrome \u0438 \u043d\u043e\u0432\u043e\u0433\u043e Microsoft Edge, \u043e\u0431\u0440\u0430\u0442\u0438\u043b \u043d\u0430 \u0441\u0435\u0431\u044f \u0441\u0435\u0440\u044c\u0451\u0437\u043d\u043e\u0435 \u043d\u0435\u0433\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u0435 \u0438\u0437-\u0437\u0430 \u0444\u0443\u043d\u043a\u0446\u0438\u0438, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u043b\u0430\u0441\u044c \u0441 \u0431\u043b\u0430\u0433\u0438\u043c\u0438 \u043d\u0430\u043c\u0435\u0440\u0435\u043d\u0438\u044f\u043c\u0438: \u043e\u043d\u0430 \u043f\u0440\u043e\u0432\u0435\u0440\u044f\u0435\u0442, \u043d\u0435 \u00ab\u043f\u043e\u0445\u0438\u0449\u0430\u0435\u0442\u00bb \u043b\u0438 \u043f\u0440\u043e\u0432\u0430\u0439\u0434\u0435\u0440 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044f \u043d\u0435\u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0435 \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u044b \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432 \u0434\u043e\u043c\u0435\u043d\u043e\u0432. Intranet Redirect Detector, \u0441\u043e\u0437\u0434\u0430\u044e\u0449\u0438\u0439 \u043f\u043e\u0434\u0434\u0435\u043b\u044c\u043d\u044b\u0435 \u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u00ab\u0434\u043e\u043c\u0435\u043d\u043e\u0432\u00bb, \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u043e\u0432\u0430\u043d\u0438\u0435 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0441\u0442\u0430\u0442\u0438\u0441\u0442\u0438\u0447\u0435\u0441\u043a\u0438 \u043c\u0430\u043b\u043e\u0432\u0435\u0440\u043e\u044f\u0442\u043d\u043e, \u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u0435\u043d \u043f\u0440\u0438\u043c\u0435\u0440\u043d\u043e \u0437\u0430 \u043f\u043e\u043b\u043e\u0432\u0438\u043d\u0443 \u043e\u0431\u0449\u0435\u0433\u043e \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043f\u043e\u043b\u0443\u0447\u0430\u0435\u043c\u043e\u0433\u043e \u043a\u043e\u0440\u043d\u0435\u0432\u044b\u043c\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":92999,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-92998","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Una delle funzionalit\u00e0 di Chromium genera un enorme carico sui server DNS radice | ProHoster","description":"Browser.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/odna-iz-funkczij-chromium-sozdayot-ogromnuyu-nagruzku-na-kornevye-dns-servery","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0434\u043d\u0430 \u0438\u0437 \u0444\u0443\u043d\u043a\u0446\u0438\u0439 Chromium \u0441\u043e\u0437\u0434\u0430\u0451\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u0443\u044e \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0443 \u043d\u0430 \u043a\u043e\u0440\u043d\u0435\u0432\u044b\u0435 DNS-\u0441\u0435\u0440\u0432\u0435\u0440\u044b | ProHoster","og:description":"\u0411\u0440\u0430\u0443\u0437\u0435\u0440.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/odna-iz-funkczij-chromium-sozdayot-ogromnuyu-nagruzku-na-kornevye-dns-servery","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-01T23:42:42+00:00","article:modified_time":"2020-09-01T23:42:42+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"92998","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:57:25","updated":"2022-09-30 00:56:08","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/92998","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=92998"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/92998\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/92999"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=92998"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=92998"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=92998"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}