Ниска латентност на DNS е ключов фактор за бързата работа в интернет. За да я минимизирате, е важно внимателно да изберете DNS сървъри и . Но първо е необходимо да се отървем от ненужните запитвания.
Точно затова DNS първоначално беше създаден като силно кешируем протокол. Администраторите на зони задават времето за живот (TTL) на отделни записи, а резолверите използват тази информация при съхранение на записи в паметта, за да избегнат ненужния трафик.
Ефективно ли е кеширането? Преди няколко години моето малко проучване показа, че не е идеално. Нека да видим настоящата ситуация.
За събиране на информация поправих за запазване на стойността на 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 кеш, като , който позволява да задавате минимални TTL, използвайте тази функция. Това е нормално. Нищо лошо няма да се случи. Задайте минимален TTL между 40 минути (2400 секунди) и 1 час. Съвсем разумен диапазон.
Източник: habr.com
