Ցածր DNS ուշացումն առանցքային է արագ ինտերնետ զննարկման համար: Այն նվազագույնի հասցնելու համար կարևոր է ուշադիր ընտրել DNS սերվերները և . Բայց առաջին քայլը անօգուտ հարցումներից ազատվելն է։
Սա է պատճառը, որ DNS-ն ի սկզբանե նախագծվել է որպես բարձր քեշավոր արձանագրություն: Գոտու ադմինիստրատորները սահմանում են ապրելու ժամանակը (TTL) առանձին մուտքերի համար, և լուծողները օգտագործում են այս տեղեկատվությունը հիշողության մեջ գրառումները պահելիս՝ խուսափելու ավելորդ տրաֆիկից:
Արդյո՞ք քեշավորումն արդյունավետ է: Մի քանի տարի առաջ իմ փոքրիկ հետազոտությունը ցույց տվեց, որ այն կատարյալ չէր: Եկեք նայենք գործերի ներկա վիճակին:
Для сбора информации я пропатчил պատասխանի համար TTL արժեքը պահպանելու համար: Այն սահմանվում է որպես իր գրառումների նվազագույն TTL յուրաքանչյուր մուտքային հարցման համար: Սա լավ պատկերացում է տալիս իրական տրաֆիկի TTL բաշխման մասին, ինչպես նաև հաշվի է առնում անհատական հարցումների հանրաճանաչությունը: Սերվերի կարկատված տարբերակը մի քանի ժամ աշխատեց:
Результирующий набор данных состоит из 1 583 579 записей (name, qtype, TTL, timestamp). Вот общее распределение TTL (ось X — это TTL в секундах):
Если не считать незначительного бугра на 86 400 (в основном, для записей SOA), довольно очевидно, что TTL находятся в низком диапазоне. Посмотрим ближе:
Լավ, 1 ժամից ավելի TTL-ները վիճակագրորեն նշանակալի չեն: Այնուհետև եկեք կենտրոնանանք 0−3600 միջակայքի վրա.
TTL-ների մեծ մասը տևում է 0-ից մինչև 15 րոպե.
Ճնշող մեծամասնությունը 0-ից 5 րոպե է.
Դա այնքան էլ լավ չէ:
Կուտակային բաշխումը խնդիրն ավելի ակնհայտ է դարձնում.
DNS պատասխանների կեսն ունի TTL 1 րոպե կամ ավելի քիչ, իսկ երեք քառորդը՝ TTL 5 րոպե կամ ավելի քիչ:
Բայց սպասեք, իրականում ավելի վատ է: Ի վերջո, սա TTL է հեղինակավոր սերվերներից: Այնուամենայնիվ, հաճախորդի լուծիչները (օրինակ՝ երթուղիչները, տեղական քեշերը) ստանում են TTL վերին հոսքի լուծիչներից, և այն նվազում է ամեն վայրկյան:
Այսպիսով, հաճախորդը կարող է իրականում օգտագործել յուրաքանչյուր մուտքագրում, միջին հաշվով, օրիգինալ TTL-ի կեսի համար՝ նախքան նոր հարցում ուղարկելը:
Միգուցե այս շատ ցածր TTL-ները վերաբերում են միայն արտասովոր հարցումներին, այլ ոչ թե հանրաճանաչ կայքերին և API-ներին: Եկեք նայենք.
X առանցքը TTL է, Y առանցքը հարցումների ժողովրդականություն է:
Ցավոք, ամենահայտնի հարցումները նաև ամենավատն են քեշում:
Եկեք խոշորացնենք.
Դատավճիռ. դա իսկապես վատ է: Նախկինում արդեն վատ էր, բայց ավելի վատացավ։ DNS քեշավորումը գործնականում անօգուտ է դարձել: Քանի որ ավելի քիչ մարդիկ օգտագործում են իրենց ISP-ի DNS լուծիչը (լավ պատճառներով), հետաձգման աճն ավելի նկատելի է դառնում:
DNS քեշավորումը դարձել է օգտակար միայն այն բովանդակության համար, որը ոչ ոք չի այցելում:
Խնդրում ենք նաև նկատի ունենալ, որ ծրագրաշարը կարող է մեկնաբանել ցածր TTL-ները:
Ինչու:
Ինչու՞ են DNS գրառումները դրված այդքան ցածր TTL-ի վրա:
- Ժառանգական բեռի հավասարակշռիչները մնացել են լռելյայն կարգավորումներով:
- Առասպելներ կան, որ DNS բեռի հավասարակշռումը կախված է TTL-ից (սա ճիշտ չէ. Netscape Navigator-ի օրերից հաճախորդները ընտրել են պատահական IP հասցե մի շարք RR-ներից և թափանցիկ փորձել են մեկ այլ հասցե, եթե չկարողանան միանալ):
- Ադմինիստրատորները ցանկանում են անմիջապես կիրառել փոփոխությունները, ուստի ավելի հեշտ է պլանավորել:
- DNS սերվերի կամ բեռի հավասարակշռողի ադմինիստրատորն իր խնդիրն է համարում արդյունավետորեն կիրառել օգտատերերի պահանջած կոնֆիգուրացիան և ոչ թե արագացնել կայքերն ու ծառայությունները:
- Ցածր TTL-ները ձեզ հանգիստ են տալիս:
- Люди первоначально ставят низкие TTL для тестирования и забывают потом их изменить.
Ես չներառեցի «failover»-ը ցուցակում, քանի որ այն գնալով ավելի քիչ ակտուալ է դառնում: Եթե Ձեզ անհրաժեշտ է օգտատերերին վերահղել այլ ցանց՝ պարզապես սխալի էջ ցուցադրելու համար, երբ մնացած բոլորը բացարձակապես կոտրված են, 1 րոպեից ավելի ուշացումը հավանաբար ընդունելի է:
Բացի այդ, մեկ րոպեանոց TTL-ը նշանակում է, որ եթե հեղինակավոր DNS սերվերներն արգելափակվեն 1 րոպեից ավելի, ոչ ոք չի կարողանա մուտք գործել կախյալ ծառայություններ: Եվ ավելորդությունը չի օգնի, եթե պատճառը կազմաձևման սխալն է կամ կոտրումը: Մյուս կողմից, ողջամիտ TTL-ների դեպքում շատ հաճախորդներ կշարունակեն օգտագործել նախկին կոնֆիգուրացիան և երբեք ոչինչ չեն նկատել:
CDN ծառայությունները և բեռի հավասարակշռողները հիմնականում մեղավոր են ցածր TTL-ների համար, հատկապես, երբ դրանք համատեղում են CNAME-ները ցածր TTL-ներով և գրառումները նույնքան ցածր (բայց անկախ) TTL-ներով.
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
Ամեն անգամ, երբ CNAME-ի կամ A գրառումներից որևէ մեկի ժամկետն ավարտվում է, պետք է նոր հարցում ուղարկվի: Երկուսն էլ ունեն 30 վայրկյան TTL, բայց դա նույնը չէ: Փաստացի միջին TTL-ը կկազմի 15 վայրկյան:
Բայց սպասե՛ք։ Նույնիսկ ավելի վատ է: Որոշ լուծիչներ շատ վատ են վարվում այս իրավիճակում երկու կապված ցածր TTL-ներով.
$ փորեք raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com: 1 CNAME-ում github.map.fastly.net: github.map.fastly.net. 1 IN A 151.101.16.133
Level3 լուծիչը հավանաբար աշխատում է BIND-ով: Եթե շարունակեք ուղարկել այս հարցումը, 1 TTL-ը միշտ կվերադարձվի: Հիմնականում, raw.githubusercontent.com երբեք չի պահվում:
Ահա այսպիսի իրավիճակի ևս մեկ օրինակ՝ շատ տարածված տիրույթով.
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
Не менее трёх записей CNAME. Ай. У одной приличный TTL, но это совершенно бесполезно. В других CNAME первоначальный TTL составляет 60 секунд, но для доменов akamai.net առավելագույն TTL-ը 20 վայրկյան է, և դրանցից ոչ մեկը փուլային չէ:
Как насчёт доменов, которые постоянно опрашивают устройства Apple?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
Նույն խնդիրը, ինչ Firefox-ը և TTL-ը, ժամանակի մեծ մասում 1 վայրկյանում կմնան Level3 լուծիչ օգտագործելիս:
Dropbox?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com: 7 CNAME-ում client.dropbox-dns.com: client.dropbox-dns.com. 59 IN A 162.125.67.3 $ փորված client.dropbox.com @4.2.2.2 client.dropbox.com: 1 CNAME-ում client.dropbox-dns.com: client.dropbox-dns.com. 1 IN A 162.125.64.3
Ձայնագրության ժամանակ safebrowsing.googleapis.com TTL արժեքը 60 վայրկյան է, ինչպես Facebook տիրույթները: Եվ կրկին, հաճախորդի տեսանկյունից, այս արժեքները կրկնակի կրճատվում են:
Ի՞նչ կասեք նվազագույն TTL սահմանելու մասին:
Օգտագործելով անունը, հարցման տեսակը, TTL-ը և սկզբնապես պահված ժամանակի դրոշմը, ես գրեցի սկրիպտ՝ քեշավորման լուծիչով անցնող 1,5 միլիոն հարցումների մոդելավորման համար՝ ժամկետանց քեշի մուտքագրման պատճառով ուղարկված անհարկի հարցումների ծավալը գնահատելու համար:
47,4% запросов были сделаны после истечения срока действия существующей записи. Это неоправданно высоко.
Ի՞նչ ազդեցություն կունենա քեշավորման վրա, եթե սահմանվի նվազագույն TTL:
X առանցքը նվազագույն TTL արժեքներն են: Այս արժեքից բարձր աղբյուրի TTL-ներով գրառումները չեն ազդում:
Y առանցքը հաճախորդի հարցումների տոկոսն է, որն արդեն ունի պահված մուտքագրում, բայց ժամկետը լրացել է և նոր հարցում է կատարում:
«Լրացուցիչ» հարցումների մասնաբաժինը 47%-ից կրճատվում է մինչև 36%՝ պարզապես նվազագույն TTL-ը դնելով 5 րոպե: Նվազագույն TTL-ը դնելով 15 րոպե, այս հարցումների թիվը նվազում է մինչև 29%: Նվազագույն TTL 1 ժամն իջեցնում է դրանք մինչև 17%: Զգալի տարբերություն!
Ի՞նչ կասեք սերվերի կողմից որևէ բան չփոխելու մասին, այլ փոխարենը սահմանել նվազագույն TTL հաճախորդի DNS քեշերում (երթուղիչներ, տեղական լուծիչներ):
Պահանջվող հարցումների քանակը նվազում է 47%-ից մինչև 34%՝ նվազագույն TTL 5 րոպեի դեպքում, մինչև 25%՝ նվազագույնը 15 րոպեի դեպքում և մինչև 13%՝ նվազագույնը 1 ժամով: Թերևս 40 րոպեն օպտիմալ է:
Влияние этого минимального изменения огромно.
Որո՞նք են դրա հետևանքները:
Իհարկե, ծառայությունը կարող է տեղափոխվել նոր ամպային մատակարար, նոր սերվեր, նոր ցանց՝ հաճախորդներից պահանջելով օգտագործել վերջին DNS գրառումները: Եվ բավականին փոքր TTL-ն օգնում է սահուն և աննկատելիորեն նման անցում կատարել: Բայց նոր ենթակառուցվածքին անցնելու դեպքում ոչ ոք չի ակնկալում, որ հաճախորդները տեղափոխվեն նոր DNS գրառումներ 1 րոպեի, 5 րոպեի կամ 15 րոպեի ընթացքում: Նվազագույն TTL-ը 40 րոպեի փոխարեն 5 րոպե սահմանելը չի խանգարի օգտատերերին օգտվել ծառայությունից:
Այնուամենայնիվ, դա զգալիորեն կնվազեցնի ուշացումը և կբարելավի գաղտնիությունն ու հուսալիությունը՝ խուսափելով ավելորդ հարցումներից:
Конечно, RFC говорят, что нужно строго соблюдать TTL. Но реальность такова, что система DNS стала слишком неэффективной.
Եթե դուք աշխատում եք հեղինակավոր DNS սերվերների հետ, խնդրում ենք ստուգել ձեր TTL-ները: Ձեզ իրո՞ք պետք են նման անհեթեթ ցածր արժեքներ։
Իհարկե, DNS գրառումների համար փոքր TTL-ներ սահմանելու լավ պատճառներ կան: Բայց ոչ DNS տրաֆիկի 75%-ի համար, որը գրեթե անփոփոխ է մնում:
Եվ եթե ինչ-ինչ պատճառներով դուք իսկապես պետք է օգտագործեք ցածր TTL-ներ DNS-ի համար, միևնույն ժամանակ համոզվեք, որ ձեր կայքում միացված չէ քեշավորումը: Նույն պատճառներով.
Եթե ունեք տեղական DNS քեշ, որն աշխատում է, օրինակ որը թույլ է տալիս սահմանել նվազագույն TTL-ներ, օգտագործեք այս գործառույթը: Սա լավ է: Ոչ մի վատ բան չի լինի։ Սահմանեք նվազագույն TTL-ը մոտավորապես 40 րոպե (2400 վայրկյան) և 1 ժամ: Բավականին ողջամիտ միջակայք։
Source: www.habr.com