Ttl dns что это
Низкая задержка 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 минут:
Это не очень хорошо.
Накопительное распределение делает проблему ещё более очевидной:
Но подождите, на самом деле всё ещё хуже. Ведь это TTL от авторитативных серверов. Однако клиентские резолверы (например, маршрутизаторы, локальные кэши) получают TTL от вышестоящих резолверов, и он уменьшается каждую секунду.
Таким образом, клиент фактически может использовать каждую запись, в среднем, в течение половины исходного TTL, после чего отправит новый запрос.
Может, эти очень низкие TTL касаются только необычных запросов, а не популярных веб-сайтов и API? Давайте посмотрим:
Ось X — это TTL, ось Y — популярность запросов.
К сожалению, самые популярные запросы также и хуже всего кэшируются.
Вердикт: всё действительно плохо. Уже и раньше было плохо, а стало ещё хуже. Кэширование DNS стало практически бесполезным. Поскольку всё меньше людей используют DNS-резолвер своего провайдера (по уважительным причинам), увеличение задержки становится более заметной.
Кэширование DNS стало полезным только для контента, который никто не посещает.
Также обратите внимание, что программное обеспечение может по-разному интерпретировать низкие TTL.
Почему для записей DNS устанавливается такой малый TTL?
- Устаревшие балансировщики нагрузки остались с настройками по умолчанию.
- Ходят мифы, что балансировка нагрузки по DNS зависит от TTL (это не так — со времён Netscape Navigator клиенты выбирают случайный IP-адрес из набора RR и прозрачно пробуют другой, если не могут подключиться)
- Администраторы хотят применить изменения немедленно, потому так проще планировать.
- Администратор DNS-сервера или балансировщика нагрузки видит своей задачей эффективно развёртывать конфигурацию, которую запрашивают пользователи, а не ускорять работу сайтов и сервисов.
- Низкие TTL дают душевное спокойствие.
- Люди первоначально ставят низкие TTL для тестирования и забывают потом их изменить.
Кроме того, минутный TTL означает, что если авторитетные DNS-серверы будут заблокированы более чем на 1 минуту, никто больше не сможет получить доступ к зависимым службам. И избыточность не поможет, если причиной является ошибка конфигурации или взлом. С другой стороны, с разумными TTL много клиентов продолжат использовать предыдущую конфигурацию и никогда ничего не заметят.
В низких TTL в значительной степени виноваты cервисы CDN и балансировщики нагрузки, особенно когда они объединяют CNAME с малыми TTL и записи с такими же малыми (но независимыми) TTL:
Всякий раз, когда истекает CNAME или любая из записей A, приходится отправлять новый запрос. У обоих 30-секундный TTL, но он не совпадает. Фактический средний TTL будет 15 секунд.
Но подождите! Всё еще хуже. Некоторые резолверы очень плохо себя ведут в такой ситуации с двумя связанными низкими TTL:
Вот ещё один пример такой ситуации с очень популярным доменом:
Как насчёт доменов, которые постоянно опрашивают устройства Apple?
Та же проблема, что у Firefox, и TTL большую часть времени застрянет на 1 секунде при использовании резолвера Level3.
Используя имя, тип запроса, 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 часом. Вполне разумный диапазон.
Fenix by Takeda11
Многие путаются в обновлении записей DNS, когда изменяют IP-адрес своего сайта. Почему эти записи медленно обновляются? Неужели действительно нужно ждать два дня, чтобы всё обновилось? Почему одни посетители видят новый IP, а другие — старый?
Обновим записи DNS
Теперь, когда мы знаем основы работы DNS, давайте обновим некоторые записи DNS и посмотрим, что произойдет.
При обновлении записей DNS существует два основных варианта:
- сохранить те же серверы имен;
- изменить серверы имен.
Минимальное значение TTL DNS
Если вы планируете в ближайшее время внести изменения в DNS, вам следует начать с установки низкого значения TTL. Это помогает обеспечить более быстрое распространение ваших изменений и их распознавание в Интернете.
Установите для минимального значения TTL DNS значение больше 0. Никогда не устанавливайте для TTL DNS значение 0. Число 0 не определено в стандарте, и это может привести к игнорированию или отклонению вашей информации DNS.
Рекомендация : 3600 (1 час) — хорошее минимальное значение. Он достаточно низкий, чтобы изменения вступили в силу быстро, но не настолько низкий, чтобы DNS-серверы были перегружены.
У серверов имен TTL намного больше
Причина, по которой мой регистратор говорил: «Это займёт 48 часов» в том, что TTL на NS-записях (сведения о том, к какому серверу имен должен обратиться рекурсивный сервер) намного больше.
172 800 секунд — это 48 часов! Таким образом, обновление сервера имен, как правило, занимает гораздо больше времени. Время нужно, чтобы закончился срок действия кэшей и распространился новый адрес. Это гораздо дольше, чем просто обновление IP-адреса без изменения вашего сервера имен.
Общие вопросы и ответы
В. Могу ли я по-прежнему использовать локальный сервер доменных имен, такой как DNSMasq, если мои клиенты используют mDNS.
О. Да, они сосуществуют в одной сети.
В. Можно ли использовать mDNS в сетях VLAN?
О. Не без дополнительной настройки.
В. Могу ли я использовать службы оповещения хоста, которые доступны на других машинах в сети?
О. Да, в Linux вам нужно будет создать и добавить файл сервисов avahi.
Вариант 2: обновление ваших серверов имен
Итак, мы видели, что когда вы обновляете IP-адрес, не меняя свои серверы имен, многие DNS-серверы довольно быстро получают новый IP-адрес. Отлично. Но что произойдет, если вы измените свои серверы имен? Давайте попробуем!
Ладно, давайте посмотрим, изменилось ли что-нибудь:
Никаких изменений. Если я спрошу другой DNS-сервер, то он знает новый IP:
Как долго длится TTL?
TTL указывается в секундах. Типичное значение по умолчанию обычно составляет 12 часов (43200 секунд) или 24 часа (86400 секунд). Например — сайт переезжает на новый сервер; или вы добавляете новый URL на свой сервер. Новые изменения DNS вступят в силу через 12–24 часа.
Обратите внимание, что даже если вы измените TTL для своего доменного имени, это не означает, что автоматически каждая сеть в Интернете будет соблюдать это значение. Многие поставщики интернет-услуг (ISP) игнорируют настройки TTL и проверяют внешние записи DNS по своему собственному расписанию.
Поговорим о TTL
Но мы забыли кое-что важное. Это TTL. Как мы сказали ранее, рекурсивный DNS-сервер будет кэшировать записи до истечения срока их действия. Он принимает решение об истечении срока действия записи в зависимости от ее TTL (time to live, времени жизни).
В этом примере сервер имен GitHub для его DNS-записи возвращает TTL 60, что означает 60 секунд:
mDNs в Linux и Windows
В Linux, включая Raspberry Pi, он обычно устанавливается автоматически и использует пакеты Avahi.
Вы также можете скачать утилиты, которые могут быть полезны для устранения неполадок, используя:
В Windows и Apple службы mDNS предоставляются пакетами Bonjour.
Вы можете скачать Bonjour SDK здесь, который позволит вам использовать инструмент командной строки dns-sd.
Вам нужно будет создать учетную запись разработчика, чтобы загрузить SDK.
Не всегда можно полагаться на TTL
Как и в большинстве интернет-протоколов, не всё подчиняется спецификации DNS. Некоторые DNS-серверы интернет-провайдеров будут кэшировать записи дольше, чем указано в TTL. Например, в течение двух дней вместо пяти минут. И люди всегда могут жестко закодировать старый IP-адрес в своем файле /etc/hosts .
На практике при обновлении записи DNS с пятиминутным TTL можно ожидать, что большой процент клиентов быстро перейдет на новые IP-адреса (например в течение 15 минут), а затем появится куча отставших, которые будут медленно обновляться в течение следующих нескольких дней.
Поиск хостов с помощью mDNS
Это можно продемонстрировать с помощью утилиты avahi-resolve, как показано ниже.
В Windows используйте команду dns -sd -Q hostname
Объявления
В рамках протокола mDNS устройства mDNS будут делать объявления, содержащие их записи mDNS, при запуске и в ответ на изменения сети на хост-компьютере.
Эти объявления будут получены всеми клиентами mDNS в локальной сети и использоваться для обновления их собственных записей.
Вариант 1: обновление записи DNS на тех же серверах имен
Во-первых, я обновила свои серверы имен (Cloudflare), чтобы получить новую запись DNS — запись A, которая сопоставляет test.jvns.ca на 1.2.3.4:
Это сработало немедленно! Не было никакой необходимости ждать вообще, потому что перед этим не было никакой DNS-записи test.jvns.ca , которая могла быть кэширована. Отлично. Но похоже, что новая запись кэшируется в течение примерно пяти минут (299 секунд).
Итак, а если мы попытаемся изменить этот IP-адрес? Я изменила его на 5.6.7.8, а затем запустила тот же DNS-запрос:
Похоже, что на этом DNS-сервере запись 1.2.3.4 всё еще кэшируется в течение 144 секунд. Интересно, что если запросить 8.8.8.8 несколько раз, вы получите противоречивые результаты — иногда он выдает новый IP, а иногда старый. Вероятно, 8.8.8.8 на самом деле распределяет нагрузку на кучу разных бэкендов, у каждого из которых собственный кэш.
После пяти минут ожидания все кэши 8.8.8.8 обновились и всегда возвращали новую запись 5.6.7.8. Потрясающе. Это довольно быстро!
Динамический DNS TTL
Динамический DNS (DDNS) — отличный способ указать доменные имена на нестатический IP-адрес.
Если вы настроили динамический DNS для доменного имени, вас могут попросить указать TTL для записей. Однозначного ответа на вопрос о значении TTL, которое следует использовать для динамической записи DNS, не существует. Частично это будет зависеть от того, как долго находится аренда IP-адреса. Чем чаще меняется IP-адрес, тем ниже TTL, который вам следует использовать.
Рекомендация. Хорошее практическое правило — сделать TTL DDNS вдвое меньше, чем аренда DHCP. Если аренда IP-адреса установлена на 60 (1 минута), установите TTL на 30 (30 секунд). Если IP-адрес 3600 (1 час), установите TTL на 1800 (30 минут).
Как выполнить поиск в DNS TTL
Узнайте, как проверить настройки TTL для вашего веб-сайта.
Linux, Unix или Mac OS X
Самый простой способ узнать настройки TTL — использовать digутилиту, доступную в Linux, Unix и Mac OS X.
В оболочке (командной строке) введите:
Это вернет информацию DNS (включая значения TTL) для имени домена:
Значение «7728» — это TTL для записи в секундах (7 728 секунд = 2 часа 8 минут).
Windows
В Windows вы можете использовать эту nslookupутилиту для проверки значений TTL DNS для веб-сайта.
Сначала откройте окно командной строки.
• Windows 7: Пуск -> Все программы -> Стандартные -> Командная строка • Windows 10: щелкните правой кнопкой мыши кнопку «Пуск» -> Выполнить -> введите «cmd» в поле и нажмите «ОК».
Чтобы запустить nslookup и получить значения TTL, введите:
Это вернет информацию авторитетного сервера имен для этого домена, включая TTL по умолчанию в секундах и часах.
В этом случае TTL веб-сайта установлен на 3600 секунд (1 час).
В сети
Есть несколько веб-сайтов, которые позволяют использовать утилиту dig для бесплатного поиска DNS TTL.
Как видите, значение TTL DNS для записей этого домена установлено на 21599 секунд (6 часов).
Вот и всё!
Надеюсь, что это поможет вам понять, что происходит при обновлении вашего DNS.
Оговорюсь, что всю историю распространения DNS определяют не только TTL. Некоторые рекурсивные DNS-серверы наверняка не уважают TTL, даже такие основные серверы как 8.8.8.8. Так что даже если вы просто обновляете запись A, указав маленький TTL, возможно, что на практике всё равно будут приходить запросы на старый IP в течение дня или двух.
Задав соответствующий вопрос в Twitter, мы выяснили, что некоторые системные администраторы даже не могут расшифровать аббревиатуру TTL (хотя такие, к счастью, в меньшинстве).
Отгадайте загадку! Что означает аббревиатура TTL, когда речь идет о системе DNS?
18:43 26 окт. 2016 г.
4 % Граница терминальной передачи
85 % Время жизни
8 % Телеметрическая транспортная линия
3 % Список доверенных технологий
26 голосов • Окончательный результат
Ретвит 1 Отметка «Нравится» 1
Чтобы внести ясность, мы рассмотрим следующие темы.
1. Общие сведения о системе DNS и параметре TTL
2. Устранение проблем с TTL в записях DNS
3. Рекомендации по управлению изменениями в записях DNS
4. Инструменты DNS
5. Дальнейшие действия
1. ОБЩИЕ СВЕДЕНИЯ О СИСТЕМЕ DNS
Что такое запись DNS?
Запись сервера доменных имен (Domain Name Server, DNS) содержит два важных параметра:
адресацию (установку соответствия) запросов для той или иной записи;
время актуальности записи при кэшировании — именно это значение получило зловещее название «время жизни» (TTL).
Зачем кэшируются записи DNS?
Многие организации настраивают записи DNS один раз и после этого годами не изменяют их. Поскольку записи DNS часто запрашиваются, но редко обновляются, их кэширование помогает значительно повысить производительность сети, увеличивая при этом сложность оценки и устранения проблем с DNS.
Что такое TTL?
Время жизни (TTL) представляет собой продолжительность кэширования записи *каждым звеном* цепочки установки соответствий DNS. Это значение измеряется в секундах (важность этого будет объяснена ниже).
К сожалению, общепринятый термин «время жизни» нельзя назвать исчерпывающим. Возможно, более логичным было бы название «время на поиск» или «продолжительность хранения записи DNS в кэше».
Каково стандартное значение TTL для записей DNS?
Значение TTL всегда выражается в секундах. Большинство служб настройки конфигурации DNS содержат готовый список значений для записей.
300 секунд = 5 минут = «Очень короткое»
3600 секунд = 1 час = «Короткое»
86 400 секунд = 24 часа = «Длинное»
604 800 секунд = 7 дней = «Абсолютный максимум»
Как осуществляется поиск DNS?
Когда вы вводите в браузере какой-либо URL-адрес, создается целая серия поисков.
На каждом этапе этого процесса (часто этапов бывает больше, чем перечислено) задаются следующие вопросы.
1. Кэширована ли нужная запись?
2. Если да, действительно ли ее значение TTL?
Если на какой-либо из этих вопросов получен ответ «Нет», запрос перемещается на следующее звено цепочки.
Почему в основе системы DNS лежат сетевые подключения, а не устройства?
Устранение проблем с DNS представляет собой непростую задачу не только из-за ряда сложностей, связанных с использованием TTL и системы кэширования, но и потому, что подключение многих современных устройств осуществляется через различные сети и цепочки серверов DNS.
Рассмотрим ситуацию на примере обычного ноутбука. Я, как правило, работаю на ноутбуке дома. Несмотря на то что я уже несколько недель никуда его не брал, за это время на устройстве устанавливались следующие подключения:
• к основной домашней сети Wi-Fi/кабельной сети;
• к мобильному телефону при недоступности кабельной сети;
• оба варианта выше, но с подключением через VPN.
При каждой смене сети активируется новая цепочка DNS. Если это происходит в момент внесения изменений, серверы и узлы кэширования в цепочке DNS могут предоставлять неверные данные.
Сразу же начнется паника: «Веб-сервер не работает!», «Это конец света!», «Где мои брюки?». Но, приступив к устранению проблемы, вы обнаружите, что ее причиной стало незакрытое подключение через VPN.
2. УСТРАНЕНИЕ ПРОБЛЕМ С TTL В ЗАПИСЯХ DNS
Сколько времени требуется на обновление записи DNS?
Для расчета максимального (худший случай) временного интервала, необходимого на обновление значения записи DNS в ссылках для всех клиентов, умножьте число звеньев цепочки (без учета полномочного сервера) на значение TTL.
Например, если значение TTL составляет 3600 секунд (1 час), а цепочка DNS состоит из 5 звеньев, полное распространение изменений должно занять не более 18 000 секунд (5 часов).
Но если бы все было так просто.
Каковы затраты на поиск DNS?
Когда речь заходит о «затратах» на поиск DNS, обычно имеются в виду не денежные, а временные затраты. В зависимости от численности интернет-гремлинов в глобальной сети на выполнение запроса DNS обычно уходит 100–200 миллисекунд.
Это очень небольшое время, но представьте себе веб-страницу. Соответствие между именем и IP-адресом в системе DNS необходимо настроить для всех изображений, файлов CSS и файлов активов JavaScript, доступных по ссылкам на странице. Без кэширования время загрузки заметно увеличится.
Упрощенная схема расчета затрат на поиск DNS
Я назвал эту схему упрощенной, поскольку маловероятно, что все активы на вашем веб-сайте находятся в разных доменах. Кроме того, в браузеры встраивается множество различных средств кэширования, которые обеспечивают более быструю загрузку содержимого, чем показано в моей схеме.
(30 файлов изображений x 50 мс на загрузку каждого файла) + (100 мс на выполнение одного поиска DNS с последующим кэшированием) = 1600 мс
(30 файлов изображений x 50 мс на загрузку каждого файла) + (30 x 100 мс на каждый поиск DNS) = 3000 мс
Почему мои записи DNS не обновляются?
Существуют и другие факторы, увеличивающие время распространения изменений. Некоторые из них перечислены ниже.
• Веб-браузеры самостоятельно кэшируют записи DNS и хранят их в течение некоторого времени без учета TTL, что якобы повышает скорость их работы. Например, современные версии Internet Explorer по умолчанию кэшируют записи DNS на 30 минут (до версии IE 4 это время составляло 24 часа) и игнорируют более низкие значения TTL.
• Поставщики мобильного Интернета могут пытаться уменьшить общий объем передаваемого трафика путем увеличения времени TTL, что снижает частоту запросов.
• Сложные внутренние сети с большим числом сервером DNS, чем предполагалось, обновляются дольше по очевидным причинам.
Именно поэтому во многих службах можно встретить следующее заявление: «Полное распространение изменений в записях DNS может занять несколько дней, поэтому планируйте свои действия соответствующим образом».
Можно ли как-нибудь принудить клиент удаленно обновить запись DNS?
Этот вопрос обычно задается в следующем контексте: «После обновления записей DNS клиент не может получить доступ к некоторым сайтам. Как выполнить обновление принудительно?»
К сожалению, единственный ответ на этот вопрос: «Никак». В системе DNS нет команды, позволяющей принудительно выполнить раннее обновление данных для клиентов более низкого уровня.
Можно использовать команды для удаления записей DNS из локального кэша, но обычно они работают не так эффективно, как хотелось бы, из-за наличия как восходящих (кэширование записей DNS на стороне поставщика Интернета), так и нисходящих (кэширование записей DNS в браузере) каналов.
Лучше всего изменить значения TTL в своих записях заблаговременно.
3. РЕКОМЕНДАЦИИ ПО УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ В ЗАПИСЯХ DNS
Какие значения TTL лучше: маленькие или большие?
Разработчики уже давно ведут священную войну по поводу того, как нужно оформлять отступы в коде: с помощью знаков табуляции или пробелов. Я выяснил, что сетевые администраторы испытывают примерно те же чувства, когда дело касается длительности TTL.
Обычно это мнение подкрепляется их собственным опытом по отражению предыдущих сетевых атак и устранению проблем с конфигурацией сети.
Атака DDOS, способная на 12 часов остановить работу корневых серверов DNS или аналогичных серверов поставщика Интернета, меньше скажется на сайтах с очень высоким значением TTL. В таких случаях клиенты будут работать даже при выключении или перегрузке сервера DNS.
Однако, если при переключении узлов Интернета или электронной почты вы случайно сделаете ошибку, 12 часов без какой-либо возможности устранить ее — это последнее, что вам будет нужно. Именно поэтому некоторые администраторы считают, что время жизни не должно превышать 1 минуты.
Лично я стараюсь указывать для записей DNS малое значение TTL (меньше 1 часа/3600 секунд).
Как узнать, когда клиент запросит обновленную запись DNS?
Определить, когда все клиенты обновят данные, очень сложно.
Время жизни — это *не* срок годности. Не стоит сравнивать значение TTL в записи DNS с рекомендуемой датой употребления, указанной, например, на несвежем хлебе: это не определенное время, при наступлении которого запись станет недействительной и потребует замены.
Запись DNS — это, скорее, штатное расписание, изменения в котором медленно распространяются по всей сети. Когда у клиентов, расположенных в расписании «ниже», истекает срок действия кэша, они запрашивают запись у сервера DNS более высокого уровня.
Как лучше всего изменять записи DNS?
Создание «плана» или «стратегии» для выполнения относительно простых задач, к которым относится изменение одной записи в домене, может казаться перегибом, но, учитывая колоссальное влияние сбоев DNS на доступность ваших данных, определенную осторожность проявить все же стоит. Как говорится в старой пословице: «Предотвратить легче, чем лечить».
Есть простой способ свести ошибки к минимуму: никогда не обновляйте запись DNS и значение TTL для этой записи одновременно. В идеале у вас должен быть реализован следующий процесс.
1. За несколько дней до переключения укажите для параметра TTL записи DNS низкое значение, например 300 секунд.
2. Установите для записи дату переключения.
3. Через несколько дней после переключения задайте более высокое значение TTL.
Как лучше всего добавлять новые записи DNS?
Добавить новую запись проще, чем изменить существующую.
1. Добавьте запись с низким значением TTL.
2. Проверьте, все ли работает, и увеличьте значение TTL.
Какое значение TTL наиболее распространено?
Мнения относительно *правильного* значения TTL настолько расходятся, что мы предприняли попытку определить его на основе статистики. Список из 500 самых важных веб-сайтов по версии Moz показался нам отличным срезом Интернета. Кроме того, на этом ресурсе был доступен готовый файл CSV с перечнем сайтов, вошедших в итоговый список.
Я написал небольшой сценарий для выполнения итерации по списку и поиска текущего значения TTL для основной записи в каждом домене. Как и в любом проекте по анализу данных, эти данные будут сильно варьироваться в зависимости от постановки вопроса. Пример не всеобъемлющий, в нем представлены текущие (кэшированные) результаты и т. д. и т. п. Невзирая на все эти оговорки, полученные результаты все же имеют определенную ценность.
Анализ значений TTL для 500 важнейших интернет-доменов по версии Moz
Минимальное значение TTL: 1
Максимальное значение TTL: 129 540
Домены с установленным соответствием: 485
Среднее арифметическое значение TTL: 6468
Медианное значение TTL: 300
При необходимости обосновать свое решение об установке низкого (в пределах 1 часа, 3600 секунд) значения TTL вы можете предоставить медианное значение 300 секунд (5 минут) и уверенно заявить, что у вас есть эмпирическое доказательство правильности своего выбора.
4. ИНСТРУМЕНТЫ ПЛАТФОРМЫ DNS
Как проверить значение TTL для записи DNS в Windows?
Значение TTL указывается в нижней части выходных данных. Фраза Non-authoritative answer (Не заслуживающий доверия ответ) указывает на значение TTL, полученное от клиента (2 минуты 11 секунд до проверки локальным клиентом следующего уровня в цепочке DNS).
Как проверить значение TTL для записи DNS в Unix/Linux/Mac?
Значение TTL обведено красным цветом.
Как проверить запись DNS через Интернет?
Значение TTL обведено красным цветом.
Как убедиться в распространении TTL для записи DNS?
Если вам необходимо выяснить, обновлены ли на конкретном сервере DNS параметры записи DNS, то в любом инструменте DNS (dig, nslookup и т. д.) вместо локальной настройки по умолчанию можно выбрать сервер DNS, на котором будет выполнен запрос.
ДАЛЬНЕЙШИЕ ДЕЙСТВИЯ ПО НАСТРОЙКЕ TTL ДЛЯ ЗАПИСЕЙ DNS
Настройка TTL для записей DNS может оказаться непростой задачей, но при выборе небольших значений (меньше одного часа) вы сможете сохранить работоспособность сети и лучше подготовить ее к внедрению изменений.
Если вам понравилась эта статья, я рекомендую также ознакомиться с нашим курсом, посвященным основам веб-безопасности. Это поможет вам лучше защитить сайт или приложение, для которого вы только что настроили запись DNS. Курс бесплатный и очень информативный.
TTL означает «время жизни» и указывает, как долго ваши настройки DNS должны храниться в кэше, прежде чем они будут автоматически обновлены.
Когда происходит изменение DNS, остальной части Интернета требуется время, чтобы это заметить. Некоторые примеры таких изменений: обновление IP-адреса сервера, обновление записи MX для размещения вашей электронной почты в новом месте или добавление нового веб-сайта. Параметр TTL сообщает Интернету, как долго ждать, прежде чем вернуться для проверки вашей записи DNS на предмет потенциально новой информации.
Если для параметра TTL DNS установлено значение 12 часов, ваши записи DNS будут кэшироваться в течение 12 часов, прежде чем срок их действия истечет, и новая информация вступит в силу.
TTL на доменах IONOS устанавливается на срок до 1 часа для всех записей A, AAA, MX, TXT и CNAME.
Как работает DNS: рекурсивные и авторитетные DNS-серверы
Во-первых, нам нужно немного объяснить систему DNS. Существует два вида DNS-серверов: авторитетные и рекурсивные.
Рекурсивные DNS-серверы сами по себе ничего не знают о том, кому принадлежит какой IP-адрес. Они вычисляют IP-адрес для домена, запрашивая его у соответствующих авторитетных DNS-серверов, а затем кэшируют этот IP-адрес на случай, если их снова спросят о нем. Так, 8.8.8.8 — это рекурсивный DNS-сервер.
Когда люди посещают ваш веб-сайт, они, вероятно, делают DNS-запросы к рекурсивному DNS-серверу. Итак, как же работают рекурсивные DNS-серверы? Давайте посмотрим!
Шаг 1: IP-адреса для корневых DNS-серверов жестко закодированы в его исходном коде. Вы можете увидеть это в исходном коде unbound. Допустим, для начала он выберет 198.41.0.4. Вот официальный источник этих жестко закодированных IP-адресов, также известный как «корневой файл подсказок» (root hints file).
Детали ответа DNS немного сложнее — в этом случае есть раздел авторитетности (authority section) с некоторыми записями NS и дополнительный раздел с записями A, так что вам не нужно делать дополнительный поиск, чтобы получить IP-адреса этих серверов имен.
Мы почти закончили!
Лучшие практики DNS TTL
По большей части нет необходимости изменять TTL. Однако, если вы знаете, что скоро внесете большое изменение в DNS, и хотите, чтобы изменения вступили в силу быстро, вы можете изменить свой TTL заранее.
По крайней мере, за 24 часа до начала обновите TTL до более короткого значения. Например, вы можете изменить его на 3600 (1 час).
Когда ваша работа будет сделана, обязательно вернитесь и верните свои настройки TTL к исходным значениям. Кэширование DNS — важный способ снизить нагрузку на серверы, и лучше всего поддерживать низкий уровень этого трафика.
Как увидеть все шаги рекурсивного DNS-сервера: dig +trace
Чтобы посмотреть, что рекурсивный DNS-сервер будет делать для резолвинга домена, можно запустить:
Эта команда показывает все DNS-записи, которые запрашивает рекурсивный сервер, начиная с корневых DNS-серверов, то есть все четыре шага, которые мы только что прошли.
Максимальное значение TTL DNS
Максимальное значение TTL — 604800 (7 дней). Хотя технически не существует максимального значения TTL для DNS, значения более 7 дней будут автоматически округляться до 7 дней.
Рекомендация: для большинства пользователей максимальное значение TTL для DNS 86400 (24 часа) является хорошим выбором.
Обнаружение службы с помощью mDNS
mDNS можно использовать для обнаружения таких сервисов, как MQTT, в вашей локальной сети.
Клиент mDNS отправляет запрос для этой службы, как показано ниже, с помощью утилиты avahi-browse:
Вы можете видеть, что эта служба доступна на машине с именем pi2 и на IPv4 и IPv6.
В Windows используйте команду dns -sd -B имя службы
Как обновляются ваши серверы имен
Как изменить TTL, если у вас есть собственный DNS
Если вы используете собственный DNS-сервер, для изменения TTL достаточно отредактировать файл зоны и убедиться, что ваша DNS-служба принимает изменения. Специфика будет зависеть от того, какую службу DNS вы используете, а в некоторых случаях от того, какую версию Linux или Unix вы используете.
После внесения изменений вы можете проверить, вступили ли они в силу, запросив у вашего сервера новую информацию DNS с помощью команды:
BIND — это наиболее широко используемое программное обеспечение DNS. В BIND TTL хранится в верхней части файла зоны, обычно во второй строке. Объявление TTL начинается с $TTL. По умолчанию TTL составляет четыре часа (14 400 секунд):
Поиск файла зоны: Red Hat и CentOS
Поиск файла зоны: Debian и Ubuntu
Редактирование файла зоны
В файле зоны вам нужно будет отредактировать две строки: TTL и серийный номер.
- Обновите TTL до значения, которое вы хотите использовать.
- Обновите серийный номер, чтобы BIND зарегистрировал изменение.
TTL будет первой строкой файла и будет выглядеть примерно так:
Просто измените число на значение TTL, которое вы хотите установить, в секундах.
Обновление серийного номера
В типичной конфигурации серийный номер нужно просто увеличить. Например, серийный номер 1234будет обновлен до 1235.
Некоторые системные администраторы могут использовать метку времени, номер версии или иметь системы для автоматического увеличения серийного номера. Если вы не уверены, какая система используется для серийных номеров BIND, обратитесь к администратору вашего сервера.
Сохраните и выйдите из файла.
Перед тем, как перезагрузить изменения, проверьте синтаксис основной конфигурации BIND с помощью команды:
Если все в порядке, проверьте синтаксис только что отредактированного файла зоны с помощью команды:
Если файлы проходят проверку синтаксиса, перезагрузите файл зоны в BIND с помощью команды:
Необязательно: в Red Hat и CentOS, если systemctlон был настроен, вы можете перезапустить BIND вместо этого, используя команду:
Несвязанный
Unbound недавно заменил BIND в качестве DNS-сервера по умолчанию во многих системах BSD, включая FreeBSD 10 и выше и OpenBSD 5.6 и выше.
По умолчанию в большинстве систем файл конфигурации находится по адресу:
- OpenBSD :/var/unbound/etc/unbound.conf
- FreeBSD 10.0 и ранее :/usr/local/etc/unbound/unbound.conf
- FreeBSD 10.1 и выше :/etc/unbound/unbound.conf
- Red Hat и CentOS 7 :/etc/unbound/unbound.conf
В файле конфигурации Unbound по умолчанию не указаны значения TTL. Вы можете добавить TTL в файл несвязанной зоны со следующими атрибутами:
- cache-max-ttl Максимальный период времени для кеширования TTL. По умолчанию 86400 секунд (1 день).
- cache-min-ttl Минимальная продолжительность кеширования TTL. По умолчанию 0 секунд. Примечание: официальная документация рекомендует оставить это значение равным нулю.
Чтобы изменить или установить TTL, отредактируйте unbound.conf файл:
Проверьте файл для cache-max-ttl и cache-min-ttl атрибутов. Если они уже существуют, вы будете их редактировать. Если их нет, вам нужно будет добавить их:
Поместите эти конфигурации в основной блок команд сервера, затем сохраните и выйдите из файла.
После редактирования файла конфигурации вы можете протестировать конфигурацию с помощью команды:
Наконец, перезапустите Unbound, чтобы изменения вступили в силу с помощью команды:
Многоадресный DNS является частью набора сетевых технологий с нулевой конфигурацией (zeroconf), предназначенных для того, чтобы устройства могли работать в сети без ручной настройки.
Многоадресный DNS используется для поиска устройства или службы по имени в небольшой локальной сети без использования предварительно настроенного сервера имен, например DNS.
Первоначально разработанный Apple, он носит название Bonjour. Это интернет-стандарт Multicast DNS RFC 6762.
Многоадресный DNS использует ту же структуру пакетов и команды, что и DNS, но не полагается на настроенный пользователем DNS-сервер.
Вместо этого компьютеры в сети создают свои собственные локальные записи DNS и сохраняют их локально в кэше (память компьютера).
В этом руководстве вы узнаете, как работает mDNS и как выполнять запросы mDNS с помощью служебных инструментов avahi и инструмента dns-sd из Bonjour sdk.
mDNS-записи
mDNS поддерживает как записи имен хостов (A и AAAA), так и записи SRV, как и в стандартной DNS.
Благодаря этому mDNS можно использовать для поиска хостов и служб в локальной сети.
Структура служебной записи может показаться запутанной на первый взгляд для любого, кто плохо знаком с служебными записями DNS.
Структура (взято из вики) показана ниже вместе с примером записи:
Вы должны заметить использование подчеркивания в структуре.
В конце записи имеем
Библиотека DNS-резолвера вашей программы также может кэшировать записи DNS
Еще одна причина, по которой TTL может не соблюдаться на практике: многие программы должны резолвить DNS-имена, а некоторые программы также будут кэшировать DNS-записи в памяти на неопределенный срок (до тех пор, пока программу не перезапустят).
Например, есть статья о настройке JVM TTL для поиска DNS-имен. Я сама писала не так много кода JVM для поиска DNS, но небольшой поиск в интернете о JVM и DNS создает впечатление, что вы можете настроить JVM так, чтобы он кэшировал каждый поиск DNS в течение бесконечного времени (например, см. этот тикет ElasticSearch).
Доменное имя.local
Все записи DNS имеют доменное имя, а для устройств и служб в локальных сетях, которые не являются частью глобального пространства имен DNS, было зарезервировано доменное имя .local.
Это означает, что все хосты в локальной сети будут иметь имя вида.
host1.local
Преобразователь mDNS на клиенте регистрирует узел с префиксом .local.
Поэтому, когда вы выполняете ping в локальной сети, вы должны использовать:
для компьютера под названием ws6 в вашей локальной сети. Локальный преобразователь имен автоматически выберет mDNS в качестве первого выбора для разрешения имени из-за наличия суффикса .local.
Как работает mDNS
Полезно сравнить mDNS с традиционной службой DNS, особенно если вы знакомы с DNS.
Адрес этого DNS-сервера является частью сетевой конфигурации хоста.
При использовании mDNS сервер mDNS предварительно не настроен, и хост использует многоадресный запрос по адресу IPv4 224.0.0.251 или адресу IPv6 ff02::fb и порту UDP 5353.
Примечание. Многоадресная рассылка — это метод отправки данных группе компьютеров в IP-сетях.
Все хосты mDNS теперь знают имя и IP-адрес запрошенного хоста.
- Хост A отправляет запрос IP-адреса хоста Z.
- Все хосты mDNS видят этот запрос.
- Хост Z отвечает своим IP-адресом
- Все хосты mDNS видят этот ответ.
- Все хосты mDNS обновляют свой локальный кеш с именем хоста Z и его IP-адресом.
Читайте также: