Який відсоток серверів імен шанують TTL в ці дні?

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

(Так, гаразд, я плутаю відсоток трафіку з відсотком серверів імен. Будь-ласка, введіть рукоділля.)

Це було приблизно в 2001 році, і ми використовували динозаврів для передачі пакетів по трубках. Я здогадуюсь, що сьогоднішні сервіси імен краще поводяться, і проблем із страдниками буде менше. Хтось відчуває, який відсоток трафіку переключиться протягом визначеного TTL в ці дні? Чи є ще багато серверів імен, які ігнорують TTL?

Ми нещодавно переїхали і мали всілякі проблеми з DNS.

Коли ми зробили перегони, більшість клієнтів почали вражати нові IP-адреси відразу. Але деякі ще тижнями стикалися до старих ІС. Ми залишили сервер на місяць або близько того. Врешті-решт ми переглянули журнали IIS на старій машині та зателефонували клієнтам, які повідомили їм передати DNS на ту саму компанію чи ISP-сервери DNS. Ось останній з них перемістився.

Це була незначна кількість людей, які трималися зі старими ІС. З 20 тис. Клієнтів, можливо, у 50 були проблеми вже після першого дня.

(Дуже) великі тижні 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 точок вимірювання

З найвідоміших / найкраще підключених громадських служб дозволу:

• Загальнодоступні 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-серверів в Університеті $, де я працюю, які, здавалося, повністю знехтували TTL для кешованих запитів (і навіть не враховували значення TTL, яке вони призначали кешованому результату).

Здається, загалом TTL слід добре поважати. 56% серверів, авторитетних для .com та .net доменів, мають BIND, що, очевидно, добре відповідає стандартам. Кабельне / оптимальне (принаймні, у штаті Нью-Йорк), схоже, використовує 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 (запис) на авторитетному сервері, а потім перевірив:

• 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, схоже, розповсюдження відбувається за лічені хвилини, а не години чи дні.