Как работает DNS

Система доменных имён (DNS) — это телефонная книга интернета: она переводит понятные человеку доменные имена (вроде api.example.com) в IP-адреса (вроде 93.184.216.34), которые компьютеры используют для связи. Каждый сетевой запрос вашего приложения начинается с DNS-запроса, что делает DNS основой всей сетевой коммуникации.

Процесс разрешения

Когда браузеру или тестовому инструменту нужно разрешить доменное имя, происходит каскад запросов:

  1. Кеш браузера: Браузер сначала проверяет собственный DNS-кеш (обычно 60 секунд)
  2. Кеш ОС: Проверяется кеш DNS-резолвера операционной системы
  3. Рекурсивный резолвер: Запрашивается DNS-сервер вашего провайдера или настроенный (Google 8.8.8.8 или Cloudflare 1.1.1.1)
  4. Корневой nameserver: Если у резолвера нет кешированного ответа, он спрашивает корневой сервер, который направляет к TLD-серверу
  5. TLD nameserver: Сервер .com, .org или .io направляет к авторитативному серверу домена
  6. Авторитативный nameserver: Возвращает фактическую DNS-запись с IP-адресом

Весь процесс обычно занимает 20-100мс, но может кешироваться на каждом уровне, сокращая последующие запросы практически до нуля.

Типы DNS-записей

ЗаписьНазначениеПример
AСопоставляет домен с IPv4-адресомexample.com → 93.184.216.34
AAAAСопоставляет домен с IPv6-адресомexample.com → 2606:2800:220:1:...
CNAMEПсевдоним другого доменаwww.example.com → example.com
MXПочтовый сервер доменаexample.com → mail.example.com
TXTТекстовые записи (SPF, DKIM, верификация)v=spf1 include:_spf.google.com
SRVРасположение сервиса (порт + хост)_sip._tcp.example.com → sip.example.com:5060
NSАвторитативные nameserversexample.com → ns1.cloudflare.com

Инструменты диагностики DNS

dig — Швейцарский нож DNS для QA-инженера 

# Базовый запрос
dig example.com

# Короткий вывод — только ответ
dig +short example.com

# Запрос конкретного типа записи
dig example.com AAAA
dig example.com MX
dig example.com TXT

# Отследить полный путь разрешения
dig +trace example.com

# Запросить конкретный DNS-сервер
dig @8.8.8.8 example.com

# Показать значения TTL
dig example.com | grep -A1 "ANSWER SECTION"

nslookup — Быстрый и кроссплатформенный 

# Базовый запрос
nslookup example.com

# Запросить конкретный сервер
nslookup example.com 8.8.8.8

# Запросить конкретный тип записи
nslookup -type=MX example.com

Проверка распространения по резолверам 

# Сравнить результаты по нескольким публичным DNS-серверам
dig @8.8.8.8 example.com +short      # Google
dig @1.1.1.1 example.com +short      # Cloudflare
dig @9.9.9.9 example.com +short      # Quad9
dig @208.67.222.222 example.com +short  # OpenDNS

Если разные резолверы возвращают разные IP-адреса, DNS-распространение ещё в процессе.

Сценарии DNS-тестирования

Маршрутизация окружений через файл hosts

Файл /etc/hosts (или C:\Windows\System32\drivers\etc\hosts на Windows) переопределяет DNS-разрешение локально. Это самая распространённая DNS-техника, которую используют QA-инженеры:

# Перенаправить продакшен-домен на staging-сервер
# Добавить в /etc/hosts:
10.0.1.50  api.example.com
10.0.1.50  www.example.com

Это позволяет тестировать поведение продакшен-домена на staging-сервере без изменений DNS-инфраструктуры. Браузер и все инструменты будут подключаться к указанному вами IP.

Тестирование, связанное с TTL

Перед любой миграцией DNS или деплоем, который изменяет DNS-записи:

  1. Проверьте текущий TTL: dig example.com | grep TTL — TTL 86400 (24 часа) означает, что старые записи сохраняются целый день
  2. Снизьте TTL перед миграцией: Уменьшите TTL до 300 (5 минут) минимум за 24 часа до изменения
  3. Мониторьте распространение: После изменения проверьте с нескольких резолверов, что новые записи активны

Тестирование DNS Failover

Многие приложения используют DNS-failover — когда основной сервер падает, DNS перенаправляет трафик на резервный. Тестируйте это:

  1. Проверяя наличие записей failover (несколько A-записей или DNS на основе health checks)
  2. Симулируя сбой основного сервера и подтверждая переключение DNS на резервный
  3. Измеряя время failover (зависит от TTL и интервалов health check)
graph LR B[Браузер] --> BC[Кеш браузера] BC --> OC[Кеш ОС] OC --> RR[Рекурсивный резолвер] RR --> Root[Корневой NS] Root --> TLD[TLD NS
.com .org .io] TLD --> Auth[Авторитативный NS] Auth --> IP[IP-адрес
93.184.216.34] IP -.-> RR RR -.-> OC OC -.-> BC BC -.-> B

Продвинутое DNS-тестирование

Обнаружение сервисов через DNS

В микросервисных архитектурах сервисы находят друг друга через DNS (особенно SRV-записи в Kubernetes). Тестирование включает:

  • Проверку, что SRV-записи возвращают корректные комбинации host:port
  • Тестирование времени регистрации/дерегистрации сервисов
  • Проверку, что клиенты корректно обрабатывают изменения DNS-записей

Тестирование GeoDNS

GeoDNS направляет пользователей к ближайшему серверу на основе географического расположения. Для тестирования из разных локаций:

# Использовать DNS-серверы в разных регионах
dig @dns-server-in-europe.example.com api.example.com +short
dig @dns-server-in-asia.example.com api.example.com +short

# Или использовать онлайн-инструменты: DNS Checker, whatsmydns.net

Валидация DNSSEC

DNSSEC добавляет криптографические подписи к DNS-записям, предотвращая подмену:

# Проверить статус DNSSEC
dig example.com +dnssec

# Проверить полную цепочку DNSSEC
dig +sigchase +trusted-key=. example.com

DNS over HTTPS (DoH)

Современные браузеры используют DNS over HTTPS, шифруя DNS-запросы. Это может влиять на поведение тестов:

  • DoH обходит локальные настройки DNS и файл hosts в некоторых конфигурациях
  • Корпоративные прокси могут не видеть DNS-запросы, влияя на мониторинг
  • Тестируйте с включённым и выключенным DoH для проверки одинакового поведения

Тестирование захвата субдоменов

Когда CNAME указывает на сервис, который больше не существует (например, удалённый S3-бакет или Heroku-приложение), атакующий может заявить права на этот сервис и раздавать вредоносный контент:

# Проверить зависшие CNAME
dig subdomain.example.com CNAME +short
# Если целевой сервис возвращает NXDOMAIN, он может быть уязвим

Практическое упражнение

Исследуйте DNS-конфигурацию выбранного сайта:

  1. Запросите все типы записей (A, AAAA, CNAME, MX, TXT, NS)
  2. Отследите полный путь разрешения с dig +trace
  3. Измените файл hosts для перенаправления домена на 127.0.0.1 и проверьте работу
  4. Проверьте значение TTL и рассчитайте, сколько времени займёт распространение DNS-изменения
  5. Сравните результаты разрешения на трёх разных резолверах
Подход к решению
# 1. Запросить все типы записей
DOMAIN="example.com"
for TYPE in A AAAA CNAME MX TXT NS; do
  echo "=== $TYPE ==="
  dig +short $DOMAIN $TYPE
done

# 2. Полный trace
dig +trace $DOMAIN

# 3. Перенаправление через hosts (требует sudo)
echo "127.0.0.1  $DOMAIN" | sudo tee -a /etc/hosts
curl $DOMAIN  # Должен отказать или подключиться к localhost
# Не забудьте удалить запись после тестирования!

# 4. Проверить TTL
dig $DOMAIN | grep -A5 "ANSWER SECTION"

# 5. Сравнить резолверы
for DNS in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo "=== $DNS ==="
  dig @$DNS +short $DOMAIN
done

Советы профессионала

  • Используйте /etc/hosts для перенаправления доменов на тестовые окружения без изменений DNS — это самый безопасный и быстрый подход для QA
  • Проверяйте DNS TTL перед деплоями — высокий TTL означает медленное переключение и потенциальные несоответствия в тестировании
  • Тестируйте с нескольких DNS-резолверов для обнаружения несоответствий распространения — разные пользователи могут разрешать разные серверы при переходах
  • DNS-кеширование может приводить к тому, что тесты проходят локально, но падают в CI — очищайте DNS-кеш при отладке (sudo dscacheutil -flushcache на macOS)
  • Мониторьте время DNS-разрешения — медленный DNS добавляет задержку к каждому запросу приложения

Ключевые выводы

  1. DNS — первый шаг в каждом сетевом запросе — сбои DNS влияют на всё последующее
  2. Файл hosts — лучший друг QA для маршрутизации тестового трафика без изменений инфраструктуры
  3. Осведомлённость о TTL критически важна при деплоях и миграциях окружений
  4. Инструменты диагностики DNS (dig, nslookup) должны быть в арсенале каждого тестировщика