Назад до блогу

Діагностика DNS: nslookup, dig, DoH

· 7 хв читання

Коротко: DNS-проблеми - одні з найчастіших і найважче діагностованих причин збоїв, бо «у мене DNS працює» не означає, що він працює для ваших клієнтів. Ось огляд практичних інструментів і процедур.

Коротко: DNS-проблеми - одні з найчастіших і найважче діагностованих причин збоїв, бо «у мене DNS працює» не означає, що він працює для ваших клієнтів. Ось огляд практичних інструментів і процедур.

Найчастіші проблеми DNS

  • Закінчилася реєстрація домену - весь DNS перестає працювати.
  • Невірний запис A/AAAA - після міграції сервера забули оновити.
  • Відсутній CNAME / MX - email не працює, при цьому сайт працює.
  • TTL не підготовлений до швидких змін - кеші провайдерів ще віддають старі дані.
  • Помилка DNSSEC - валідатори відхиляють непідписані або погано підписані записи.
  • Збій Geo-DNS - резолвер з певного регіону отримує невірну відповідь.

nslookup: найпростіша команда

Доступна в усіх ОС без встановлення. Використовує системний DNS-сервер за замовчуванням, але його можна явно вказати другим аргументом.

$ nslookup epulz.io
Server:    127.0.0.53
Address:   127.0.0.53#53

Non-authoritative answer:
Name:      epulz.io
Address:   87.197.115.180

# Явно використати Cloudflare DNS
$ nslookup epulz.io 1.1.1.1

# Конкретний тип запису
$ nslookup -type=MX gmail.com 8.8.8.8
$ nslookup -type=TXT _dmarc.epulz.io 1.1.1.1

dig: детальний DNS-запит для Unix

dig (Domain Information Groper) значно детальніший і гнучкіший. Частина пакета bind-utils або dnsutils.

$ dig epulz.io

;; QUESTION SECTION:
;epulz.io.                      IN      A

;; ANSWER SECTION:
epulz.io.               300     IN      A       87.197.115.180

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: ...

Ключові поля:

  • TTL (300) = секунди, на які резолвер може кешувати відповідь.
  • ANSWER SECTION = результат.
  • SERVER = який DNS-резолвер відповів.
  • Query time = тривалість - корисно при налагодженні повільного DNS.

Практичні команди

# Коротка відповідь (тільки IP)
$ dig +short epulz.io
87.197.115.180

# Усі записи
$ dig epulz.io ANY

# Трасування всієї DNS-ієрархії (від root-серверів)
$ dig +trace epulz.io

# Reverse lookup
$ dig -x 87.197.115.180

# Конкретний резолвер
$ dig @8.8.8.8 epulz.io
$ dig @1.1.1.1 epulz.io
$ dig @9.9.9.9 epulz.io

# Валідація DNSSEC
$ dig +dnssec epulz.io

DNS-over-HTTPS (DoH): коли немає UDP/53

У деяких мережах (корпоративні файрволи, мобільні дані з блокуваннями) традиційний DNS-порт 53 заблокований. DoH пакує DNS-запити в HTTPS-запити - проходять усюди, де працює 443.

# Endpoint DoH Cloudflare
$ curl -s "https://cloudflare-dns.com/dns-query?name=epulz.io&type=A" \
       -H "Accept: application/dns-json" | jq

# Google DoH
$ curl -s "https://dns.google/resolve?name=epulz.io&type=MX" | jq

Онлайн DoH-клієнт із приємним UI є й на - без встановлення.

Алгоритм при «домен не працює»

  1. Перевірте реєстрацію. whois yourdomain.com або через реєстратора. Якщо закінчилася, більше нічого виправити не можна.
  2. Перевірте NS-записи. dig NS yourdomain.com @8.8.8.8. Чи повертаються сервери імен, відповідальні за домен? Чи збігаються з тими, що в панелі реєстратора?
  3. Перевірте A-запис. dig yourdomain.com @8.8.8.8. Повертає правильний IP?
  4. Протестуйте із зовнішньої мережі (мобільні дані, VPN, онлайн-інструмент). У вас самих можуть бути кешовані старі дані.
  5. Перевірте TTL. Якщо тільки що змінили запис, зачекайте принаймні початковий TTL (за замовчуванням 1-24 години).
  6. Перевірте DNSSEC. Якщо використовуєте, ланцюг підписів може бути пошкоджений. dig +dnssec yourdomain.com покаже прапор ad при успіху.

DNS-поширення: скільки займає?

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

Практичні наслідки:

  • Плануєте міграцію? Знизьте TTL до 60-300 секунд принаймні за 48 годин.
  • Старий IP залишиться дійсним для деяких клієнтів ще довго після зміни. Не вимикайте старий сервер одразу.
  • Cloud-провайдери (Cloudflare, AWS Route 53) мають швидкий TTL і cache invalidation, але кінцевий клієнт все одно мусить чекати TTL свого резолвера.

Висновок

DNS - інфраструктурний клей, який усі приймають як даність, доки він не перестане працювати. Регулярний моніторинг DNS-записів (A, NS, MX, їх TTL та DNSSEC-валідація) виявить проблему до того, як клієнт повідомить про неї телефоном.

Моніторинг DNS та закінчення WHOIS

ePulz.io відстежує записи A/AAAA/MX/NS та закінчення реєстрації домену. 7 днів безкоштовно.

Запустити моніторинг →


Спробуйте ePulz.io безкоштовно - 7 днів без банківської картки.

Створити акаунт