Хватит использовать смехотворно малый TTL для DNS

Автор оригинала: Frank Denis
  • Перевод
Низкая задержка DNS — ключевой фактор для быстрой работы в интернете. Чтобы её минимизировать, важно тщательно подобрать DNS-серверы и анонимные рилеи. Но первым делом следует избавиться от бесполезных запросов.

Именно поэтому DNS изначально создавался как сильно кэшируемый протокол. Администраторы зон устанавливают время жизни (TTL) для отдельных записей, а резолверы используют эту информацию при хранении записей в памяти, чтобы избежать ненужного трафика.

Эффективно ли кэширование? Пару лет назад моё небольшое исследование показало, что оно не идеально. Взглянем на нынешнее положение дел.

Для сбора информации я пропатчил Encrypted DNS Server для сохранения значения TTL для ответа. Оно определяется как минимальное TTL его записей, для каждого входящего запроса. Это даёт хороший обзор распределения TTL реального трафика, а также учитывает популярность отдельных запросов. Пропатченная версия сервера работала несколько часов.

Результирующий набор данных состоит из 1 583 579 записей (name, qtype, TTL, timestamp). Вот общее распределение 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 в значительной степени виноваты cервисы 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, приходится отправлять новый запрос. У обоих 30-секундный TTL, но он не совпадает. Фактический средний 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 часом. Вполне разумный диапазон.
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 42

    +18

    Если с последней точкой или бедным сервером происходит кака-то жопа, то у 80% клиентов проблемы исчезнут через 15 минут при низком ttl. Если же там вдруг будет час, день — то это будет катастрофа.


    Если бы владелец домена мог посылать какой-то сигнал "всем сбросить кеши" — все бы ставили кеш максимальным.

      0

      Если с вашим сервером может произойти жопа, то почему бы его не зарезервировать и поставить перед ним балансировщик нагрузки? Если с вашим балансировщиком может произойти жопа, то почему бы не зарезервировать балансировщики, каждый со своей DNS-записью?


      Потому что денег на это нет, а на белкового админа, которые будет перетыкивать руками в три часа ночи — есть :(

        +5

        Или потому, что денег вообще нет, а это мой хобби-проект.

          +3

          А от того что хобби проект полежит час, что произойдёт?

            +3
            wild cert от letsencrypt не выдадут
              0
              а можно по подробней, что вы имеете ввиду
                0
                wildcard сертификат от letsencrypt можно получить только используя авторизацию через DNS. Высокий TTL — проверка будет провалена.
                  +1
                  Let’s Encrypt при авторизации через DNS всегда проверяет запись непосредственно через непосредственное обращение к авторитативным DNS серверам домена. Запись должна быть опубликована к тому моменту, когда Let’s Encrypt придет ее проверять. TTL тут никакой роли не играет.
                    0
                    ок, убедили
              +3
              Если проект прямо сейчас нужен на учебном занятии или выступлении — то оно сорвётся.
                –2

                На выступлении не должно быть внешних зависимостей. Все толькотлокаотно. Это пастулат.

                  +3
                  Какой раз я говорю себе, что не нужно писать комменты с телефона. Следует читать: «Всё только локально. Это постулат.»
                +2

                Зависит от отношения. Раньше я заморачивался на тему доступности, популяризации и этакого имиджа, и это немножко съедало нервные клетки. Вплоть до «вот сейчас я напишу анонс на opennet, а у меня сайт приляжет».


                Притом, что не съедать нервные клетки очень просто: можно просто выставить TTL пониже.

          +3

          Если вам по какой-то причине надо срочно обновить А запись то ждать вам придется как раз весь TTL. И хорошо если у вас есть полный контроль над роутингом у себя и "плавающие" IP-адреса, а если это vps?

            +1
            Кстати, при переключении ip-адреса заметил, что многие мобильные клиенты, особенно iOS, еще долго долбились на старый ip-адрес — около двух дней были редкие запросы (TTL было 5 минут). Может, конечно, какой-то провайдер закешировал или они таким способом экономят энергию.
            0
            Да, проблема есть, и она серьёзна. Я ещё в 2013 году это заметил при просмотре трафика.
            Чаще всего, почему-то, проблема была заметна на доменах каких-то российских рекламных сетей (сейчас уже не вспомню кто это был). Я посчитал, что они собирают статистику на своих DNS-серверах.
              +19

              Автор статьи упорно не хочет замечать проблему, которую он обозначил вскользь и не хочет предложить какой-то способ для её решения.
              Современный бизнес не готов терпеть сутки убытка, пока сайт переключится если он неожиданно упадёт и его придётся подымать на другом месте. Поэтому сейчас все такие умные и стали ставить значения как можно меньше — вот и все дела. И это самый дешёвый способ способ снизить время переключения, поэтому неважно, что у вас в ближайших планах на полгода нет повода для смены хостинга: просто тупо держите TTL поменьше на всякий пожарный случай.


              Все другие способы сделать более качественно страдают одним мааааленьким недостатком: они намного более дороги. Все ли готовы вкладываться в это? Не все. А требовать хотят все.
              Вот отсюда и описанная ситуация.


              В айти всего две действительно сложные проблемы: нейминг и инвалидация кеша. В протоколе DNS инвалидация кеша есть? Ну вот потому ситуация и не меняется.

                +2
                Хочу заметить, что перечисляя две действительно сложные проблемы, вы забыли «ошибки на единицу»
              • НЛО прилетело и опубликовало эту надпись здесь
                  +2
                  > Сейчас с хостингом в облаках конечно попроще, но эту инерцию трудно сломить.
                  С хостингом в облаках как раз всё намного хуже.
                  Я до сих пор помню чудесное от digitalocean — «ну у нас кнопки reinstall пока нет, вы дроплет удалите, создайте заново с теми же параметрами, может быть повезет и он будет с тем же адресом» (кнопки reinstall на тот момент действительно не было).
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      У них до сих пор «ну у нас выбор ОС в reinstall есть, но на самом деле нормально реинсталлить можно только ту же ОС/версию, что была при создании, потому что cloud-init не меняется».
                    +2
                    Многие пользуются cloudflare, там по умолчанию auto ttl, а это вроде бы 5 минут. Видимо в cf считают, что это нормально, нагрузка приемлема.
                      0
                      Раньше была 1 минута, если память не изменяет.
                      А сейчас минималка в 2 минуты на непроксируемых, и 5 минут — на proxied ресурсах
                        0

                        Я недавно менял ip сайта в CF, так после смены он мгновенно стал доступен. Подозреваю, что там TTL для недоступных сайтов снижается, чтобы при возобновлении работы сразу отдать его клиентам.

                        +4

                        Загрузка одной страницы типичного сайта генерирует более 1 Мб трафика. Если ради нее приходится делать DNS-запрос, то это + 300 байт трафика — менее 0,1%.


                        Статья предлагает вам тратить время ради оптимизации менее 0,1% трафика. И получить проблемы при падениях, ДДОС-атаках, проблемах с хостером.


                        Не уж, пусть будет 5-15 минут, и вам не придется объяснять владельцу бизнеса, что поднять сайт нельзя, так как какой-то гений, начитавшись советов в Интернете, поставил TTL в 12 часов.

                          +12
                          Только в современном мире пропускная способность часто высока (даже по сотовой связи), а вот RTT до сих пор часто бывает очень высоким (даже на проводе).
                          И генерируя 5 днс запросов (cname, cdn, ресурсы партнеров, счетчики) с задержкой в 200мс вы легко получаете более 1 секунды до загрузки страницы каждые { ваше/cdn/партнеров значение ttl }.
                            +8

                            DNS-ресолвинг — для клиента это в первую задержка перед отображением страницы, а не объём трафика

                              +1
                              поднять сайт нельзя, так как какой-то гений, начитавшись советов в Интернете, поставил TTL в 12 часов.

                              Я вполне себе застал времена в начале 2000-х, когда TTL обычно стоял 86400. И были постоянные факапы, когда люди пуляли ошибочное обновление в зону, которое роняло корпоративную почту или сайт на сутки.
                              Работал в то время в телекоме и сполна насмотрелся на эти ужасы.
                              Пусть уж лучше TTL в 60-120 секунд.
                              +4
                              Первая, и самая важная ваша ошибка в рассуждениях: балансировка по DNS зависит от TTL, и это ключевой момент, довольно подробно про это было в блоге Dropbox: blogs.dropbox.com/tech/2018/10/dropbox-traffic-infrastructure-edge-network.
                              Вторая: в общем случае, у вас нету надёжного способа управления трафиком, кроме GeoDNS. Предупреждая вопросы, anycast — это не управление, т.к. решение в итоге принимает провайдер на основе ваших предложений, но далеко не всегда в соответствии с вашими желаниями.
                              Из этих двух вводных и возникает низкий TTL в большинстве CDN (включая AWS, Google Cloud и т.д.).

                              Про проблемы быстрого переключения на другой пул адресов/балансеров/etc уже писали выше, это уже касается не-CDN доменов.
                                +8
                                Один, два или десяток лишних DNS запросов вносят задержки, да. Но эти задержки — капля в море по сравнению с теми секундами, пока грузится перегруженный скриптами и рекламой современный веб.
                                И уж тем более это добро несопоставимо с часами простоя, в случае протухшей DNS записи.
                                Петь песни про резервирование, кэширование и управление траффиком все горазды, а вот когда припрет — каждому клиенту на дом «сделайте, пожалуйста ipconfig /flushdns» носить не будешь.
                                Кэширование DNS штука, конечно, клевая, но фарш обратно не провернешь: если закэшировало — то все, жди пока протухнет.

                                Сейчас кэш DNS просто ушел в прошлое имхо. Для ускорения загрузки нынче куда более эффективнее кэширование на уровне CDN с проверками по 304 коду или чем-нибудь подобным.
                                В конце концов пропускная способность сети и скорости загрузки контента для конечного пользователя постоянно растут и влияние задержек от DNS запросов будет становится все менее и менее заметным.
                                  +3

                                  а еще бывает, не оплатит бухгалтерия вовремя домен, и один крупный провайдер с названием в названии быстренько подставляет ip адреса со своей рекламой, которые кэшируются у клиентов и некоторые потом сутками жалуются на недоступность сервиса.

                                    +4

                                    Когда мои коллеги-программисты где-то вкорячивают кеширование но забывают приделать к нему инвалидацию — я отрываю им руки.
                                    Создателям DNS руки вовремя никто не оторвал, а про инвалидацию кеша они вообще были не в курсе.

                                      +10
                                      Как вы это представляете? Допустим, есть популярный глобальный сервис, у его DNS запросили инфу порядка тысячи разных кэширующих резолверов — как ему надежно сбросить кэш у каждого из них?

                                      Запонимать всех кто (и когда) спрашивал и слать «сбросить кэш»? При этом, без криптографии тут не обойдётся — все запросы на сброс кэша должны быть подписаны, а резолверы должны их валидировать, и это не считая того что эту «память» нужно хранить где-то постоянно — иначе холодный рестарт сервера (или переход на другой сервер в пуле) не сбросит кэш.

                                      Технически это конечно реализуемо, но усложняет систему неимоверно, а если учесть что клиенты иногда запрашивают кэширующие резолверы совсем не первого уровня, да и самих резолверов могут быть не тысячи а десятки тысяч, то всё становится очень мрачно.
                                        0
                                        Нет, просто конечный резолвер должен регулярно опрашивать авторитативный сервер (каждые X запросов, но не чаще раза в N<TTL секунд) и сравнивать с данным в кеше. Для популярных записей нагрузка увеличится незначительно, а для редких почти каждый запрос будет уходить наверх, но это не проблема. Реализуемо уже сейчас, но даже если и принять стандарт, только лет через 30 оно разойдётся по сети окончательно. Но вот бьющиеся в истерике администраторы могут уже сейчас начать патчить свои резолверы, добавляя игнорирование оригинального TTL и регулярный опрос.
                                          +1
                                          Современный кеширующий резолвер при обработке запроса от Клиента смотрит сколько от оригинального TTL осталось. И если осталось меньше чем время N, то асинхронно запрашивает авторитативные сервера, обновляя запись в фоне. Таким образом популярные запросы всегда находятся в Кеше. Стандартов на сколько я знаю на это не существует в природе и каждый разработчик кэширующих DNS серверов делает это по собственным алгоритмам.
                                      +1
                                      По проблематике коротких TTL — текущая температура по больнице:
                                      1) Маленькие TTL на популярных доменах не вредят телеком-провайдерам с большим количеством Абонентов. При условии того, что эти телеком-провайдеры агрегируют трафик 400+ тысяч Абонентов на сервер. Давление на кеш на таком сервере позволяет держать все популярные домены в кеше. Сервер может отвечать на запросы к популярным доменам 100% из кеша, если используются проактивное кеширование.
                                      У телеком-провайдеров с небольшой нагрузкой на кешируюшие DNS сервера популярные домены часто вымываются из кеша, вследствии небольшого на него давления от клиентов. И проактивное кеширование при небольшом давлении на кеш уже не помогает.
                                      2) В среднем TTL все время снижается, так как все больше ресурсов переезжает в «облака», в которых короткие TTL используются по умолчанию.

                                      В среднем никогда не стоит делать TTL меньше 15 секунд, иначе и проактивное кеширование на стороне резолвера ISP может не успевать обновлять кеш, до того как запись умрет по TTL.
                                        +1

                                        Хм, а причем здесь серверы? Нельзя ли сделать просто долгосрочный кеш на стороне клиента? И сбрасывать его если произошла ошибка соединения.


                                        Или я фундаментально не понимаю что нибудь?

                                          +4
                                          Тогда такие клиенты будут долго не видеть изменений в DNS при, к примеру, переезде веб-сервера на новый адрес. Что для клиентов будет равнозначно ситуации «сайт лежит». Если вы будете обновлять кеш при ошибке соединения с каким-либо сервисом на целевом хосте (да, про UDP и прочие подобные stateless протоколы придётся забыть), то клиент опять же получит ситуацию «сайт лежит», если веб-сервер не знает про такой Host/SNI в HTTP(S)-запросе вследствие переезда сайта на другой адрес.
                                          +1
                                          Не убедили. Плавающие ip стоят денег, и требуют обслуживания, особенно в bare-metal инфраструктуре. Да даже с ними я ставлю ttl пять минут, на всякий случай, чтобы быть точно уверенным что я смогу перенести основную часть трафика на резерв, в разумное для бизнеса время.
                                            +1
                                            Bare-metal инфраструктура Packet: цена плавающего IP: $0.005/час ($3,6 в месяц) в пределах одного ДЦ, $0,15/час ($108 в месяц) между ДЦ. По мне, если это дорого для Бизнеса, но это наверное не Бизнес на котором зарабатывают деньги, а попытки экономить на спичках и на End User Experience.
                                            +1
                                            Кстати, такие маленькие TTL у «конечных» записей, а у NSов экстремально низкие TTL это редкость, и кеширование всего кроме последней записи про целевой хост работает.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое