Хабрахабр

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

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

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

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

Вот общее распределение TTL (ось X — это TTL в секундах): Результирующий набор данных состоит из 1 583 579 записей (name, qtype, TTL, timestamp).

Посмотрим ближе: Если не считать незначительного бугра на 86 400 (в основном, для записей SOA), довольно очевидно, что TTL находятся в низком диапазоне.

Тогда сосредоточимся на диапазоне 0−3600: Хорошо, TTL более 1 часа статистически не значимы.

Большинство 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 и изначально сохранённую временную метку, я написал скрипт для имитации 1,5 миллиона запросов, проходящих через кэширующий резолвер, чтобы оценить объём лишних запросов, отправленных из-за просроченной записи кэша.

Это неоправданно высоко. 47,4% запросов были сделаны после истечения срока действия существующей записи.

Каково будет влияние на кэширование, если установлен минимальный TTL?

Записи с исходными TTL выше этого значения не затронуты. Ось X — это минимальные значения TTL.

Ось Y — процент запросов от клиента, у которого уже есть кэшированная запись, но её срок действия истёк и он делает новый запрос.

При установке минимального TTL в 15 минут количество этих запросов снижается до 29%. Доля «лишних» запросов снижается с 47% до 36% простой установкой минимального TTL в 5 минут. Существенная разница! Минимальный TTL в 1 час снижает их до 17%.

Как насчёт того, чтобы ничего не менять на стороне сервера, а вместо этого установить минимальные TTL в клиентских DNS-кэшах (маршрутизаторы, локальные резолверы)?

Возможно, оптимальное значение 40 минут. Количество требуемых запросов снижается с 47% до 34% при установке минимального TTL в 5 минут, до 25% с минимумом в 15 минут и до 13% с минимумом в 1 час.

Влияние этого минимального изменения огромно.

Конечно, сервис можно перевести на нового облачного провайдера, новый сервер, новую сеть, требуя от клиентов использовать последние записи DNS. И достаточно малый TTL помогает плавно и незаметно осуществить такой переход. Но с переходом на новую инфраструктуру никто не ожидает, что клиенты перейдут на новые записи DNS в течение 1 минуты, 5 минут или 15 минут. Установка минимального срока жизни в 40 минут вместо 5 минут не помешает пользователям получить доступ к сервису.

Однако это позволит значительно сократить задержку и повысить конфиденциальность и надёжность, избегая ненужных запросов.

Но реальность такова, что система DNS стала слишком неэффективной. Конечно, RFC говорят, что нужно строго соблюдать TTL.

Вам действительно нужны такие смехотворно низкие значения? Если вы работаете с авторитативными DNS-серверами, пожалуйста, проверьте свои TTL.

Но не для 75% трафика DNS, который практически не меняется. Конечно, есть веские причины установки малых TTL для DNS-записей.

По тем же причинам. И если по каким-то причинам вам действительно нужно использовать низкие TTL для DNS, заодно убедитесь, что на вашем сайте не включено кэширование.

Это нормально. Если у вас работает локальный DNS-кэш, такой как dnscrypt-proxy, который позволяет устанавливать минимальные TTL, используйте эту функцию. Установите минимальный TTL примерно между 40 минутами (2400 секунд) и 1 часом. Ничего плохого не случится. Вполне разумный диапазон.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»