Какой процент серверов имен соблюдает TTL в эти дни?

Несколько лет назад мне пришлось несколько раз менять DNS в течение нескольких недель, когда я перемещал части оборудования из одного центра обработки данных в другой. В то время, когда я делал это, около 95% серверов имен в мире, казалось, уважали значение TTL, и около 5% игнорировали наш и составляли свои собственные. Другими словами, 95% трафика перемещалось в пределах 15-минутного TTL, который мы определили. Еще 3% сделали это в первый час, 1% в первый день, а несколько отставших заняли три дня.

(Да, хорошо, я путаю процент трафика с процентом серверов имен. Пожалуйста, добавьте рукопожатие.)

Это было примерно в 2001 году, и мы использовали динозавров для передачи пакетов через трубки. Я предполагаю, что современные серверы имен ведут себя лучше, и у отставших проблем будет меньше. Кто-нибудь чувствует, какой процент трафика будет переключаться в пределах определенного TTL в эти дни? Много ли еще серверов имен, которые игнорируют TTL?

Мы переехали недавно, и у нас были всевозможные проблемы с DNS.

Когда мы сделали все возможное, большинство клиентов сразу начали использовать новые IP-адреса. Но некоторые все еще использовали старые IP-адреса в течение нескольких недель. Мы оставили сервер на месяц или около того. В конце концов, мы просмотрели журналы IIS на старой машине и позвонили заказчикам, чтобы они попросили сбросить DNS на DNS-серверах компании или ISP. Это заставило последнего из них переместиться.

Это было небольшое количество людей, которые сохранили старые 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).

Первый поиск возвращается:

• TTL 1 недели, для 3 из 50 точек измерения
• TTL 165 недель, для 47 из 50 точек измерения

Последовательный поиск возвращается (преобразуется в исходное значение TTL):

• TTL 1 недели, для 3 из 50 точек измерения
• TTL 2 недели, для 46 из 50 точек измерения
• TTL 165 недель, для 1 из 50 точек измерения

Второй тест (с использованием другого домена), где по умолчанию TTL установлен на 4 недели (= SOA + NS TTL), результаты ниже.

Первый поиск возвращается:

• TTL 1 недели, для 3 из 50 точек измерения
• TTL 2 недели, для 1 из 50 точек измерения
• TTL 165 недель, для 46 из 50 точек измерения

Возврат последовательных поисков (преобразуется в полную длину TTL):

• TTL 1 недели, для 3 из 50 точек измерения
• TTL 2 недели, для 47 из 50 точек измерения
• TTL 165 недель, для 0 из 50 точек измерения

Из наиболее известных / наиболее подключенных публичных служб распознавания:

• Общедоступный DNS Google [8.8.8.8 и 8.8.4.4] сокращен до 1 дня.
• UltraDNS [rdns (1 | 2) .ultradns.net] чтят полные 165 недель.
• Sprintlink [ns (1 | 2 | 3) .sprintlink.net] соблюдает полные 165 недель.

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

Похоже, в целом, TTL следует уважать. На 56% серверов, уполномоченных для доменов .com и .net , используется BIND, что, очевидно, хорошо соответствует стандартам. Cablevision / Optimum (по крайней мере, в Нью-Джерси), похоже, использует Nominum CNS, который также учитывает TTL.

Это не ответ на ваш вопрос конкретно; но, скорее, дополнительные вещи, которые следует учитывать, играют в ваше тестирование:

Цепные рекурсоры DNS и демоны кэширования

Это не просто ребра DNS-рекурсоров, которые кэшируют записи. Иногда люди связывают рекурсоры, и это добавляет время. Должно ли это быть сделано или нет, может быть длительное обсуждение, основанное на том, что люди пытались решить. Я видел 3 уровня рекурсии в дата-центре. Смешивание рекурсоров может иметь смешанные результаты, поскольку приращения TTL не всегда сохраняются. Некоторые операционные системы кешируют записи. Некоторые системы также используют такие вещи , как nscd, dnsmasqи другие методы , чтобы минимизировать влияние местных проблем recursor и снизить нагрузку на их recursors. Характеристики ОС различаются в зависимости от версии выпуска, демонов кэширования, версии демонов кэширования и т. Д.

[Править] Повторюсь, это не нормальное поведение рекурсора или демона кэширования. Я не собираюсь стыдить глючные, но один из них считается незатронутым, даже если он связан со многими дистрибутивами Linux.

DNS-кэш приложения

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

Конечные результаты могут быть искажены

Вышеуказанные предметы могут легко превратить 15-минутный TTL в 60+ минут или даже дольше.

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

Старый вопрос, но новые ответы (2017, 6 лет спустя):

1. Похоже, почти все мировые DNS-серверы обновляются за 5 минут
2. Google и OpenDNS позволяют вручную очищать записи DNS, ускоряя обновления распространения

Перед экспериментами ниже я ранее изменил свой TTL с 14400 (секунд = 4 часа) на 300 (секунд = 5 минут), но я сделал это за 2 часа до экспериментов, и так как предыдущий TTL был 4 часа, я не уверен, что мои изменения вышел бы, если бы у DNS-серверов не было своего собственного минимального TTL.

Мои эксперименты:

Эксперимент 1:

Я изменил преобразование имени в IP (запись A) на официальном сервере, а затем проверил:

• https://www.whatsmydns.net
• https://dnschecker.org

Через 5 минут (300 секунд) примерно половина глобальных серверов, проверенных этими сайтами, была обновлена.

Через 7 минут все было обновлено, кроме 1.

Эксперимент 2:

Google и OpenDNS позволяют вам вручную очищать их кеш DNS для определенного домена. Ссылки:

• Очистите запись DNS-кэша Google для вашего домена: https://developers.google.com/speed/public-dns/cache
• Промывать OpenDNS DNS записи кэша «ы для вашего домена: https://cachecheck.opendns.com/

Я обновил еще одну A-запись, а затем немедленно очистил кеш DNS от Google. У них есть капча, которая заставила меня «нажать на все квадраты со знаками» 3 раза, поэтому мне потребовалось 1-2 минуты, прежде чем я смог завершить сброс.

Через 4 минуты только 1 DNS-сервер, проверенный этими сайтами, имел старый IP-адрес. Все остальные были обновлены.

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

Однако, даже без флеш-памяти Google, кажется, что распространение происходит в минутах, а не в часах или днях.