# Перевірка DNS-зони: команди dig, dnsviz і розбір помилок

> Перевірка DNS-зони через dig показує реальну відповідь серверів ще до скарг користувачів на недоступність сайту чи пошти, а dnsviz знайде розриви DNSSEC.

## Навіщо перевіряти DNS-зону перед запуском

Перевірка DNS-зони — це не формальність, а спосіб побачити зону очима резолвера, а не панелі керування. Панель хостингу показує те, що записано в базі, а `dig` показує те, що реально віддають авторитативні сервери. Розбіжність між цими двома картинами — найчастіша причина «сайт не відкривається» і «листи не доходять» через добу після зміни налаштувань.

Перевірку варто робити у трьох випадках: одразу після [зміни записів](https://www.zevshost.net/uk/kb/kak-rabotat-dns/), після переїзду на нові [NS-сервери](https://www.zevshost.net/uk/kb/ns-servery-izmenit/) і перед публікацією будь-якого нового домену в проді.

## Команда 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 розходиться з тим, що ви бачите в панелі реєстратора, — це і є джерело проблеми: реєстр домену ще зберігає старі сервери, або навпаки, зона на нових серверах ще не піднята. Це особливо важливо після [делегування піддомену](https://www.zevshost.net/uk/kb/delegirovanie-poddomena/) на окремі 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 кеші.

---

Джерело: https://www.zevshost.net/uk/kb/proverka-dns-zony-dig/