Навіщо перевіряти DNS-зону перед запуском
Перевірка DNS-зони — це не формальність, а спосіб побачити зону очима резолвера, а не панелі керування. Панель хостингу показує те, що записано в базі, а dig показує те, що реально віддають авторитативні сервери. Розбіжність між цими двома картинами — найчастіша причина «сайт не відкривається» і «листи не доходять» через добу після зміни налаштувань.
Перевірку варто робити у трьох випадках: одразу після зміни записів, після переїзду на нові NS-сервери і перед публікацією будь-якого нового домену в проді.
Команда dig: як читати відповідь сервера
Базовий синтаксис: dig ІМ'Я ТИП. Щоб отримати A-запис домену, виконайте:
dig example.com A +shortПрапорець +short прибирає службовий вивід і залишає лише IP-адреси. Для повної картини з TTL, прапорцями та секцією AUTHORITY приберіть його:
dig example.com MXУ відповіді важливі три блоки: ANSWER SECTION — самі записи, AUTHORITY SECTION — які NS-сервери вважаються джерелом, і рядок flags: qr rd ra; — якщо в ньому немає ra (recursion available), сервер не резолвить рекурсивно і ви, ймовірно, спитали не той сервер.
Щоб спитати конкретний сервер напряму, оминаючи кеш локального резолвера, вкажіть його через @:
dig @8.8.8.8 example.com AЯк перевірити делегування і NS-сервери
Окрема перевірка потрібна для самого делегування — тобто для того, що батьківська зона (реєстр домену) знає про ваші NS-сервери. Команда:
dig example.com NS +traceПрапорець +trace проходить шлях від кореневих серверів до авторитативних, показуючи кожен крок делегування. Якщо на якомусь етапі список NS розходиться з тим, що ви бачите в панелі реєстратора, — це і є джерело проблеми: реєстр домену ще зберігає старі сервери, або навпаки, зона на нових серверах ще не піднята. Це особливо важливо після делегування піддомену на окремі NS.
Порівняйте відповідь на рівні батьківської зони і на рівні самих авторитативних серверів:
dig example.com NS @a.gtld-servers.net
dig example.com NS @ns1.example.comЯкщо списки не збігаються — синхронізація ще не завершена, чекайте або перевіряйте реєстратора.
dnsviz: візуальна перевірка ланцюга DNSSEC
Для DNSSEC одного dig замало — ланцюг довіри зручніше дивитися в dnsviz. Онлайн-версія будує граф зони і підсвічує розриви: відсутній DS-запис у батьківській зоні, прострочений підпис RRSIG або невідповідність алгоритму. Локально запустити перевірку можна так:
pip install dnsviz
dnsviz probe example.com | dnsviz printЧервоні вузли на графі — це конкретні помилки ланцюга: саме від них варто відштовхуватися під час діагностики, а не гадати заново.
Типові помилки під час перевірки зони
Більшість проблем укладаються в кілька повторюваних сценаріїв:
| Симптом у dig | Ймовірна причина |
|---|---|
| SERVFAIL на всі запити | Зламаний ланцюг DNSSEC або зона не відповідає |
| NXDOMAIN для наявного домену | Помилка в імені або зона ще не опублікована |
| Різні відповіді від різних NS | Записи не синхронізовані між серверами |
| Немає секції ANSWER, лише AUTHORITY | Запитано не той тип запису або делегування зламане |
Чек-лист перед публікацією домену
- Перевірте A, AAAA і MX через
dig +short— значення збігаються з панеллю. - Звірте NS через
dig NS +trace— батько і авторитативні сервери узгоджені. - Якщо увімкнено DNSSEC, проженіть домен через dnsviz і закрийте всі червоні вузли.
- Опитайте щонайменше два публічні резолвери (наприклад, 8.8.8.8 і 1.1.1.1), щоб виключити локальний кеш.
- Повторіть перевірку через 30–60 хвилин після змін — частина даних живе в TTL кеші.