Ниска латентност на DNS е ключов фактор за бърза работа в интернет. За да я минимизираме, е важно внимателно да изберем DNS сървъри и анонимни риле. Но първото нещо, което трябва да направим, е да се отървем от безполезните заявки.

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

Дали кеширането е ефективно? Преди няколко години моето малко проучване показа, че не е идеално. Нека да видим текущото положение.

За събиране на информация аз модифицирах Encrypted DNS Server за да запази стойността на TTL за отговора. Тя се определя като минималното TTL на неговите записи за всяка входяща заявка. Това дава добър преглед на разпределението на TTL за реалния трафик и също така отчита популярността на отделните заявки. Модифицираната версия на сървъра работи няколко часа.

Полученият набор от данни съдържа 1 583 579 записа (име, qtype, TTL, времеви печат). Ето общото разпределение на TTL (оста X е TTL в секунди):

Ако игнорираме незначителния връх на 86 400 (главно за записи SOA), е доста очевидно, че TTL са в ниския диапазон. Нека да погледнем по-близо:

Добре, TTL над 1 час статистически не са значими. Тогава да се съсредоточим в диапазона 0−3600:

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

Преобладаващото мнозинство е от 0 до 5 минути:

Това не е много добре.

Натрупаното разпределение прави проблема още по-очевиден:

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

Но изчакайте, всъщност всичко е още по-лошо. В крайна сметка това е TTL от авторитетни сървъри. Въпреки това клиентските резолвери (например, маршрутизатори, локални кешове) получават TTL от по-горе резолвери и той намалява всяка секунда.

Така че клиентът всъщност може да използва всяка запис, средно, за половината от първоначалното TTL, след което ще изпрати нова заявка.

Може би тези много ниски TTL се отнасят само за необичайни заявки, а не за популярни уебсайтове и API? Нека да разгледаме:

Оста X е TTL, оста Y е популярността на заявките.

За съжаление, най-популярните заявки също имат най-лошото кеширане.

Нека да приближим:

Вердикт: всичко наистина е лошо. Вече е било лошо, а сега е още по-лошо. Кеширането на DNS стана практически безполезно. Понеже все по-малко хора използват DNS резолвърите на своите доставчици (по уважителни причини), увеличението на времето за забавяне става все по-забележимо.

Кеширането на DNS стана полезно само за съдържание, което никой не посещава.

Също така е важно да се отбележи, че софтуерът може да интерпретира по различен начин ниските TTL.

Защо е така?

Защо за записите в DNS се задава толкова малък TTL?

• Устарелите натоварвани балансировачи са останали с настройки по подразбиране.
• Съществуват митове, че балансирането на натоварването по DNS зависи от TTL (всъщност не е така – от времето на Netscape Navigator клиентите избират произволен IP адрес от набора RR и прозрачно пробват друг, ако не могат да се свържат)
• Администраторите искат да приложат промените веднага, защото така е по-лесно да се планира.
• Администраторът на DNS сървъра или натоварвания балансировач вижда задачата си да разгръща ефективно конфигурацията, която потребителите искат, а не да ускорява работата на сайтовете и услугите.
• Ниските TTL дават душевен мир.
• Хората първоначално задават ниски TTL за тестове и след това забравят да ги променят.

Не включих в списъка „обработка на откази“, тъй като това става все по-малко актуално. Ако е необходимо да се пренасочат потребителите към друга мрежа само за да се покаже страница с грешка, когато абсолютно всичко останало е повредено, вероятно е допустимо забавяне от над 1 минута.

Освен това, миномен TTL означава, че ако авторитетните DNS сървъри бъдат блокирани повече от 1 минута, никой друг няма да може да получи достъп до зависимите услуги. И излишността няма да помогне, ако причината е конфигурационна грешка или хак. От друга страна, с разумни TTL много клиенти ще продължат да използват предишната конфигурация и никога няма да забележат.

При ниските TTL до известна степен виновни са услугите на CDN и натоварвания балансировачи, особено когато комбинират 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 записите, трябва да се изпрати нова заявка. И двата имат TTL от 30 секунди, но не съвпадат. Фактическият среден TTL ще бъде 15 секунди.

Но изчакайте! Все още е по-лошо. Някои резолвери реагират много лошо в такава ситуация с две свързани ниски TTL:

$ drill raw.githubusercontent.com @4.2.2.2
raw.githubusercontent.com.	1	IN	CNAME	github.map.fastly.net.
github.map.fastly.net.	1	IN	A	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

$ drill client.dropbox.com @4.2.2.2
client.dropbox.com.	1	IN	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 минути. Задаването на минимален срок на живот от 40 минути вместо 5 минути не пречи на потребителите да имат достъп до услугата.

Въпреки това, това значително ще намали закъснението и ще повиши конфиденциалността и надеждността, избягвайки ненужни заявки.

Разбира се, RFC споменават, че трябва строго да се спазва TTL. Но реалността е, че системата DNS стана прекалено неефективна.

Ако работите с авторитативни DNS сървъри, моля, проверете вашите TTL. Имате ли наистина нужда от толкова смехотворно ниски стойности?

Разбира се, има основателни причини за задаване на малки TTL за DNS записи. Но не за 75% от DNS трафика, който почти не се променя.

И ако по някакви причини наистина трябва да използвате ниски TTL за DNS, също така се уверете, че кеширането на вашия сайт не е включено. Поради същите причини.

Ако имате локален DNS кеш, като dnscrypt-proxy, който позволява да се зададат минимални TTL, използвайте тази функция. Това е нормално. Нищо лошо няма да се случи. Задайте минимален TTL между 40 минути (2400 секунди) и 1 час. Напълно разумен обхват.

Източник: habr.com