Браўзэр Chromium, актыўна які развіваецца open-source-бацька Google Chrome і новага Microsoft Edge, звярнуў на сябе сур'ёзная негатыўная ўвага з-за функцыі, якая задумвалася з добрымі намерамі: яна правярае, ці не "выкрадае" ці правайдэр карыстальніка неіснуючыя вынікі запытаў даменаў.
, Які стварае падробленыя запыты выпадковых «даменаў», існаванне якіх статыстычна малаверагодна, адказны прыкладна за палову агульнага трафіку, які атрымліваецца каранёвымі DNS-серверамі па ўсім свеце. Інжынер Verisign Мэт Томас напісаў вялізны у блогу APNIC з апісаннем праблемы і ацэнкай яе маштабу.
Як звычайна выконваецца DNS-пераўтварэнне
Гэтыя серверы з'яўляюцца вышэйшай інстанцыяй, да якой варта звяртацца для рэзалвінгу .com, .net і гэтак далей, каб яны паведамілі вам, што frglxrtmpuf - гэта не дамен верхняга ўзроўню (TLD).
DNS, або Domain Name System ("сістэма даменных імёнаў") - гэта сістэма, дзякуючы якой кампутары могуць пераўтвараць запамінальныя даменныя імёны накшталт arstechnica.com у значна меней зручныя IP-адрасы, напрыклад 3.128.236.93. Без DNS Інтэрнэт не мог бы існаваць у прыдатным для людзей выглядзе, а значыць, непатрэбная нагрузка на інфраструктуру верхняга ўзроўню з'яўляецца рэальнай праблемай.
Для загрузкі адзінай сучаснай вэб-старонкі можа запатрабавацца няўяўная колькасць аперацый DNS-пошуку. Напрыклад, калі мы аналізавалі галоўную старонку ESPN, то налічылі 93 асобныя даменных імя, ад a.espncdn.com да z.motads.com. Усе яны неабходны для поўнай загрузкі старонкі!
Каб такую нагрузку магла вытрымліваць сістэма пошуку, якой неабходна абслугоўваць увесь мір, DNS спраектавана як шматузроўневая іерархія. На вяршыні гэтай піраміды знаходзяцца каранёвыя серверы - кожны дамен верхняга ўзроўню, напрыклад, .com, мае ўласнае сямейства сервераў, якія з'яўляюцца вышэйшай інстанцыяй для кожнага дамена ніжэй за іх. Адной прыступкай вышэй гэтых сервераў знаходзяцца самі каранёвыя сервера, ад a.root-servers.net да m.root-servers.net.
Як часта гэта адбываецца?
Дзякуючы шматузроўневай іерархіі кэшавання інфраструктуры DNS, каранёвых сервераў дасягае вельмі малы працэнт сусветных DNS-запытаў. Большасць людзей атрымлівае інфармацыю DNS-рэзалвера непасрэдна ад свайго правайдэра. Калі прыладзе карыстальніка трэба даведацца, як патрапіць на пэўны сайт, запыт спачатку адпраўляецца DNS-серверу, які кіруецца гэтым лакальным правайдэрам. Калі лакальны DNS-сервер не ведае адказу, ён перанакіроўвае запыт уласным "серверам перасылкі" (у выпадку, калі яны пазначаны).
Калі ні ў DNS-сервера лакальнага правайдэра, ні ў зададзеных у яго канфігурацыі "сервераў перасылкі" няма кэшаванага адказу, запыт паднімаецца непасрэдна да паўнамоцнага сервера дамена. вышэй таго, які вы спрабуеце пераўтварыць. У выпадку домен.com гэта будзе азначаць, што запыт адпраўляецца да паўнамоцных сервераў самага дамена com, якія знаходзяцца па адрасе gtld-servers.net.
Сістэма gtld-servers, да якой быў запыт, адказвае на яго спісам паўнамоцных сервераў імёнаў для дамена дамен.com, а таксама прынамсі адным злучным запісам, утрымоўвальнай IP-адрас аднаго такога сервера імёнаў. Далей адказы спускаюцца па ланцужку - кожны сервер перасылання перадае гэтыя адказы ўніз таму серверу, які іх запытваў, пакуль адказ нарэшце не дасягне сервера лакальнага правайдэра і кампутара карыстальніка. Усе яны пры гэтым кэшуюць гэты адказ, каб без неабходнасці не турбаваць сістэмы больш верхняга ўзроўня.
У большасці выпадкаў запісы сервераў імёнаў для дамен.com ужо будуць кэшаваны на адным з гэтых сервераў перасылання, таму каранёвыя серверы ніхто не трывожыць. Аднак пакуль мы гаворым аб звыклым нам выглядзе URL - тым, які пераўтворыцца ў звычайны вэб-сайт. Запыты Chrome адносяцца да ўзроўню вышэй гэтага, на прыступцы саміх кластараў root-servers.net.
Chromium і праверка выкрадання NXDomain
Праверкі Chromium "гэты DNS-сервер мяне не падманвае?" складаюць амаль палову ўсяго трафіку, які дасягае кластара каранёвых DNS-сервераў Verisign.
Браўзэр Chromium, бацькоўскі праект Google Chrome, новага Microsoft Edge і незлічонай колькасці меней вядомых браўзэраў, жадае забяспечыць карыстачам прастату пошуку ў адным полі, часам званага "Omnibox". Іншымі словамі, карыстач уводзіць і рэальныя URL, і запыты да пошукавага рухавічка ў адно і тое ж тэкставае поле ў верхняй частцы акна браўзэра. Робячы яшчэ адзін крок да спрашчэння, ён таксама не прымушае карыстальніка ўводзіць частку URL з http:// або https://.
Як бы зручна гэта ні было, такі падыход патрабуе, каб браўзэр зразумеў, што трэба лічыць URL, а што - пошукавым запытам. У большасці выпадкаў гэта даволі відавочна - напрыклад, радок з прабеламі не можа быць URL. Але ўсё можа быць хітрэй, калі ўлічыць інтранэт – прыватныя сеткі, якія могуць таксама выкарыстоўваць прыватныя дамены верхняга ўзроўню для рэзалвінгу сапраўдных вэб-сайтаў.
Калі карыстач у інтранэце сваёй кампаніі ўводзіць «marketing», а ў інтранэце кампаніі ёсць унутраны вэб-сайт з такой жа назвай, то Chromium адлюстроўвае інфармацыйнае акно, якое пытаецца карыстача, ці жадае ён шукаць «marketing», або перайсці да https://marketing. Гэта яшчэ куды ні ішло, але многія правайдэры Інтэрнэту і правайдэры агульных сетак Wi-Fi "выкрадаюць" кожны ўведзены з памылкай друку URL, перанакіроўваючы карыстальніка на якую-небудзь нашпігаваны рэкламнымі банэрамі старонку.
Выпадковая генерацыя
Распрацоўнікі Chromium не жадалі, каб карыстачы ў звычайных сетках пры кожным пошуку аднаго слова бачылі інфармацыйнае акно, пытальнае, што тыя мелі ў выглядзе, таму яны рэалізавалі тэст: пры запуску браўзэра або змене сеткі Chromium выконвае аперацыі DNS-пошуку трох выпадкова згенераваных "даменаў" верхняга ўзроўню даўжынёй ад сямі да пятнаццаці сімвалаў. Калі любыя два з гэтых запытаў вяртаюцца з аднолькавым IP-адрасам, то Chromium мяркуе, што лакальная сетка "выкрадае" памылкі. NXDOMAIN, якія ён павінен атрымліваць, таму браўзэр да далейшага апавяшчэння лічыць усе ўведзеныя запыты з аднаго слова спробамі пошуку.
На жаль, у сетках, якія ня выкрадаюць вынікі DNS-запытаў, гэтыя тры аперацыі звычайна паднімаюцца на самы верх, да саміх каранёвых сервераў імёнаў: лакальны сервер не ведае, як пераўтварыць qwajuixk, таму перакідае гэты запыт свайму серверу перасылкі, які робіць тое ж самае, пакуль, нарэшце, a.root-servers.net або адзін з ягоных «братоў» не будзе змушаны сказаць «Прабачце, але гэта не дамен».
Бо існуе прыблізна 1,67*10^21 магчымых фальшывых даменных імёнаў даўжынёй ад сямі да пятнаццаці знакаў, часцей за ўсё кожны з гэтых тэстаў, выкананых у "сумленнай" сетцы, дабіраецца да каранёвага сервера. Гэта складае аж палову ад агульнай нагрузкі на каранёвыя DNS, калі верыць статыстыцы ад той часткі кластараў root-servers.net, якія належаць кампаніі Verisign.
гісторыя паўтараецца
Гэта не першы выпадак, калі створаны з самымі добрымі намерамі праект ці ледзь не завальваў грамадскі рэсурс неабавязковым трафікам - нам гэта адразу ж нагадала доўгую і сумную гісторыю D-Link і NTP-сервера (Network Time Protocol) Поўля-Хеннінга Кампа сярэдзіны 2000-х.
У 2005 году распрацоўнік FreeBSD Поуль-Хеннінг, які валодаў таксама адзіным у Даніі серверам Network Time Protocol узроўня Stratum 1, атрымаў нечаканы і вялікі рахунак за перададзены трафік. Калі сцісла, то чыннік складалася ў тым, што распрацоўнікі D-Link прапісалі адрасы NTP-сервераў Stratum 1, у тым ліку і сервера Кампа, у прашыўку лінейкі камутатараў, маршрутызатараў і кропак доступу кампаніі. Гэта імгненна павысіла ў дзевяць разоў трафік сервера Кампа, з-за чаго Danish Internet Exchange (кропка абмену Інтэрнэт-трафікам Даніі) змяніла яго тарыф з "Бясплатнага" на "9 000 даляраў у год".
Праблема заключалася не ў тым, што маршрутызатараў D-Link было занадта шмат, а ў тым, што яны "парушалі субардынацыю". Амаль як і DNS, NTP павінны працаваць у іерархічнай форме - серверы ўзроўню Stratum 0 перадаюць інфармацыю серверам Stratum 1, якія перадаюць інфармацыю серверам Stratum 2, і гэтак далей, уніз па іерархіі. Звычайны хатні маршрутызатар, камутатар ці кропка доступу накшталт тых, у якія D-Link адштабнавала адрасы NTP-сервераў, павінны былі адпраўляць запыты серверу Stratum 2 ці Stratum 3.
Праект Chromium, верагодна, маючы самыя добрыя намеры, паўтарыў праблему з NTP у праблеме з DNS, загрузіўшы каранёвыя серверы Інтэрнэту запытамі, якія яны ніколі не павінны былі апрацоўваць.
Надзея на хуткае рашэнне ёсць
У праекце Chromium ёсць адкрыты , які патрабуе для ўхілення гэтай праблемы адключэння па змаўчанні Intranet Redirect Detector. Трэба аддаць належнае праекту Chromium: баг быў знойдзены да таго, як Мэт Томас з Verisign прыцягнуў да яго вялікую ўвагу сваім у блогу APNIC. Баг быў адкрыты ў чэрвені, але заставаўся ў забыцці да паста Томаса; пасля паста ён пачаў знаходзіцца пад чулым наглядам.
Ёсць надзея, што праблема хутка будзе вырашана, і каранёвым DNS-серверам больш не давядзецца адказваць штодня на прыкладна 60 мільярдаў фіктыўных запытаў.
На правах рэкламы
Эпічныя серверы - Гэта ці Linux з магутнымі працэсарамі сямейства AMD EPYC і вельмі хуткімі NVMe дыскамі Intel. Спяшайцеся замовіць!
Крыніца: habr.com