Что происходит, когда ваш TTL облажался в вашей записи DNS?

Что происходит, когда кто-то получает доступ к вашему элементу управления DNS и устанавливает TTL 100 лет на вашем домене, указывая при этом свой IP на какой-то непонятный веб-сайт?

(и вы обнаружите это слишком поздно, конечно)

Райан дал отличный ответ на одну интерпретацию вашего вопроса. Однако, учитывая нашу целевую аудиторию и ситуацию, в которой люди могут наткнуться на этот вопрос, я собираюсь ответить на другой вопрос.

Что делает компания, когда плохой TTL выбегает на волю?

У вас есть несколько вариантов здесь. Прежде всего, вам нужно определить вектор проблемы и устранить его. Попытка сдержать ущерб бессмысленна, когда вы не можете контролировать повторение проблемы.

1. Подождите. Если это не важная запись, вы можете подождать. Как заметил Райан, «максимальный ущерб» составляет не 68 лет, а на практике, скорее всего, 7 дней. Это наиболее распространенное значение по умолчанию для максимального срока службы положительной записи в кэше (BIND, JunOS и т. Д.). Даже в тех случаях, когда это не так, можно надеяться, что сервер получает регулярные обновления безопасности, которые вызывают перезапуск процесса. Говоря как оператор нескольких крупных кластеров, я не считаю вероятным, что MSO намеренно установит это значение на большее: он служит только для генерации большего количества внешних запросов (которые мы ненавидим). Возможно, вам придется перейти к следующим шагам для компаний, использующих менее популярное программное обеспечение, или операторов, которые ненавидят себя.
2. Раздражают операторы кеша DNS. Если вам нужно очистить запись из кэша как можно скорее, ваш единственный реальный выбор - начать обращаться к крупнейшим поставщикам рекурсивных DNS, о которых вы можете подумать, и продолжить работу. Некоторые из этих компаний могут игнорировать вас: либо они думают, что ваша компания слишком мала, чтобы их клиенты могли о них заботиться, либо они устанавливают собственные политики очистки кэша, чтобы свести к минимуму количество обращений в службу поддержки, с которыми им приходится иметь дело. В последнем случае они, вероятно, пожмут плечами и позволят решить проблему в назначенное время. В конце концов, ваша компания создала эту проблему для себя.
3. Сделайте так, чтобы клиенты интернет-провайдеров раздражали своих интернет-провайдеров. Если прошло несколько дней, и крупный провайдер игнорирует кэшированную запись, попытайтесь заставить одного из своих клиентов подать жалобу и сгенерировать билет для этой компании. Их сложнее игнорировать, но это не принесет вам пользы с их командой ops, так как с их точки зрения вы сделали это для себя. Если это повторяется, они, вероятно, начнут аннулировать эти билеты просто из-за вас.
4. Посоветуйте своим партнерам обойти запись DNS. Если это критически важная запись DNS, используемая вашими партнерами, и ни один из перечисленных выше вариантов не является приемлемым (т. Е. Вы теряете доход за минуту), у вашей компании нет другого выбора, кроме как работать со своими партнерами, чтобы обойти проблему. Если они не контролируют свой локальный кэш, обычно это достигается путем вставки записей в таблицу хостов задействованных систем, поскольку это позволяет избежать необходимости изменять программы, использующие запись DNS. Это возможно только в том случае, если потеря дохода связана с несколькими избранными компаниями, потребляющими данные. Во всех остальных случаях вы застряли с первыми тремя вариантами.

Ну, во-первых, в руководстве по настройке Bind, которое я смотрю, говорится, что TTL - это 32-разрядное целое число со знаком, выраженное в секундах, что дает ему теоретический максимум 2 ^ 31. Это говорит

Допустимые значения TTL находятся в диапазоне 0-2147483647 секунд.

Или примерно 68 лет. Таким образом, вы, вероятно, не можете установить его на 100 лет в первую очередь.

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

Причина, по которой мы не можем поместить одно жесткое число в максимумы, заключается в том, что существует множество различных реализаций DNS, созданных многими разными поставщиками, и все они используют слегка разные переменные. Например, DNS-сервер, работающий на Juniper JunOS, будет работать в TTL только до 604800 секунд или 7 дней.