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

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

Походит, в целом, TTL должен хорошо уважаться. 56% серверов, авторитетных для .com и доменов .NET, выполняют BIND, который, очевидно, играет хорошо со стандартами. Кабельное телевидение/Оптимум (по крайней мере, в NJ), кажется, использует Nominum CNS, который также уважает TTLs.

(Очень) длинные значения TTL недель в мае 2011 соблюдает большая часть DNS, разрешая серверы имен до 2 недель.

В тесте с помощью just-dnslookup.com, имея 50 глобальных распределенных активных точек измерения, с рекордный набор TTL к 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 имеющих размеры точек

От самого известного / лучше всего соединил общедоступные сервисы сопоставителя:

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

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

Связанные DNS-рекурсоры и демоны кэширования

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

[Edit] Повторюсь, это ненормальное поведение рекурсора или демона кэширования. Я не собираюсь позорить те, у которых есть ошибки, но один из них считается неподдерживаемым, хотя он входит в комплект многих дистрибутивов 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 на определенное время. ar домен. Ссылки:

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

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

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

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

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