Chromium զննարկիչը՝ Google Chrome-ի և նոր Microsoft Edge-ի բաց կոդով աշխատող ծնողը, զգալի բացասական ուշադրության է արժանացել մի հատկության համար, որը նախատեսված էր բարի նպատակներով. .
, որը ստեղծում է կեղծ հարցումներ պատահական «տիրույթների» համար, որոնք վիճակագրորեն քիչ հավանական են գոյություն ունենալու համար, պատասխանատու է ամբողջ աշխարհում արմատային DNS սերվերների կողմից ստացված ընդհանուր տրաֆիկի մոտավորապես կեսի համար: Verisign-ի ինժեներ Մեթ Թոմասը երկարատև գրություն է գրել APNIC բլոգում` նկարագրելով խնդիրը և գնահատելով դրա մասշտաբները:
Ինչպես է սովորաբար կատարվում DNS լուծումը
Այս սերվերները ամենաբարձր իշխանությունն են, որոնց հետ պետք է դիմեք .com, .net և այլն լուծելու համար, որպեսզի նրանք ձեզ ասեն, որ frglxrtmpuf-ը վերին մակարդակի տիրույթ չէ (TLD):
DNS-ը կամ Դոմեն Անունների Համակարգը համակարգ է, որով համակարգիչները կարող են լուծել հիշարժան տիրույթի անունները, ինչպիսին է arstechnica.com-ը 3.128.236.93-ի նման օգտատերերի համար ավելի քիչ հարմար IP հասցեների մեջ: Առանց DNS-ի, ինտերնետը չէր լինի այնպես, որ մարդիկ կարողանան օգտագործել, ինչը նշանակում է, որ վերին մակարդակի ենթակառուցվածքի վրա ավելորդ ծանրաբեռնվածությունը իրական խնդիր է:
Մեկ ժամանակակից վեբ էջի բեռնումը կարող է պահանջել անհավանական թվով DNS որոնումներ: Օրինակ, երբ մենք վերլուծել ենք ESPN-ի գլխավոր էջը, մենք հաշվել ենք 93 առանձին տիրույթի անուններ՝ a.espncdn.com-ից մինչև z.motads.com: Դրանք բոլորն անհրաժեշտ են էջն ամբողջությամբ բեռնելու համար:
Այս տեսակի ծանրաբեռնվածությունը որոնողական համակարգի համար, որը պետք է սպասարկի ամբողջ աշխարհը, DNS-ը նախագծված է որպես բազմաստիճան հիերարխիա: Այս բուրգի վերևում գտնվում են արմատային սերվերները. յուրաքանչյուր վերին մակարդակի տիրույթ, ինչպիսին .com-ն է, ունի սերվերների իր ընտանիքը, որոնք իրենցից ցածր յուրաքանչյուր տիրույթի համար ամենաբարձր հեղինակությունն են: Մեկ քայլ վեր այդ սերվերներն իրենք արմատային սերվերներն են՝ սկսած a.root-servers.net դեպի m.root-servers.net.
Որքա՞ն հաճախ է դա տեղի ունենում:
DNS ենթակառուցվածքի բազմաստիճան քեշավորման հիերարխիայի շնորհիվ աշխարհի DNS հարցումների շատ փոքր տոկոսը հասնում է արմատային սերվերներին: Մարդկանց մեծամասնությունը ստանում է իրենց DNS լուծիչի մասին տեղեկությունները անմիջապես իրենց ISP-ից: Երբ օգտագործողի սարքը պետք է իմանա, թե ինչպես հասնել կոնկրետ կայք, հարցումը նախ ուղարկվում է DNS սերվեր, որը կառավարվում է այդ տեղական մատակարարի կողմից: Եթե տեղական DNS սերվերը չգիտի պատասխանը, այն ուղարկում է հարցումն իր «փոխանցողներին» (եթե նշված է):
Եթե ոչ տեղական մատակարարի DNS սերվերը, ոչ էլ դրա կազմաձևում նշված «փոխանցող սերվերները» քեշավորված պատասխան չունեն, հարցումը կբարձրացվի անմիջապես հեղինակավոր տիրույթի սերվերին: վեր մեկը, որը դուք փորձում եք փոխակերպել: Երբ домен.com սա կնշանակի, որ հարցումն ուղարկվում է հենց տիրույթի հեղինակավոր սերվերներին com, որոնք գտնվում են gtld-servers.net.
Համակարգ gtld-servers, որին տրվել է հարցումը, պատասխանում է domain.com տիրույթի հեղինակավոր անունների սերվերների ցանկով, ինչպես նաև առնվազն մեկ հղումային գրառում, որը պարունակում է այդպիսի անունների սերվերի IP հասցեն: Այնուհետև պատասխանները շարժվում են շղթայի ներքև. յուրաքանչյուր առաքիչ փոխանցում է այդ պատասխանները այն սերվերին, որը խնդրել է դրանք, մինչև պատասխանը վերջապես հասնի տեղական մատակարարի սերվերին և օգտագործողի համակարգչին: Նրանք բոլորը պահում են այս պատասխանը, որպեսզի ավելորդ մակարդակի համակարգերը չխանգարեն:
Շատ դեպքերում անունների սերվերի գրառումները domain.com արդեն կքեշավորվի այս փոխանցողներից մեկում, այնպես որ արմատային սերվերները չեն խանգարվի: Այնուամենայնիվ, առայժմ մենք խոսում ենք մեզ ծանոթ URL-ի տեսակի մասին՝ այն, որը վերածվում է սովորական կայքի: Chrome-ի հարցումները գտնվում են մակարդակի վրա վեր սա, բուն կլաստերների աստիճանի վրա root-servers.net.
Chromium-ի և NXDomain-ի գողության ստուգում
Chromium-ը ստուգում է՝ «այս DNS սերվերը խաբո՞ւմ է ինձ»: բաժին է ընկնում Verisign-ի արմատային DNS սերվերների կլաստերին հասնող ամբողջ տրաֆիկի գրեթե կեսին:
Chromium զննարկիչը՝ Google Chrome-ի մայր նախագիծը, նոր Microsoft Edge-ը և անհամար քիչ հայտնի բրաուզերները, ցանկանում են օգտատերերին ապահովել մեկ տուփի մեջ որոնելու հեշտություն, որը երբեմն կոչվում է «Omnibox»: Այլ կերպ ասած, օգտվողը մուտքագրում է և՛ իրական URL-ները, և՛ որոնման համակարգի հարցումները նույն տեքստային դաշտում, որը գտնվում է դիտարկիչի պատուհանի վերևում: Մեկ այլ քայլ կատարելով դեպի պարզեցում, այն նաև չի ստիպում օգտվողին մուտքագրել URL-ի մի մասը http:// կամ https://.
Որքան էլ սա հարմար է, այս մոտեցումը պահանջում է, որ զննարկիչը հասկանա, թե ինչը պետք է համարվի URL, իսկ ինչը պետք է համարվի որոնման հարցում: Շատ դեպքերում դա բավականին ակնհայտ է, օրինակ, բացատներով տողը չի կարող URL լինել: Բայց ամեն ինչ կարող է բարդանալ, երբ հաշվի առնեք ինտրանետները՝ մասնավոր ցանցեր, որոնք կարող են նաև օգտագործել մասնավոր վերին մակարդակի տիրույթներ իրական կայքերը լուծելու համար:
Եթե օգտատերն իր ընկերության ինտրանետում մուտքագրում է «մարքեթինգ», իսկ ընկերության ինտրանետն ունի նույն անունով ներքին կայք, ապա Chromium-ը ցուցադրում է տեղեկատվական դաշտ՝ հարցնելով օգտատիրոջը՝ արդյոք նա ցանկանում է որոնել «մարքեթինգ», թե՞ գնալ 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-ին:
Պատմությունը կրկնվում է
Սա առաջին անգամը չէ, որ լավագույն մտադրություններով ստեղծվող նախագիծը կամ գրեթե ողողել է հանրային ռեսուրսը անհարկի տրաֆիկով - սա անմիջապես հիշեցրեց մեզ 2000-ականների կեսերին D-Link-ի և Poul-Henning Kamp-ի NTP (Ցանցային ժամանակի արձանագրություն) սերվերի երկար ու տխուր պատմությունը:
2005 թվականին FreeBSD-ի ծրագրավորող Փոուլ-Հենինգը, ով նաև պատկանում էր Դանիայի միակ Stratum 1 Network Time Protocol սերվերին, ստացավ անսպասելի և մեծ հաշիվ փոխանցվող տրաֆիկի համար: Մի խոսքով, պատճառն այն էր, որ D-Link ծրագրավորողները գրել էին Stratum 1 NTP սերվերների հասցեները, ներառյալ Kampa սերվերը, ընկերության անջատիչների, երթուղիչների և մուտքի կետերի որոնվածի մեջ: Սա ակնթարթորեն ավելացրեց Kampa-ի սերվերի տրաֆիկը ինը անգամ, ինչի հետևանքով դանիական ինտերնետ փոխանակումը (Դանիական ինտերնետ փոխանակման կետ) փոխեց իր սակագինը «անվճարից» մինչև «9 դոլար տարեկան»:
Խնդիրն այն չէր, որ չափազանց շատ 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 միլիարդ կեղծ հարցումներին:
Գովազդի իրավունքների մասին
Epic սերվերներ - Ից կամ Linux հզոր AMD EPYC ընտանիքի պրոցեսորներով և շատ արագ Intel NVMe կրիչներով: Շտապե՛ք պատվիրել։
Source: www.habr.com