Райан дал отличный ответ на одну интерпретацию вашего вопроса. Однако, учитывая нашу целевую аудиторию и ситуацию людей, которые, скорее всего, могут наткнуться на этот вопрос, я собираюсь ответить на другой вопрос.
Что делает компания, когда плохой TTL становится явным?
У вас есть несколько вариантов. Но в первую очередь необходимо определить вектор проблемы и устранить его. Пытаться сдержать ущерб бессмысленно, если вы не можете контролировать повторяющуюся проблему.
- Подождите. Если это не критическая запись, вы, вероятно, можете подождать. Как заметил Райан, «максимальный ущерб» составляет не 68 лет, а на практике, скорее всего, составляет 7 дней. Это наиболее распространенное значение по умолчанию для максимального срока жизни положительной записи в кэше (BIND, JunOS и т. Д.). Даже в тех случаях, когда это неточно, можно надеяться, что сервер получает регулярные обновления безопасности, которые вызывают перезапуск процесса. Выступая в качестве оператора нескольких больших кластеров, я не считаю вероятным, что MSO намеренно установит для него большее значение: оно служит только для генерации большего количества внешних запросов (что мы ненавидим). Возможно, вам придется перейти к следующим шагам для компаний, использующих менее популярное программное обеспечение, или операторов, которые ненавидят себя.
- Досадные операторы кеширования DNS. Если вам нужно как можно скорее очистить запись из кеша, ваш единственный реальный выбор - начать обращаться к крупнейшим поставщикам рекурсивных DNS, о которых вы только можете подумать, и работать дальше. Некоторые из этих компаний, вероятно, проигнорируют вас: либо они думают, что ваша компания слишком мала, чтобы о ней могли заботиться их клиенты, либо они вводят собственные политики очистки кеша, чтобы минимизировать количество обращений в службу поддержки, с которыми им приходится иметь дело. В последнем случае они, вероятно, пожмут плечами и позволят проблеме позаботиться о себе в назначенное время. В конце концов, ваша компания создала для себя эту проблему.
- Заставьте клиентов-провайдеров раздражать их за вас. Если прошло несколько дней, а крупный интернет-провайдер игнорирует кешированную запись, попробуйте заставить одного из его клиентов пожаловаться и сгенерировать внутренний запрос для этой компании. Им сложнее игнорировать это, но это не принесет вам никакой пользы в их команде операций, поскольку, с их точки зрения, вы сделали это сами. Если это повторится, они, вероятно, начнут отменять эти билеты просто назло вам.
- Посоветуйте своим партнерам обходить DNS-запись. Если это критически важная DNS-запись, используемая вашими партнерами, и ни один из вышеперечисленных вариантов не является приемлемым (то есть вы теряете доход каждую минуту), у вашей компании нет другого выбора, кроме как работать со своими партнерами, чтобы обойти проблему. Если они не контролируют свой локальный кеш, обычно это достигается путем вставки записей в таблицу хостов задействованных систем, поскольку это позволяет избежать необходимости изменять программы, использующие запись DNS. Это только жизнеспособным, если потеря доходов связана с некоторыми компаниями, потребляющими данные. Во всех остальных случаях вы застряли на первых трех вариантах.
Ну, во-первых, в руководстве по настройке Bind, которое я просматриваю, говорится, что TTL - это 32-битное целое число со знаком, выраженное в секундах, что дает теоретический максимум 2 ^ 31. Это говорит
Допустимые значения TTL находятся в диапазоне 0-2147483647 секунд.
Или примерно 68 лет. Так что вы, вероятно, не можете установить его на 100 лет.
Итак, допустим, вы установили 68 лет. Совершенно ясно, что произойдет. Преобразователи DNS, соблюдающие чрезвычайно длинный TTL ваших записей DNS, будут кэшировать их столько, сколько они могут. Некоторые преобразователи DNS вообще не соблюдают TTL и просто реализуют свою собственную политику кэширования по своему усмотрению.
Причина, по которой мы не можем указать единую точную цифру для максимальных значений, заключается в том, что существует множество различных реализаций DNS, созданных разными поставщиками, и все они используют несколько разные переменные. Например, DNS-сервер, работающий на Juniper JunOS, будет работать только до 604800 секунд или 7 дней по TTL.