Ниската латентност на DNS е клучна за брзо прелистување на интернет. За да го минимизирате, важно е внимателно да изберете DNS сервери и анонимни релеи. Но, првиот чекор е да се ослободите од бескорисните прашања.

Ова е причината зошто DNS првично беше дизајниран како протокол со високо кеширање. Администраторите на зона поставуваат време на живеење (TTL) за поединечни записи, а решавачите ги користат овие информации кога ги складираат записите во меморијата за да избегнат непотребен сообраќај.

Дали кеширањето е ефикасно? Пред неколку години, моето мало истражување покажа дека не е совршено. Ајде да ја погледнеме моменталната состојба на работите.

За да соберам информации што ги закрпив Шифриран DNS сервер за да ја зачувате вредноста на TTL за одговорот. Тој е дефиниран како минимален TTL на неговите записи за секое дојдовно барање. Ова дава добар преглед на TTL дистрибуцијата на реалниот сообраќај, а исто така ја зема предвид популарноста на индивидуалните барања. Закрпената верзија на серверот работеше неколку часа.

Добиениот сет на податоци се состои од 1 записи (име, тип, TTL, временски печат). Еве ја целокупната дистрибуција на TTL (оската X е TTL во секунди):

Настрана од малиот удар на 86 (најчесто за SOA записи), прилично е јасно дека TTL се во низок опсег. Ајде да погледнеме подетално:

Во ред, TTL поголеми од 1 час не се статистички значајни. Потоа да се фокусираме на опсегот 0−3600:

Повеќето TTL се од 0 до 15 минути:

Огромното мнозинство се од 0 до 5 минути:

Не е многу добро.

Кумулативната дистрибуција го прави проблемот уште поочигледен:

Половина од DNS одговорите имаат TTL од 1 минута или помалку, а три четвртини имаат TTL од 5 минути или помалку.

Но чекај, всушност е полошо. На крајот на краиштата, ова е TTL од авторитетни сервери. Како и да е, клиентските резолутори (на пр. рутери, локални кешови) добиваат TTL од upstream решавачи и се намалува секоја секунда.

Така, клиентот всушност може да го користи секој запис за, во просек, половина од оригиналниот TTL пред да испрати ново барање.

Можеби овие многу ниски TTL се однесуваат само на невообичаени барања, а не на популарни веб-локации и API? Ајде да погледнеме:

Оската X е TTL, а оската Y е популарност на барањето.

За жал, најпопуларните прашања се исто така најлоши за кеширање.

Ајде да зумираме:

Пресуда: навистина е лошо. Порано веќе беше лошо, но стана уште полошо. DNS кеширањето стана практично бескорисно. Како што помалку луѓе го користат разрешувачот на 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 или која било од записите А, мора да се испрати ново барање. И двајцата имаат TTL од 30 секунди, но не е исто. Вистинскиот просечен TTL ќе биде 15 секунди.

Но, чекај! Уште полошо е. Некои решавачи се однесуваат многу лошо во оваа ситуација со два поврзани ниски TTL:

$ вежба raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 ВО CNAME github.map.fastly.net. github.map.fastly.net. 1 ВО А 151.101.16.133

Резолуторот Level3 веројатно работи на BIND. Ако продолжите да го испраќате ова барање, секогаш ќе се враќа TTL од 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

Најмалку три записи 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?

$ вежба клиент.dropbox.com @8.8.8.8 client.dropbox.com. 7 ВО CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 ВО 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 ВО А 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. Дали навистина ви требаат толку смешно ниски вредности?

Се разбира, постојат добри причини да се постават мали TTL за записи DNS. Но, не и за 75% од сообраќајот DNS кој останува практично непроменет.

И ако поради некоја причина навистина треба да користите ниски TTL за DNS, во исто време проверете дали вашата страница нема овозможено кеширање. Од истите причини.

Ако имате локален DNS кеш што работи, како на пр dnscrypt-проксишто ви овозможува да поставите минимум TTL, користете ја оваа функција. Ова е во ред. Ништо лошо нема да се случи. Поставете го минималниот TTL на приближно 40 минути (2400 секунди) и 1 час. Сосема разумен опсег.

Извор: www.habr.com