Ниската DNS латентност е ключова за бързото сърфиране в интернет. За да го сведете до минимум, е важно внимателно да изберете DNS сървъри и . Но първата стъпка е да се отървете от безполезните заявки.
Ето защо DNS първоначално е проектиран като протокол с висока степен на кеширане. Администраторите на зоните задават време на живот (TTL) за отделни записи, а преобразувателите използват тази информация, когато съхраняват записи в паметта, за да избегнат ненужен трафик.
Кеширането ефективно ли е? Преди няколко години малкото ми проучване показа, че не е перфектно. Нека да разгледаме текущото състояние на нещата.
За събиране на информация, която закърпих за да запазите TTL стойността за отговора. Дефинира се като минималното TTL на неговите записи за всяка входяща заявка. Това дава добър преглед на TTL разпределението на реалния трафик и също така взема предвид популярността на отделните заявки. Пачираната версия на сървъра работи няколко часа.
Полученият набор от данни се състои от 1 583 579 записа (име, qtype, TTL, времево клеймо). Ето общото разпределение на TTL (оста X е TTL в секунди):
Освен незначителния удар при 86 (най-вече за SOA записи), доста ясно е, че TTL са в ниския диапазон. Нека да разгледаме по-отблизо:
Добре, TTL над 1 час не са статистически значими. Тогава нека се фокусираме върху диапазона 0-3600:
Повечето TTL са от 0 до 15 минути:
По-голямата част са от 0 до 5 минути:
Не е много добре.
Кумулативното разпределение прави проблема още по-очевиден:
Половината от DNS отговорите имат TTL от 1 минута или по-малко, а три четвърти имат TTL от 5 минути или по-малко.
Но чакайте, всъщност е по-лошо. В крайна сметка това е TTL от авторитетни сървъри. Обаче клиентските резолвери (напр. рутери, локални кешове) получават TTL от резолверите нагоре и той намалява всяка секунда.
Така че клиентът всъщност може да използва всеки запис средно за половината от първоначалния 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 или някой от записите A изтече, трябва да се изпрати нова заявка. И двата имат 30 секунден TTL, но не е същото. Действителният среден TTL ще бъде 15 секунди.
Но почакай! Още по-лошо е. Някои резолвери се държат много зле в тази ситуация с два свързани ниски TTL:
$ drill 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?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN 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 В А 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 кеш, като напр която ви позволява да зададете минимални TTL, използвайте тази функция. Това е добре. Нищо лошо няма да се случи. Задайте минималния TTL на приблизително 40 минути (2400 секунди) и 1 час. Доста разумен диапазон.
Източник: www.habr.com