Скільки триває поширення DNS і як його перевірити

Коли браузеру потрібен example.com, він запитує рекурсивний резолвер: вашого інтернет-провайдера, вашої компанії або публічний, як-от Google чи Cloudflare. Резолвер запитує авторитетні NS-сервери домену й кешує відповідь на стільки, скільки дозволяє TTL (time to live, час життя) запису. Доки ця закешована копія не застаріє, він віддаватиме стару відповідь, хоч би як нещодавно ви змінили запис.

Тож «поширення» — це просто тисячі кешів, які застарівають у різний час. Резолвер, що запитав ваш домен за секунду до зміни, тримає стару відповідь цілий TTL. Той, що ніколи його не запитував, одразу отримує нову відповідь. Ось чому друг бачить новий сайт, а ви ще бачите старий.

Цифра «від 24 до 48 годин», яку бачите всюди, походить від змін NS-серверів і з часів, коли довгі TTL були нормою. Після зміни A-запису з TTL 300 секунд майже всі бачать новий сервер за кілька хвилин.

• Ви знизили TTL надто пізно. Зниження TTL допомагає лише після того, як старий, довгий TTL застаріє в кешах. Знижуйте його за добу: див. Знизьте TTL перед перенесенням.
• Локальні кеші. Операційна система і браузер теж кешують DNS. Очистьте їх, перш ніж вирішувати, що поширення застрягло.
• Забутий запис. www досі вказує на старий сервер, або старий AAAA-запис (IPv6) і далі спрямовує туди відвідувачів з IPv6.
• CDN або проксі перед сайтом. Якщо перед сайтом стоїть Cloudflare чи інший проксі, відповідь DNS — це адреса CDN, і вона не змінюється. Змінювати треба налаштування origin у CDN, і Cloudflare застосовує його за секунди, тож поширюватися нічому: натомість перевірте новий сервер за допомогою посилання-превʼю.
• Резолвери, що тримають відповіді довше за TTL. Такі трапляються. Їх меншість, тому старий сервер і тримають увімкненим ще день-два після перемикання.

1. 1

   Крок 1: Переконайтеся, що зміна є на авторитетних NS-серверах

   Запитайте власні NS-сервери домену. Якщо вони досі повертають старе значення, запис не збережено, і чекання не допоможе.

2. 2

   Крок 2: Запитайте публічні резолвери по всьому світу

   Введіть домен і очікуване значення в перевірку поширення DNS, щоб побачити, які резолвери вже його повертають.

3. 3

   Крок 3: Перевірте кожне імʼя хоста і тип запису

   Повторіть для www, інших піддоменів і AAAA-записів. Забутий запис — найпоширеніша причина, чому зміна здається застряглою.

4. 4

   Крок 4: Очистьте власні кеші

   Очистьте кеш DNS операційної системи й перезапустіть браузер, перш ніж перевіряти сайт самостійно.

5. 5

   Крок 5: Переконайтеся, що сайт відповідає з нового сервера

   Скористайтеся інструментом Чи перемкнувся мій домен?, щоб перевірити, що домен резолвиться в новий IP і сайт там відповідає.

6. 6

   Крок 6: Отримуйте сповіщення замість оновлення сторінки

   Увімкніть сповіщення про поширення DNS для посилання-превʼю, і DNSPeek перевірятиме що кілька хвилин та надішле вам email, коли зміну буде завершено.

Запитайте конкретні публічні резолвери напряму. Число в розділі відповіді — це залишок TTL закешованої відповіді в секундах:

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @9.9.9.9 example.com A +noall +answer

Resolve-DnsName -Name example.com -Type A -Server 8.8.8.8
Resolve-DnsName -Name example.com -Type A -Server 1.1.1.1

Щоб побачити, що кажуть авторитетні NS-сервери без жодного кешу, запитайте їх напряму. Знайдіть їх командою dig NS example.com +short або за допомогою перевірки NS-серверів, а потім виконайте dig @ns1.your-dns-host.com example.com A. Якщо навіть авторитетна відповідь стара, зміну не збережено.

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Глобального перемикача, що спрацьовує в один момент, немає, тож виберіть правило. DNSPeek використовує таке: поширення завершено, коли щонайменше 90% публічних резолверів, які відповіли, повертають нове значення, і відповіла щонайменше половина всіх резолверів. Резолвери, що не відповіли вчасно, не враховуються, тож один недоступний резолвер вас не затримає. Найбільший TTL, який ще трапляється, показує, скільки може протриматися застарілий кеш. Коли нове значення — адреса Cloudflare, зараховується будь-яка адреса Cloudflare, бо Cloudflare видає кожному регіону власний edge-IP.

Безкоштовна перевірка поширення DNS застосовує це правило до 20 публічних резолверів, яких запитує сервер DNSPeek. У кабінеті посилання-превʼю може на вимогу перевірити 16 резолверів, а на платних тарифах DNSPeek може надіслати вам сповіщення email або вебхуком, коли поширення для домену завершиться, а потім повторно запустити ваш QA-звіт на робочому домені.

Бачити стару адресу від одного резолвера і нову від іншого — нормально посеред процесу. Кожен резолвер закешував запис у різний момент, тож і застаріває запис у кожного в різний момент. Великі публічні резолвери до того ж мають багато окремих кешів за однією адресою, тому два запити до того самого резолвера з різницею у хвилину можуть дати різні відповіді.

Хвилюватися варто, лише якщо співвідношення не змінюється. Якщо частка нових відповідей залишається тією самою довше за старий TTL, шукайте запис, який не змінили, другий набір NS-серверів, що досі обслуговує стару зону, або CDN, що відповідає за домен. Інструмент Порівняння DNS показує, чи повертають два NS-сервери різні записи.

Поширення викликає стрес лише тоді, коли новий сервер не перевірили заздалегідь. Якщо перед перемиканням ви відкрили сайт на новому IP за допомогою посилання-превʼю, період очікування означає лише те, що деякі відвідувачі трохи довше бачать стару копію. Тримайте на обох серверах однаковий вміст, уникайте змін вмісту на старому і переглядайте його журнали доступу: коли реальні відвідувачі перестануть приходити, його можна безпечно вимкнути.