Несколько лет назад мне пришлось внести несколько изменений в DNS в течение нескольких недель, когда я перемещал части оборудования из одного центра обработки данных в другой. В то время, когда я это сделал, около 95% серверов имен в мире, казалось, уважали значение TTL, а около 5% игнорировали наши и создавали свои собственные. Другими словами, 95% трафика прошло в течение 15-минутного TTL, который мы определили. Еще 3% сделали это в первый час, 1% - в первый день, а некоторым отставшим потребовалось до трех дней.
(Да, хорошо, я путаю процент трафика с процентом серверов имен. Пожалуйста, вставьте размахивание руками.)
Однако это было примерно в 2001 году, и мы использовали динозавров для передачи пакетов по трубкам. Я предполагаю, что сегодняшние серверы имен ведут себя лучше, и проблем с отставшими будет меньше. Кто-нибудь знает, какой процент трафика будет переключаться в пределах определенного TTL в наши дни? Есть ли еще много серверов имен, которые игнорируют TTL?
Мы недавно переехали, и у нас были разные проблемы с DNS.
Когда мы сделали это, большинство клиентов сразу же начали использовать новые IP-адреса. Но некоторые по-прежнему использовали старые IP-адреса в течение нескольких недель. Мы оставили сервер на месяц или около того. В конце концов мы просмотрели журналы IIS на старом компьютере и позвонили клиентам, сказав им очистить DNS на DNS-серверах компании или провайдера. Это привело к тому, что последний из них переехал.
Это было небольшое количество людей, которые сохранили старые IP-адреса. Из 20 тысяч клиентов примерно у 50 возникли проблемы после первого дня.
(Очень) длинные значения TTL, равные неделям, в мае 2011 г. соблюдались большинством DNS-серверов имен до 2 недель.
В тесте с использованием just-dnslookup.com, имеющего 50 глобально распределенных активных точек измерения, с TTL записи A, установленным на 99.999.999 = 165 недель (точно: 165 недель 2 дня 9 часов 46 минут 39 секунд) и TTL по умолчанию. от 2 недель (= SOA + NS TTL).
Первый поиск возвращает:
Последовательные поиски return (преобразованный в исходное значение TTL):
Результаты второго теста (с использованием другого домена), где TTL по умолчанию установлен на 4 недели (= SOA + NS TTL), приведены ниже.
Первый поиск возвращает:
Последовательные поиски return (преобразованный в полную длину TTL):
Из наиболее известных и подключаемых общедоступных резолверов:
Недавно я переместил DNS для нескольких доменов, на которых размещен мой личный сайт и сайты проектов, с GoDaddy на внутренний DNS (да, буквально мой дом). В целом, каждый сайт, к которому у меня есть удаленный доступ, соблюдает TTL и хорошо выполняет переход. Об этом же говорил каждый друг, которого я мог попросить проверить, как по стационарному, так и по мобильному телефону. По иронии судьбы, единственной проблемой были основные DNS-серверы кэширования в $ University, где я работаю, которые, казалось, полностью игнорировали TTL для кешированных запросов (и даже игнорировали значение TTL, которое они присваивали кешированному результату).
Похоже, что в целом TTL следует уважать. 56% серверов являются официальными для доменов .com и .net используют BIND, который, очевидно, хорошо соответствует стандартам. Cablevision / Optimum (по крайней мере, в Нью-Джерси), похоже, использует Nominum CNS, который также соблюдает TTL.
Старый вопрос, но новые ответы (2017 год, 6 лет спустя):
Перед экспериментами ниже я ранее изменил свой TTL с 14400 (секунды = 4 часа) на 300 (секунды = 5 минут), но я сделал это за 2 часа до экспериментов, и, поскольку предыдущий TTL составлял 4 часа, я не уверен, что изменил вышел бы, если бы DNS-серверы не имели собственного минимального TTL.
Мои эксперименты:
Эксперимент 1:
Я изменил преобразование имени в IP (запись A) на официальном сервере, затем проверил:
Через 5 минут (300 секунд) около половины глобальных серверов, проверенных этими сайтами, были обновлены.
Через 7 минут все было обновлено, кроме 1.
Эксперимент 2:
Google и OpenDNS позволяют вручную очищать кеш DNS для определенного домена. Ссылки:
Я обновил еще одну A-запись, а затем немедленно очистил кеш DNS Google. У них есть капча, которая заставила меня «щелкнуть по всем квадратам со знаками» 3 раза, так что мне потребовалось 1-2 минуты, прежде чем я смог завершить флеш.
Через 4 минуты только 1 DNS-сервер, проверенный этими сайтами, имел старый IP-адрес. Все остальные были обновлены.
Таким образом, очистка кеша DNS Google и принуждение его к повторному запросу авторитетного сервера, похоже, ускорило глобальное распространение DNS, возможно, за счет запуска обновлений кеша на всех мировых серверах.
Однако даже без промывки Google кажется, что распространение происходит в минутах, а не в часах или днях.
Это не ответ конкретно на ваш вопрос; скорее, дополнительные моменты, которые следует учитывать при тестировании:
Связанные DNS-рекурсоры и демоны кэширования
Записи кэшируют не только пограничные DNS-рекурсоры. Иногда люди связывают рекурсоры, и это добавляет времени. Стоит ли это делать или нет - это долгая дискуссия, основанная на том, что люди пытались решить. Я видел 3 уровня рекурсии в дата-центре. Смешение рекурсоров может давать неоднозначные результаты, так как уменьшение TTL не всегда сохраняется. Некоторые операционные системы кэшируют записи. Некоторые системы также используют такие вещи, как nscd, dnsmasq и другие методы, позволяющие минимизировать влияние проблем с локальными рекурсорами и снизить нагрузку на их рекурсоры. Характеристики ОС различаются в зависимости от версии выпуска, демонов кэширования, версии демонов кэширования и т. Д.
[ Редактировать ] Повторюсь, это ненормальное поведение демона рекурсора или кеширования. Я не собираюсь стыдить глючных, но один из них считается неподдерживаемым, хотя он входит в состав многих дистрибутивов Linux.
Кэш DNS приложений
Некоторые браузеры также кэшируют записи. Java и другие приложения также кешируют DNS. Иногда вы можете ограничить максимальный ttl в приложениях.
Конечные результаты могут быть искажены
Вышеупомянутые элементы могут легко превратить 15-минутный TTL в 60+ минут или даже дольше.
Вот почему я часто предлагаю приложениям или веб-сайтам учитывать наличие нескольких активных узлов в своей отказоустойчивой конструкции, чтобы клиент мог быстрее определять, когда одна точка входа на ваш сайт выходит из строя, и автоматически обрабатывать проблему в изящном и предсказуемом состоянии. , когда это возможно. Anycast - это один из методов, который некоторые компании используют, чтобы сделать переключение при отказе в некоторой степени прозрачным и не слишком сильно полагаться на изменения DNS. Есть также несколько умных методов балансировки нагрузки, которые можно сделать в javascript с использованием нескольких записей DNS.