Мало кашњење ДНС-а је кључно за брзо претраживање интернета. Да бисте га минимизирали, важно је пажљиво одабрати ДНС сервере и . Али први корак је да се решите бескорисних упита.
Због тога је ДНС првобитно дизајниран као протокол који се може кеширати. Администратори зоне постављају време трајања (ТТЛ) за појединачне уносе, а разрешивачи користе ове информације када чувају уносе у меморији како би избегли непотребан саобраћај.
Да ли је кеширање ефикасно? Пре неколико година, моје мало истраживање је показало да није савршено. Хајде да погледамо тренутно стање ствари.
Да прикупим информације које сам закрпио да сачувате ТТЛ вредност за одговор. Дефинише се као минимални ТТЛ његових записа за сваки долазни захтев. Ово даје добар преглед ТТЛ дистрибуције стварног саобраћаја, а такође узима у обзир популарност појединачних захтева. Закрпљена верзија сервера је радила неколико сати.
Добијени скуп података се састоји од 1 записа (име, ктипе, ТТЛ, временска ознака). Ево укупне ТТЛ дистрибуције (Кс-оса је ТТЛ у секундама):
Осим мањег скока на 86 (углавном за СОА записе), прилично је јасно да су ТТЛ-ови у ниском опсегу. Хајде да погледамо ближе:
У реду, ТТЛ дужи од 1 сата нису статистички значајни. Онда хајде да се фокусирамо на опсег 0−3600:
Већина ТТЛ-ова је од 0 до 15 минута:
Велика већина је од 0 до 5 минута:
Није баш добро.
Кумулативна дистрибуција чини проблем још очигледнијим:
Половина ДНС одговора има ТТЛ од 1 минута или мање, а три четвртине има ТТЛ од 5 минута или мање.
Али чекај, заправо је горе. На крају крајева, ово је ТТЛ са ауторитативних сервера. Међутим, клијентски разрешивачи (нпр. рутери, локални кешови) примају ТТЛ од узводних резолвера и он се смањује сваке секунде.
Дакле, клијент заправо може да користи сваки унос за, у просеку, половину оригиналног ТТЛ-а пре него што пошаље нови захтев.
Можда се ови веома ниски ТТЛ примењују само на необичне захтеве, а не на популарне веб локације и АПИ-је? Хајде да погледамо:
Кс оса је ТТЛ, И оса је популарност упита.
Нажалост, најпопуларнији упити су такође најгори за кеширање.
Хајде да увећамо:
Пресуда: стварно је лоше. Раније је већ било лоше, али је постало још горе. ДНС кеширање је постало практично бескорисно. Како све мање људи користи ДНС резолвер свог ИСП-а (из добрих разлога), повећање латенције постаје приметно.
ДНС кеширање је постало корисно само за садржај који нико не посећује.
Такође имајте на уму да софтвер може интерпретирати ниске ТТЛ.
Зашто тако?
Зашто су ДНС записи подешени на тако низак ТТЛ?
- Застарели балансери оптерећења су остављени са подразумеваним подешавањима.
- Постоје митови да балансирање оптерећења ДНС-а зависи од ТТЛ-а (ово није тачно - од времена Нетсцапе Навигатора, клијенти су бирали случајну ИП адресу из скупа РР-ова и транспарентно покушавали другу ако не могу да се повежу)
- Администратори желе одмах да примене промене, тако да је лакше планирати.
- Администратор ДНС сервера или балансера оптерећења види свој задатак као ефикасно постављање конфигурације коју корисници траже, а не убрзавање сајтова и услуга.
- Ниски ТТЛ вам пружају мир.
- Људи у почетку постављају ниске ТТЛ-ове за тестирање, а затим заборављају да их промене.
Нисам укључио "фаиловер" на листу јер постаје све мање релевантан. Ако требате да преусмерите кориснике на другу мрежу само да бисте приказали страницу са грешком када је апсолутно све остало покварено, кашњење од више од 1 минута је вероватно прихватљиво.
Поред тога, ТТЛ од једног минута значи да ако су ауторитативни ДНС сервери блокирани дуже од 1 минута, нико други неће моћи да приступи зависним услугама. А редундантност неће помоћи ако је узрок грешка у конфигурацији или хак. С друге стране, са разумним ТТЛ-овима, многи клијенти ће наставити да користе претходну конфигурацију и никада ништа неће приметити.
ЦДН услуге и балансери оптерећења су у великој мери криви за ниске ТТЛ-ове, посебно када комбинују ЦНАМЕ-ове са ниским ТТЛ-овима и записе са једнако ниским (али независним) ТТЛ-овима:
$ 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
Кад год ЦНАМЕ или било који од А записа истекне, мора се послати нови захтев. Оба имају ТТЛ од 30 секунди, али то није исто. Стварни просечан ТТЛ ће бити 15 секунди.
Али чекај! Још је горе. Неки разрешивачи се понашају веома лоше у овој ситуацији са два повезана ниска ТТЛ-а:
$ дрилл рав.гитхубусерцонтент.цом @4.2.2.2 рав.гитхубусерцонтент.цом. 1 У ЦНАМЕ гитхуб.мап.фастли.нет. гитхуб.мап.фастли.нет. 1 У 151.101.16.133
Ресолвер нивоа 3 вероватно ради на БИНД-у. Ако наставите да шаљете овај захтев, ТТЛ од 1 ће увек бити враћен. 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
Најмање три ЦНАМЕ записа. Аи. Један има пристојан ТТЛ, али је потпуно бескорисан. Други ЦНАМЕ имају почетни ТТЛ од 60 секунди, али за домене akamai.net максимални ТТЛ је 20 секунди и ниједна од њих није у фази.
Шта је са доменима који стално анкетирају Аппле уређаје?
$ 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
Исти проблем као Фирефок и ТТЛ ће бити заглављен на 1 секунду већину времена када се користи Левел3 резолвер.
Дропбок?
$ дрилл цлиент.дропбок.цом @8.8.8.8 цлиент.дропбок.цом. 7 У ЦНАМЕ цлиент.дропбок-днс.цом. цлиент.дропбок-днс.цом. 59 У 162.125.67.3 $ дрилл цлиент.дропбок.цом @4.2.2.2 цлиент.дропбок.цом. 1 У ЦНАМЕ цлиент.дропбок-днс.цом. цлиент.дропбок-днс.цом. 1 У 162.125.64.3
На снимању safebrowsing.googleapis.com ТТЛ вредност је 60 секунди, као Фацебоок домени. И опет, са становишта клијента, ове вредности су преполовљене.
Шта кажете на постављање минималног ТТЛ-а?
Користећи име, тип захтева, ТТЛ и првобитно сачувану временску ознаку, написао сам скрипту за симулацију 1,5 милиона захтева који пролазе кроз кеш резолвер да бих проценио обим непотребних захтева послатих због истекла уноса у кеш меморију.
47,4% захтева је поднето након истека постојеће евиденције. Ово је неоправдано високо.
Какав ће бити утицај на кеширање ако се постави минимални ТТЛ?
Кс оса је минималне ТТЛ вредности. То не утиче на записе са изворним ТТЛ-овима изнад ове вредности.
И оса је проценат захтева од клијента који већ има кеширани унос, али је истекао и поставља нови захтев.
Удео „додатних“ захтева је смањен са 47% на 36% једноставним подешавањем минималног ТТЛ-а на 5 минута. Постављањем минималног ТТЛ-а на 15 минута, број ових захтева пада на 29%. Минимални ТТЛ од 1 сата смањује их на 17%. Значајна разлика!
Шта кажете на то да ништа не мењате на страни сервера, већ да уместо тога поставите минимални ТТЛ у клијентским ДНС кешовима (рутери, локални разрешивачи)?
Број захтеваних захтева опада са 47% на 34% са минималним ТТЛ од 5 минута, на 25% са минимумом од 15 минута и на 13% са минималним 1 сат. Можда је 40 минута оптимално.
Утицај ове мале промене је огроман.
Које су последице?
Наравно, услуга се може преместити на новог провајдера облака, нови сервер, нову мрежу, захтевајући од клијената да користе најновије ДНС записе. А прилично мали ТТЛ помаже да се таква транзиција направи глатко и неприметно. Али са преласком на нову инфраструктуру, нико не очекује да ће клијенти прећи на нове ДНС записе у року од 1 минута, 5 минута или 15 минута. Постављање минималног ТТЛ-а на 40 минута уместо 5 минута неће спречити кориснике да приступе сервису.
Међутим, ово ће значајно смањити кашњење и побољшати приватност и поузданост избегавањем непотребних захтева.
Наравно, РФЦ-ови кажу да се ТТЛ мора стриктно поштовати. Али реалност је да је ДНС систем постао превише неефикасан.
Ако радите са ауторитативним ДНС серверима, проверите своје ТТЛ-ове. Да ли су вам заиста потребне тако смешно ниске вредности?
Наравно, постоје добри разлози за постављање малих ТТЛ-ова за ДНС записе. Али не и за 75% ДНС саобраћаја који остаје практично непромењен.
А ако из неког разлога заиста морате да користите ниске ТТЛ-ове за ДНС, у исто време уверите се да ваша веб локација нема омогућено кеширање. Из истих разлога.
Ако имате покренут локални ДНС кеш, као што је који вам омогућава да поставите минималне ТТЛ-ове, користите ову функцију. Ово је добро. Ништа лоше се неће десити. Поставите минимални ТТЛ на приближно 40 минута (2400 секунди) и 1 сат. Сасвим разуман распон.
Извор: ввв.хабр.цом
