Як перевірити поширення DNS

Звідки береться очікування

Уявіть ланцюжок, яким проходить пошук. Ваш пристрій запитує рекурсивний резолвер, що його веде ваш провайдер чи публічний сервіс. Якщо в цього резолвера є свіжа відповідь у кеші, він повертає закешовану, нікого більше не запитуючи. Лише коли кеш застаріває, резолвер спускається до кореневих серверів, реєстру домену верхнього рівня і, нарешті, до ваших авторитетних nameserver-ів, які й тримають запис, що ви редагували.

Тож коли ви змінюєте A-запис, нове значення існує тієї ж секунди, коли ваш DNS-провайдер його зберігає. Кожен резолвер, що досі тримає стару відповідь, продовжує її віддавати, поки не мине час його копії. TTL, time to live, - це число секунд, прикріплене до запису, яке каже резолверам, як довго його можна кешувати. Запис із TTL 3600 можна віддавати з кешу протягом години після отримання, тож година - це найгірший випадок для резолвера, який отримав його якраз перед вашою зміною.

Саме тому двоє людей в одному офісі можуть бачити різні результати, і саме тому очищення власного кешу нікому іншому не допомагає. Немає жодного глобального поширення, на яке варто чекати - лише багато незалежних таймерів, що спливають у різні моменти.

Як перевірити за кількома резолверами

Ручний спосіб - запитати кілька резолверів про одне й те саме та порівняти відповіді:

dig +short example.com @8.8.8.8      # Google Public DNS
dig +short example.com @1.1.1.1      # Cloudflare
dig +short example.com @9.9.9.9      # Quad9
dig +short example.com               # ваш власний резолвер
dig +short example.com @ns1.yourdns.example  # авторитетний: джерело істини

Авторитетний запит - найважливіший. Якщо він повертає нове значення, ваша зміна правильна й завершена, а все інше - лише питання кешування. Якщо він повертає старе значення, зміна не зберіглася, ви редагували не ту зону, або nameserver-и домену не ті, на які ви думаєте.

Щоб побачити не саме значення, а скільки лишилося кешу, приберіть +short і прочитайте колонку TTL:

dig example.com @8.8.8.8 | grep -A1 "ANSWER SECTION"

Число перед типом запису відлічує час, поки закешована копія старіє, і показує точно, скільки ще цей резолвер віддаватиме стару відповідь. У Windows nslookup example.com 8.8.8.8 робить те саме порівняння без додаткових інструментів. Вебінструмент DNS-пошуку, що запитує з багатьох локацій одночасно, виконує ту саму роботу швидше і заодно охоплює резолвери, до яких ви не можете дотягнутися з власної машини.

Чому це може тривати годинами

• Керує старий TTL, а не новий. Якщо запис мав TTL 86400 і ви занижуєте його разом зі зміною, резолвери, що закешували старий запис, усе одно мають право тримати його цілу добу. Зниження TTL допомагає лише наступній зміні.
• Деякі резолвери ігнорують короткі TTL. Низка провайдерів нав'язує власний мінімум, зазвичай годину чи більше, незалежно від того, що каже ваш запис.
• Зміни nameserver-ів повільніші. NS-записи на рівні реєстру часто мають TTL, виміряний днями, тож перехід на іншого DNS-провайдера справді може зайняти день-два, поки все всюди усталиться.
• Негативне кешування теж рахується. Якщо на момент запиту імені ще не існувало, відповідь "не існує" теж кешується - на період, заданий мінімальним полем SOA зони.
• Ланцюжки кешів. Браузер кешує DNS, операційна система кешує DNS, а корпоративний резолвер може стояти попереду публічного. Кожен рівень додає власну затримку.
• Довготривалі з'єднання. Застосунки, що розв'язали ім'я хоста один раз під час запуску, продовжують використовувати ту адресу, поки не перезапустяться, хоч би що зараз казав DNS.

Як зробити наступну зміну швидкою

1. Спершу знизьте TTL, потім зачекайте. Опустіть TTL запису до 300 секунд і залиште так щонайменше на час старого TTL, перш ніж робити справжню зміну. До того часу кожна закешована копія нестиме коротке значення.
2. Зробіть зміну. З TTL у 300 секунд більшість резолверів підхоплять її за п'ять хвилин.
3. Тримайте старий сервер відповідним під час перекриття. Не вимикайте його тієї ж миті, як DNS оновлено. Залиште його відповідати, поки трафік до нього не спаде, і міграція пройде непомітно для всіх.
4. Перевірте за авторитетними nameserver-ами й кількома публічними резолверами, перш ніж вважати справу завершеною.
5. Поверніть TTL назад, щойно зміна усталиться, щоб звичайний трафік знову вигравав від кешування.

Для зміни nameserver-ів обхідного шляху немає, бо TTL реєстру не вам налаштовувати. Плануйте день-два і тримайте обох DNS-провайдерів із однаковими записами протягом усього цього часу, щоб не мало значення, кого саме питає резолвер.

Після того, як зміна усталилася

Перевірка кількох резолверів вручну показує, наскільки далеко зміна поширилася на момент, коли ви дивитеся, що корисно під час міграції і марно решту часу. Варті уваги ті збої, що трапляються пізніше: запис, що змінюється непомітно для всіх, nameserver, що перестає відповідати, зона, термін дії якої закінчується. Безперервний моніторинг DNS запитує з багатьох локацій за розкладом і сповіщає, коли відповідь перестає відповідати очікуваній, що також ловить випадок "звідси працює, звідти ні", якого не побачить одноразовий пошук. Виконайте пошук просто зараз за допомогою інструмента DNS-запиту. Якщо сайт недоступний для вас, але в порядку деінде, далі допоможе посібник чи сайт лежить для всіх, чи тільки для мене.