TTL в сети: как работает и значение для кэширования
TTL (Time to Live) – это как срок годности �� для данных в сети или кэше. Он говорит, сколько времени или сколько «шагов» данные могут существовать, прежде чем их нужно удалить или обновить. Это помогает держать информацию актуальной и предотвращает её бесконечное блуждание по сети.
TTL решает проблему засорения сети устаревшими данными и уменьшает риск зацикливания пакетов данных. Это как уборщик, который регулярно проверяет, что пора выкинуть, чтобы всё работало чётко и без застоев. ��
Это важно, потому что упрощает управление данными и повышает эффективность работы приложений и сетей. Знание о TTL позволяет создавать более быстрые и надёжные программы, где каждый бит информации находится там, где ему место, и в то время, когда он актуален.
Пример
Давайте представим, что вы отправляете письмо другу, которое должно доставиться в течение 5 дней. Если письмо не достигнет его в этот срок, оно будет уничтожено. В мире компьютерных сетей, такой «срок жизни» письма называется TTL (Time to Live), и он помогает управлять данными, передаваемыми через сеть.
�� Пример с DNS запросом:
Представим, что вы хотите зайти на сайт example.com . Ваш компьютер не знает IP-адрес этого сайта, поэтому он отправляет запрос к DNS-серверу, чтобы узнать его. DNS-сервер отвечает и сообщает IP-адрес, но также указывает TTL для этой информации, например, 24 часа. Это означает, что ваш компьютер может «запомнить» этот IP-адрес в течение 24 часов, и если вы захотите снова зайти на example.com в течение этого времени, ваш компьютер не будет каждый раз спрашивать DNS-сервер, а сразу обратится к запомненному IP-адресу. Это ускоряет загрузку сайта и снижает нагрузку на DNS-серверы.
Скопировать код
# Пример кода, показывающего как может работать кэширование DNS с TTL в Python (упрощенно) import time # Кэш DNS-записей (простой пример) dns_cache = <> def get_ip_address(url): # Проверяем, есть ли URL в кэше и не истек ли TTL if url in dns_cache and (time.time() – dns_cache[url]['timestamp']) < dns_cache[url]['ttl']: print(f"Используем кэшированный IP для ") return dns_cache[url]['ip'] else: # Здесь должен быть запрос к DNS-серверу, но мы просто вернем пример IP и TTL print(f"Запрашиваем IP для у DNS-сервера") ip_address = "93.184.216.34" # Пример IP-адреса ttl = 86400 # Пример TTL в секундах (24 часа) # Обновляем кэш dns_cache[url] = return ip_address # Пример использования ip_example = get_ip_address("example.com") time.sleep(2) # Имитация задержки ip_example_again = get_ip_address("example.com")В этом примере мы видим, как TTL помогает оптимизировать процесс получения IP-адреса сайта, снижая нагрузку на сеть и ускоряя доступ к ресурсам.
TTL в сети: основы и принципы работы
Что такое TTL и как он работает в сети? TTL, или Time to Live, это параметр, который определяет, сколько времени или сколько переходов (хопов) данные могут совершить в сети, прежде чем будут уничтожены или обновлены. Этот механизм предотвращает бесконечное циркулирование "потерянных" пакетов данных в сети, тем самым обеспечивая её более эффективное функционирование.
Каждый раз, когда пакет данных проходит через маршрутизатор, значение TTL уменьшается на единицу. Если TTL достигает нуля, пакет уничтожается. Это предотвращает возможность зацикливания данных в сети, когда они не могут найти путь к месту назначения.
Значение TTL для DNS и кэширования
TTL в DNS играет ключевую роль в процессе кэширования. Он определяет, как долго информация о домене (например, IP-адрес сайта) сохраняется в кэше DNS-сервера или вашего компьютера. Это влияет на скорость доступа к веб-ресурсам: чем дольше данные остаются в кэше, тем быстрее ваш компьютер сможет их получить, не обращаясь к DNS-серверу.
Однако слишком долгое кэширование может привести к проблемам с доступностью сайтов, если их IP-адреса изменятся. Поэтому важно найти баланс между скоростью доступа и актуальностью данных, корректно настраивая TTL.
Настройка TTL и её влияние на сеть
Настройка TTL может значительно повлиять на производительность сети и приложений. Администраторы сетей и разработчики могут устанавливать различные значения TTL, исходя из требований к актуальности данных и нагрузке на сеть. Например, для динамически изменяющихся данных, таких как акции или новости, предпочтительнее использовать меньшее значение TTL, чтобы обеспечить их своевременное обновление.
В то же время, для статического контента, который не меняется часто, можно установить более длительный TTL, что уменьшит количество запросов к серверу и ускорит загрузку страниц для пользователей.
TTL и IPv6: от TTL к Hop Limit
В контексте IPv6, концепция TTL была заменена на Hop Limit. Это изменение отражает сдвиг в подходе к управлению временем жизни пакетов данных. Хотя основная идея осталась прежней – предотвращение бесконечного циркулирования данных в сети, – терминология и некоторые детали реализации были обновлены, чтобы лучше соответствовать новым стандартам и возможностям сетей IPv6.
Понимание и применение TTL в управлении данными
Понимание TTL и его правильное применение в кэшировании и управлении данными критично для оптимизации производительности приложений и сетей. Это позволяет не только ускорить доступ к информации, но и уменьшить нагрузку на сервера, снизить задержки и обеспечить актуальность данных.
Применение стратегий кэширования, таких как LRU (Least Recently Used), позволяет эффективно управлять кэшем, автоматически удаляя наименее используемые данные для освобождения места для новых. Это обеспечивает баланс между быстродействием и актуальностью информации, делая работу приложений более эффективной.
В заключение, TTL является ключевым элементом в управлении данными и кэшировании в сети. Правильное понимание и использование TTL может значительно улучшить производительность сетей и приложений, обеспечивая быстрый доступ к актуальной информации при минимальной нагрузке на ресурсы.
Что такое TTL
Time to live (TTL) – это время жизни пакета. TTL показывает максимальный период времени существования набора данных (пакета).
TTL IP-пакетов
В IPv4 TTL представляет собой восьмиразрядное поле IP-заголовка. Параметр TTL считается верхней границей времени существования IP-дейтаграммы в сети. Поле TTL устанавливается отправителем пакета и уменьшается в течение всего процесса передачи данных, в соответствии со временем пребывания в данном устройстве, согласно протоколу обработки.
Основное назначение – не допустить длительной задержки, когда, например, в процессе передачи данных маршрутизатор отключился или была потеряна связь между двумя узлами.
В каждой промежуточной точке (маршрутизаторе) значение поля TTL уменьшается на 1 (данный параметр изменяется) до тех пор, пока пакет данных не достигнет точки назначения.
При условии, что значение на каком-либо из задействованных узлов достигнет 1, пакет данных уничтожается, а на исходный сервер посылается сообщение о необходимости повторить передачу пакета. В этом случае отправителю отправляется ICMP-пакет с кодом 11 — «Превышение временного интервала». При слишком маленьком значении пакет может просто не дойти, при слишком большом, в случае задержки, ожидание может занять много времени (при значении TTL 255 оно достигает 4 минут и 10 секунд).
Маршрутизатор не пропускает пакеты с нулевым значением TTL. Это делается для того, чтобы в случае ошибочной маршрутизации пакет не «гулял» бесконечно по сети, а уничтожался через некоторое время.
TTL у DNS
DNS в TTL – это параметр, отвечающий за использование записей DNS-зоны в памяти сервера без дополнительных изменений. По достижении установленного времени, кеширующий сервер запрашивает DNS-сервер, содержащий доменную зону и информацию о ней.
При использовании стандартных настроек TTL обновление произойдет на сервере через день. Перед запланированными процедурами первую строку записи следует изменить на значение 550 или меньше, после чего ввести serial number и перегрузить зоны, обновив DNS-сервер. После обновления данных можно начинать производить необходимые процедуры по миграции серверов. Проверку произвести с помощью команды dig. После этого произойдет обновление IP-адресов в течение указанного времени.
После выполнения всех процедур по передаче данных, значение TTL можно увеличить, чтобы снизить нагрузку на DNS-сервер и избежать использования большого трафика для обновления зон.
Хватит использовать смехотворно малый 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 минут:
Это не очень хорошо.
Накопительное распределение делает проблему ещё более очевидной:
В половине 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 для тестирования и забывают потом их изменить.
Кроме того, минутный 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.
$ 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 часом. Вполне разумный диапазон.
- Администрирование доменных имен
- IT-инфраструктура
- IT-стандарты
- Серверное администрирование
Подробное руководство по настройке TTL для записей DNS
Система DNS — это фундаментальный технологический продукт. Обработка практически всех сетевых запросов верхнего уровня и поисковых запросов в Интернете, пересылка интернет-трафика и электронной почты, а также многие другие операции становятся возможными благодаря установке определенных соответствий при поиске DNS (преобразованию таких имен, как some.domain.org, в IP-адреса или имена других доменов).
Мы решили написать о времени жизни (Time To Live, TTL) данных, поскольку большинству системных администраторов не приходится каждый день работать с конфигурациями DNS и значительная часть информации об этом параметре — это полузабытые байки, передаваемые системными администраторами из поколения в поколение.
Задав соответствующий вопрос в 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 могут предоставлять неверные данные.
Такое часто случается в корпоративных сетях, где имя домена Active Directory совпадает с адресом веб-сайта компании. На внешнем сервере DNS (уровень поставщика Интернета) хранится запись DNS, направляющая адрес www.example.com к верному IP-адресу/CNAME веб-сервера, но на внутреннем сервере DNS, используемом службой Active Directory, записи не дублируются.
Сразу же начнется паника: «Веб-сервер не работает!», «Это конец света!», «Где мои брюки?». Но, приступив к устранению проблемы, вы обнаружите, что ее причиной стало незакрытое подключение через 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
Вы можете просмотреть или изменить этот сценарий либо загрузить его и выполнить анализ самостоятельно: gist.github.com/mbuckbee/79b2e76bd9271bea38487defd8a9138b
Посмотреть список и загрузить его в формате CSV можно по адресу moz.com/top500
Минимальное значение TTL: 1
Максимальное значение TTL: 129 540
Домены с установленным соответствием: 485
Среднее арифметическое значение TTL: 6468
Медианное значение TTL: 300
Минимальные значения были получены от доменов, которые очень часто изменяют записи DNS в целях балансировки нагрузки. Максимальные значения соответствовали доменам, которые не обновлялись в течение длительного времени (да-да, python.org, это я про вас).
При необходимости обосновать свое решение об установке низкого (в пределах 1 часа, 3600 секунд) значения TTL вы можете предоставить медианное значение 300 секунд (5 минут) и уверенно заявить, что у вас есть эмпирическое доказательство правильности своего выбора.
4. ИНСТРУМЕНТЫ ПЛАТФОРМЫ DNS
Как проверить значение TTL для записи DNS в Windows?
Для проверки записей DNS в Windows проще всего использовать служебную программу nslookup: technet.microsoft.com/en-us/library/bb490950.aspx.
Пример: C:\>nslookup -type=cname -debug www.varonis.com
Значение TTL указывается в нижней части выходных данных. Фраза Non-authoritative answer (Не заслуживающий доверия ответ) указывает на значение TTL, полученное от клиента (2 минуты 11 секунд до проверки локальным клиентом следующего уровня в цепочке DNS).
Как проверить значение TTL для записи DNS в Unix/Linux/Mac?
В системе Unix (и ее производных) для устранения проблем с DNS используется команда dig.
Пример: dig www.varonis.com
Значение TTL обведено красным цветом.
Как проверить запись DNS через Интернет?
Иногда бывает так, что вам необходимо проверить запись DNS без компьютера под рукой. Удобная (и бесплатная) версия команды dig доступна в инструментах Google по следующему адресу: toolbox.googleapps.com/apps/dig.
Значение TTL обведено красным цветом.
Как убедиться в распространении TTL для записи DNS?
Если вам необходимо выяснить, обновлены ли на конкретном сервере DNS параметры записи DNS, то в любом инструменте DNS (dig, nslookup и т. д.) вместо локальной настройки по умолчанию можно выбрать сервер DNS, на котором будет выполнен запрос.
Для получения полной картины изменений я рекомендую ресурс whatsmydns.net, который позволяет проверить множество серверов DNS верхнего уровня (уровень поставщика Интернета) и выявить возможные проблемы.
ДАЛЬНЕЙШИЕ ДЕЙСТВИЯ ПО НАСТРОЙКЕ TTL ДЛЯ ЗАПИСЕЙ DNS
Настройка TTL для записей DNS может оказаться непростой задачей, но при выборе небольших значений (меньше одного часа) вы сможете сохранить работоспособность сети и лучше подготовить ее к внедрению изменений.
Если вам понравилась эта статья, я рекомендую также ознакомиться с нашим курсом, посвященным основам веб-безопасности. Это поможет вам лучше защитить сайт или приложение, для которого вы только что настроили запись DNS. Курс бесплатный и очень информативный.
- Блог компании Varonis Systems
- IT-инфраструктура
- DNS