Что такое ttl dns

Обновлено: 02.07.2024

Как у администратора DNS, есть ли у вас настройки времени жизни (TTL) по умолчанию для ваших DNS-серверов?

В неофициальном опросе клиентов BlueCat ответы включали восемь часов, два часа, один час и 15 минут. Некоторые администраторы изменяют свои TTL в зависимости от того, идет ли трафик DNS в их внутреннюю сеть или выходит в Интернет.

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

Существует ли наиболее распространенный TTL? Идеальный? Должен ли он быть длинным или коротким? Какой есть волшебный ответ?

(Если бы Джеймс Бонд имел право голоса в этом вопросе, он бы настаивал на том, что нет времени умирать — есть время жить.)

В этом посте речь пойдет о том, сколько времени осталось жить в контексте кэширования DNS. Затем будут обсуждаться факторы, которые следует учитывать при выборе правильного TTL для вашей сети. Наконец, в нем будет показано, как функции BlueCat Edge, связанные с TTL, могут сделать вашу сеть более безопасной и отказоустойчивой.

Небольшая группа ИТ-специалистов, обсудившая эти идеи, участвует в открытых дискуссиях BlueCat с экспертами по DDI и DNS. Все желающие могут присоединиться к Network VIP в Slack.

Что такое TTL для кэширования DNS?

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

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

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

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

Определение подходящего времени жизни для вашей сети

В одном можно быть уверенным, так это в том, что требования к TTL для каждой сети будут различаться.

"Это одна из тех областей DNS, где почти нет правильного ответа", – говорит Пабло Гарридо, старший технический менеджер по продуктам BlueCat Edge. «Это правильный ответ для случая использования».

Коротко, но не слишком

Короткие TTL имеют свои преимущества. Они могут увеличить скорость распространения DNS, ускорить обновление систем и повысить эффективность балансировки нагрузки.

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

Другой участник ИТ-сообщества Фрэнк Денис также недавно изложил свои доводы в пользу того, чтобы избегать слишком низких сроков жизни.

«Вы платите штраф. И ваши потребители за эту услугу платят за это незначительную плату за общий срок службы модели предоставления услуг», — сказал один из клиентов. «Если вы разработчик решений — облачных или корпоративных, для меня это не имеет особого значения — и вы разрабатываете что-то, для чего каким-то образом требуется почти нулевой TTL, вы провалились. Вы завалили свою работу по правильному проектированию этого решения».

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

Как клиенты устанавливают минимальное значение TTL

Один клиент устанавливает наименьшее значение TTL на основе среднего минимального времени, необходимого для переноса службы с одного сервера на другой. Другой устанавливает минимальный TTL и, если пользователи запрашивают что-то ниже этого, рассматривает запросы в каждом конкретном случае. Они могут понизить его для определенных событий, чтобы поддержать операции по быстрому изменению услуги. Но после завершения мероприятия они возвращают его к необходимому минимальному уровню.

«Если у вас есть реальная архитектура DNS, вы понимаете, где происходит кэширование и как ваши TTL будут взаимодействовать и взаимодействовать», — сказал клиент. «Тогда вы сможете принимать разумные решения относительно того, каким должен быть ваш TTL по умолчанию или где должны быть минимальные значения».

Повысьте безопасность и отказоустойчивость с помощью функций BlueCat Edge TTL

Говоря о том, что нет времени умирать, функция пространства имен в BlueCat Edge противостоит этой тенденции и позволяет запросам обрести вторую жизнь. Если запрос DNS получает ответ NXDOMAIN в первый раз, он может попробовать второй набор серверов ниже по течению. Называемая Intelligent Forwarding, она дает запросу как минимум две жизни. (Потому что, эй, ты живешь только дважды, верно?)

Функции Edge также обеспечивают пользователям большую безопасность и отказоустойчивость, особенно когда речь идет о DNS TTL.

Повышенная безопасность благодаря очистке кеша одним щелчком мыши и короткому сроку жизни

Пограничные точки обслуживания действуют как «первый переход» для клиентских устройств — по сути, кэширующий сервер пересылки. Но BlueCat обнаружил, что клиенты, которые хотят создать политики для блокировки определенного сетевого трафика, были обязаны TTL доменов для этих запросов. Вы можете принять политику, чтобы заблокировать их, да. Но это может вступить в силу только после истечения срока действия запросов в этом кеше.

С помощью Edge вы можете сбросить кеш в точке обслуживания одним щелчком мыши. Это позволяет новой политике немедленно вступить в силу. Однако важно отметить, что эта функция подходит не для всех случаев использования. Он реактивный и неуклюжий, так как очищает весь кеш.

В качестве более активной альтернативы Edge также имеет параметр пространства имен, называемый коротким сроком жизни. Просто установив флажок, все DNS-запросы, которые проходят через это пространство имен, автоматически получают 60-секундный TTL. Edge переопределяет TTL в ответе и делает его равным 60 секундам. В результате пользователи получают наиболее релевантные ответы на свои запросы.

Важно отметить, что вы можете настроить списки доменов, чтобы контролировать, какие полные доменные имена будут затронуты этими правилами. Таким образом, вы можете, например, исключить внутренние домены, которые вы не хотите контролировать с помощью сокращенного TTL.

Более высокая отказоустойчивость за счет обслуживания запросов с истекшим сроком действия из кеша

Для повышения отказоустойчивости Edge может обслуживать запросы из кеша после истечения срока жизни ответа. Это так же просто, как выбрать переключатель.

Функция просроченной подачи не влияет на срок жизни как таковой. Но он продлевает срок жизни просроченного ответа в кеше до тех пор, пока не будет получен новый ответ. Продление может длиться от одного до 24 часов.

В случае установки филиала обслуживание запросов с истекшим сроком действия из кеша в течение полного дня после истечения срока действия может помочь обеспечить бесперебойную работу. Или подумайте, не отвечают ли серверы пересылки для внутреннего пространства имен. Продлевая срок действия ответа с истекшим сроком действия, Edge по-прежнему может отвечать и показывать клиенту, что сбоя нет.

Подробнее о настройке запросов с истекшим сроком действия сервера из кэша в пограничной точке обслуживания:

Возможность полной настройки значений TTL

Для будущих выпусков Edge компания BlueCat рассматривает возможность полной настройки значений TTL.

Не слишком ли 60 секунд для короткого TTL? Может быть, это 15 секунд, которые вы хотите. Или при обслуживании запросов с истекшим сроком действия из кеша один час может оказаться слишком долгим, а 15 или 30 минут будут более эффективными.

Поделитесь своими мыслями об этой потенциальной функции управления кешем в Edge или о том, как вы настраиваете TTL в целом в Network VIP.

В идеальном мире DNS была бы похожа на одну из тех духовых шкафов-вертелов, показанных по телевизору: установите ее и забудьте. Однако Интернет — это динамично меняющееся место, и то, что может быть актуальным в один момент, может оказаться неактуальным в следующий.

Чтобы справиться с этим, DNS был разработан с механизмом обновления записей и гарантией того, что пользователи всегда получат наиболее подходящий ответ, когда они его запросят.

Основы

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

Время жизни SOA

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

SOA TTL – интервал обновления самой записи SOA.

Обновить TTL — интервал, с которым вторичные серверы (дополнительный DNS) должны обновлять файл первичной зоны с основного сервера.

Retry TTL — частота повторных попыток вторичного сервера обновить файл первичной зоны, если первоначальное обновление не удалось.

Срок действия TTL. Если обновление и повторная попытка повторяются неоднократно, это период времени, по истечении которого первичный объект считается удаленным и более недействительным для данной зоны.

NX TTL — в случае, если запрос домена приводит к несуществующему запросу (NXDOMAIN), это время, которое рекурсор соблюдает для возврата ответа NXDOMAIN.

Не рекомендуется изменять эти значения TTL, если только у вас нет особой необходимости в этом, что часто бывает очень редко.

Время жизни (TTL) определяет, как долго ваши записи будут храниться в кэше. Например, как долго ваша запись A будет храниться в кэше до получения новой копии записи с DNS-серверов. Хранилище записей называется кэшем DNS, а процесс хранения записей называется кэшированием.

Когда кэширующий (рекурсивный) сервер имен запрашивает у авторитетного сервера имен запись ресурса, он будет кэшировать эту запись на время (в секундах), указанное TTL. Если преобразователь-заглушка запрашивает у кэширующего сервера имен ту же запись до истечения TTL, кэширующий сервер просто ответит уже кэшированной записью ресурса, а не получит ее снова с уполномоченного сервера имен. TTL для ответов NXDOMAIN устанавливается из минимума поля MINIMUM записи SOA и TTL самого SOA и указывает, как долго преобразователь может кэшировать отрицательный ответ.

В следующих строках мы поговорим о наиболее распространенных практиках TTL и о том, почему TTL так важен для вас.

Значения TTL

Меньшие значения TTL могут увеличить нагрузку на полномочный сервер имен, но могут быть полезны при изменении адресов важных служб, таких как веб-серверы или записи MX, и поэтому администратор DNS часто уменьшает их перед перемещением службы, чтобы чтобы свести к минимуму сбои.

Используемые единицы измерения — секунды. Ранее общее значение TTL для DNS составляло 86400 секунд, что составляет 24 часа. Значение TTL, равное 86 400, означает, что если запись DNS была изменена на полномочном сервере имен, DNS-серверы по всему миру могут по-прежнему показывать старое значение из своего кеша в течение 24 часов после изменения.

В ClouDNS TTL по умолчанию составляет 3600 секунд (1 час). TTL может быть установлен от 60 секунд (1 минута) до 2592000 секунд (1 месяц) для каждой отдельной записи. Эта опция доступна только для аккаунтов с подпиской Premium/DDoS/GeoDNS. Если ваша учетная запись находится на бесплатной подписке, вы не можете изменить TTL.

Вы также можете установить срок жизни по умолчанию для всех добавляемых записей DNS, отличный от 3600 секунд (1 час). Вы можете получить доступ к этой опции, зайдя в настройки профиля вашей учетной записи ClouDNS, в частности, в раздел «Веб-настройки». Аналогично функции изменения TTL, параметр TTL по умолчанию доступен только для учетных записей с подписками Premium, DDoS Protected и GeoDNS

Значения TTL в ClouDNS

В ClouDNS мы поддерживаем разные значения TTL. Они следующие:

1 минута
5 минут
15 минут
30 минут
1 час
6 часов
12 часов
1 день
2 дня
3 дня
1 неделя
2 недели
1 месяц

Почему TTL важен для вас?

В большинстве случаев вам не нужно менять значение TTL. Значение TTL по умолчанию, равное 3600 (1 час), достаточно для быстрого распространения изменений, но не настолько мало, чтобы DNS-серверы были перегружены. Однако значение TTL становится очень важным, если в ваших записях A/AAAA есть служба, которая динамически обновляет значения конечной точки, такие как Dynamic DNS и/или DNS Failover. В этом случае вам, безусловно, следует рассмотреть возможность установки более низкого значения TTL для этих конкретных ваших записей.

Как изменить TTL

Вы можете изменить значение TTL для каждой из ваших записей DNS. Для этого перейдите на страницу управления зоной DNS и щелкните значок «Изменить» для соответствующей записи DNS. Появится новое всплывающее окно. Выберите нужное значение TTL в раскрывающемся меню "TTL" и сохраните изменения.

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

Мы в SIDN Labs и USC/ISI провели исследование измерений, чтобы понять, как различные значения TTL влияют на рабочие сети, чтобы помочь операторам сделать осознанный выбор значений TTL для своих сценариев. Мы уведомили 8 операторов нДВУ с короткими значениями TTL, после чего уругвайский домен .uy увеличил TTL своих записей NS, что привело к значительному уменьшению задержки пользователей. Следующий пост представляет собой краткое изложение выводов и рекомендаций, изложенных в нашем исследовательском документе, который мы представим на предстоящей конференции ACM IMC 2019 в Амстердаме.

Значения DNS TTL могут варьироваться от 0 секунд до 248555 дней (2^31 -1 секунд). Учитывая такой большой диапазон возможных значений, трудно понять, какие значения выбрать. Точно понять, как выбор значения TTL влияет на операционные сети, сложно из-за взаимодействий в распределенной службе DNS.

TTL косвенно управляют кэшированием распознавателя. Кэширование, в свою очередь, является краеугольным камнем производительности DNS: ответ за 15 мс — это быстро, а кешированный ответ за 1 мс — гораздо быстрее.

Для разрешения доменного имени пользователь обычно подключается к преобразователю DNS (как показано на рис. 2 ниже). Затем этот преобразователь перенаправляет запрос пользователя на полномочный сервер DNS, который, в свою очередь, отправляет ответ на запрос с сопроводительным значением TTL (1h на этом рисунке). Это означает, что преобразователь может кэшировать полученный ответ на срок до 1 часа.

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

В этом смысле кэширование можно рассматривать как форму эфемерной репликации на стороне преобразователя (в предыдущем исследовании мы показали, как кэширование защищает пользователей, когда авторитетные серверы подвергаются DDoS-атаке).

Рисунок 2. Клиенты, резолвер с кэшированием и авторитетные серверы

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

Чтобы понять, какие значения обычно используются в реальных условиях, мы просканировали пять источников данных:

Один национальный домен верхнего уровня (.nl, Нидерланды) с 5,8 млн доменных имен.
Три лучших списка (Alexa, Majestic и Umbrella)
Корневая зона DNS

Для каждого домена мы запросили записи NS, A, AAAA, MX, DNSKEY с дочерних полномочных серверов.

На рис. 3 показаны результаты для записей NS и A для рассматриваемых доменов (остальные записи можно найти в нашей исследовательской статье). Мы видим, что:

Рисунок 3: CDF TTL для записей NS и A

Увеличение задержки в домене .uy в Уругвае за счет увеличения TTL

При сканировании корневой зоны (домены верхнего уровня) мы обнаружили 34 домена верхнего уровня (TLD) со значениями TTL для записей NS менее 30 минут, что очень мало по сравнению с другими TLD. Мы связались с 8 из 34 национальных доменов верхнего уровня и уведомили их о нашем наблюдении. Мы получили ответы от пяти; и трое увеличили TTL своих записей NS после нашего первого контакта:

Записи Уругвая .uy NS были изменены с 300 NS TTL на 86 400 (1 день)
Африканский ccTLD и ближневосточный ccTLD также увеличили свои NS TTL с 480 и 30 до 86400.

По воле случая мы провели измерения DNS в нДВУ .uy перед изменением TTL: 10 000 зондов RIPE Atlas были использованы для запроса записей NS и A. Мы повторили измерение после внесения изменений, чтобы увидеть, как это повлияло на удобство работы пользователей (результаты показаны на рис. 4).

На рис. 4 показано, что медианная задержка сократилась с 28 мс до 8 мс, а задержка 75-го процентиля сократилась со 183 мс до 21 мс — всего лишь за счет изменения одного параметра. Другими словами, средний пользователь .uy заметил изменение времени отклика на 20 мс просто в результате изменения TTL. А пользователь из 75-го процентиля заметит улучшение более чем на 160 мс.

Наши результаты также показывают увеличение задержки в точках обзора зондов RIPE Atlas в зависимости от их географического региона: прирост производительности наблюдался во всех регионах. Важно отметить, что это значительные улучшения производительности, требующие только одного изменения параметра и никаких изменений в файле .uy инфраструктура вообще.

Это немалый подвиг: операторы DNS постоянно стремятся уменьшить задержку. Anycast IP также часто используется для размещения более авторитетных серверов рядом с преобразователями для повышения производительности. Но, как показано в нашей статье (раздел 6.2), кэширование с более длинным TTL выполняется даже быстрее, чем любое вещание с более коротким TTL.

Рис. 4. RTT от RIPE Atlas VP для запросов NS .uy до и после изменения записей TTL NS. Верх – объединенные ВП. Внизу – медиана и количество RTT по регионам

Существует множество причин, по которым сетевые операторы выбирают длинные или короткие TTL:

Более длительное кэширование приводит к более быстрым ответам: более длительный TTL позволяет кэшировать в течение более длительных периодов времени, а обращения к кэшу выполняются намного быстрее, чем получение ответов с авторитетных серверов, как показывает опыт .uy. Мы разработали несколько экспериментов для исследования этого, которые описаны в нашей статье. Результаты показывают, что более длительное кэширование улучшает результаты даже в большей степени, чем большая сеть произвольной рассылки.

Более длительное кэширование приводит к меньшему трафику DNS: авторитетные операторы могут быть заинтересованы в установке более высоких значений TTL, поскольку кэширование сокращает количество получаемых ими запросов. Это особенно важно, если служба DNS измеряется.

Длительное кэширование более устойчиво к DDoS-атакам на авторитетный DNS-сервер: DDoS-атаки на поставщика услуг DNS нанесли ущерб нескольким известным веб-сайтам . Недавняя работа показала, что кэширование DNS может значительно уменьшить влияние DDoS на DNS, если кэши сохраняются дольше, чем атака.

Кэширование в более короткие сроки облегчает оперативные изменения : простой способ перехода со старого сервера на новый — изменить записи DNS. Поскольку нет возможности удалить кэшированные записи DNS, продолжительность TTL представляет собой задержку перехода, необходимую для полной миграции на новый сервер. Поэтому низкие значения TTL обеспечивают более быстрый переход. Однако, если развертывание запланировано на более раннее время, чем длина TTL, TTL можно снизить непосредственно перед крупными операционными изменениями и снова поднять после того, как изменение вступит в силу.

Укороченное кэширование может помочь при реагировании на DDoS-атаки на основе DNS: некоторые службы очистки от DDoS-атак используют DNS для перенаправления трафика во время атаки. Поскольку DDoS-атаки происходят без предупреждения, перенаправление трафика на основе DNS требует, чтобы значение TTL всегда оставалось достаточно низким, чтобы быть готовым отреагировать на потенциальную атаку.

Сокращение времени кэширования помогает балансировке нагрузки на основе DNS: многие крупные службы используют балансировку нагрузки на основе DNS. Каждый входящий DNS-запрос дает возможность регулировать нагрузку, поэтому короткие TTL могут быть желательны для быстрого реагирования на динамику трафика. (Хотя у многих рекурсивных распознавателей минимальное время кэширования составляет десятки секунд, что ограничивает гибкость.)

Хотя наш анализ не предлагает единого идеального значения TTL, он проясняет компромиссы, что позволяет нам дать следующие рекомендации для различных ситуаций:

Длительность TTL: выбор значения TTL частично зависит от внешних факторов, поэтому нет единой рекомендации, подходящей для всех сетей или типов сетей.

TTL (или Time to Live) — это важнейший параметр в каждой записи DNS… и тем не менее о нем редко говорят.

Если вы виновны в использовании TTL по умолчанию для своих записей, вам необходимо прочитать это.

Как работает TTL?

[ Если вы уже знаете, просто пропустите! ]

TTL сообщает разрешающим серверам имен, как долго следует кэшировать информацию DNS (например, наличные деньги). Серверы разрешений имен подобны посредникам при обмене DNS. Когда вы вводите домен в свой браузер, вы фактически запрашиваете IP-адрес этого домена у локального сервера разрешений имен.

< /p>

Если кто-то недавно сделал такой же запрос, информация, скорее всего, будет сохранена в кэше разрешающего сервера имен. Если это не так, то разрешающий сервер имен обратится к полномочному серверу имен для этого домена — обычно это поставщик DNS.

После того как запись, указывающая домен на соответствующий IP-адрес, найдена, эта информация сохраняется на разрешающем сервере имен. Это ускоряет время разрешения для следующего запроса домена на этом распознавателе.

Почему значение TTL имеет значение?

Для базовых записей A и CNAME вы, скорее всего, не столкнетесь со сценариями, в которых время TTL вызывает проблемы. Однако, как только вы начнете динамически изменять конечные точки, такие как отказоустойчивость, значение TTL становится очень важным.

Например, предположим, что основной IP-адрес искомого домена недоступен. В этом домене также включен переход на другой ресурс, который будет указывать пользователям на резервный IP-адрес, когда основной не работает.

Это можно решить двумя способами. Если запись имеет высокий TTL, пользователи по-прежнему будут указывать на первичный IP-адрес, пока не истечет срок действия кеша распознавателя. Если у записи низкий TTL, вероятность того, что она будет указана на правильную конечную точку раньше, выше.

Когда удерживать TTL коротким

Если к записи применено какое-либо правило, которое динамически обновляет конечную точку, например отказоустойчивость или балансировка нагрузки, вам потребуется короткий TTL.

Каждый раз, когда вы собираетесь изменить TTL, спросите себя,

"Как долго мне будет удобно, если пользователи перейдут на недоступную конечную точку до обновления кеша?"

Страшно подумать.

Для любых важных записей всегда следует поддерживать низкий срок жизни. Хорошим диапазоном будет от 30 секунд до 5 минут.

Если вы вносите какие-либо изменения в записи, вам нужно сделать TTL как можно меньше. Любые внесенные вами изменения не вступят в силу, пока не истечет срок жизни.

Обратите внимание, что минимальное значение TTL в DNS Made Easy составляет 30 секунд. Это связано с тем, что серверы имен обычно обращают внимание только на значения TTL, равные 30 секундам или выше.

Вам также нужен низкий TTL, если у вас есть какие-либо дополнительные настройки, такие как правила GeoDNS. Это в большей степени относится к нашему новому продукту Constellix, который позволяет создавать правила, изменяющие возвращаемые конечные точки в зависимости от местоположения пользователя.

Здесь мы попали в серую зону. Если у вас есть какие-либо некритические записи, но вы знаете, что можете внести в них изменения в ближайшем будущем, вам может понадобиться короткий TTL. Вы также не хотите платить за большее количество запросов, которые приходят с более низким TTL, поэтому не хотите, чтобы он был всего 30 секунд или даже полчаса. В этом случае вы хотели бы использовать более длинный TTL от 1 до 12 часов.

Когда использовать длинный TTL

Стоимость становится важным фактором для TTL. Подумайте об этом: чем короче TTL, тем чаще авторитетным серверам имен придется отвечать на запросы, и тем выше будет ваш ежемесячный счет.

Увеличение TTL также сокращает время разрешения. Каждый раз, когда запрос обращается к полномочному серверу имен, добавляется дополнительный поиск, который может добавить драгоценные миллисекунды.

Вот основные записи, у которых должен быть более длинный TTL:

MX-запись (указывает на ваш почтовый сервер)
DKIM и SPF (обычно настраиваются с записями MX)
TXT-запись

Записи, которые указывают на ваш веб-сервер или CDN, записи A и CNAME соответственно, обычно имеют более длительный срок жизни, поскольку они редко меняются. Для них вы можете установить TTL от 12 часов до 1 дня.

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

Читайте также: