DNS для тестировщиков

Как работает 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-записей #

Инструменты диагностики 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)

Продвинутое 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) должны быть в арсенале каждого тестировщика