Что такое домены?

Домен - это удобочитаемое имя для идентификации веб-сайтов в интернете. Вместо запоминания IP адресов (например, 142.250.185.78), мы используем доменные имена (google.com).

Зачем тестировщику знать про домены:

• Понимать, как работает маршрутизация запросов
• Диагностировать проблемы с доступностью сайтов
• Тестировать поддомены и различные окружения
• Анализировать проблемы с CDN и балансировкой нагрузки
• Понимать безопасность и SSL сертификаты

Структура доменного имени

Иерархия доменов

www.api.example.com.
│   │   │       │   │
│   │   │       │   └── Корневой домен (Root)
│   │   │       └────── Домен верхнего уровня (TLD)
│   │   └────────────── Домен второго уровня (SLD)  
│   └────────────────── Поддомен (Subdomain)
└────────────────────── Поддомен третьего уровня

Типы доменов верхнего уровня (TLD)

Общие TLD (gTLD):

.com    - коммерческие организации
.org    - некоммерческие организации  
.net    - сетевые ресурсы
.info   - информационные сайты
.biz    - бизнес сайты
.edu    - образовательные учреждения
.gov    - правительственные сайты

Национальные TLD (ccTLD):

.ru     - Россия
.uk     - Великобритания
.de     - Германия
.fr     - Франция
.jp     - Япония
.cn     - Китай

Новые TLD:

.tech   - технологические компании
.app    - мобильные приложения
.dev    - разработчики (только HTTPS)
.blog   - блоги
.shop   - интернет-магазины

DNS - система доменных имен

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

Пошаговый процесс разрешения домена:

1. Локальный кэш браузера

   Браузер проверяет: есть ли IP для example.com в кэше?
   Если да → использует сохраненный IP
   Если нет → переходит к следующему шагу
   

2. Кэш операционной системы

   ОС проверяет: есть ли IP в системном кэше?
   Также проверяется файл hosts
   

3. Рекурсивный DNS сервер (Resolver)

   Обычно DNS сервер провайдера (например, 8.8.8.8)
   Принимает запрос и выполняет поиск от имени клиента
   

4. Корневые DNS серверы

   Знают, где найти информацию о .com, .org, .ru и других TLD
   Отвечают: "За .com отвечают серверы a.gtld-servers.net"
   

5. TLD серверы

   Серверы .com знают, где найти информацию о example.com
   Отвечают: "За example.com отвечают ns1.example.com"
   

6. Авторитетные серверы домена

   Серверы example.com знают все записи для этого домена
   Отвечают: "www.example.com → 192.0.2.1"
   

Визуальная схема DNS запроса

[Браузер] → [Локальный кэш] → [DNS Resolver] → [Root] → [.com] → [example.com]
    ↓                                                                   ↑
[IP: 192.0.2.1] ←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←

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

A запись (Address)

Связывает домен с IPv4 адресом

example.com.        A       192.0.2.1
www.example.com.    A       192.0.2.1

AAAA запись (IPv6 Address)

Связывает домен с IPv6 адресом

example.com.        AAAA    2001:db8::1

CNAME запись (Canonical Name)

Создает псевдоним для другого домена

www.example.com.    CNAME   example.com.
blog.example.com.   CNAME   example.com.
api.example.com.    CNAME   server.hosting.com.

Важно: CNAME не может существовать с другими записями для того же имени

MX запись (Mail Exchange)

Указывает почтовые серверы для домена

example.com.    MX    10    mail1.example.com.
example.com.    MX    20    mail2.example.com.

Число (10, 20) - приоритет (меньше = выше приоритет)

NS запись (Name Server)

Указывает авторитетные DNS серверы для домена

example.com.    NS    ns1.example.com.
example.com.    NS    ns2.example.com.

TXT запись

Хранит произвольный текст, часто для верификации

example.com.    TXT    "v=spf1 include:_spf.google.com ~all"
example.com.    TXT    "google-site-verification=abc123..."

PTR запись (Pointer)

Обратный DNS - связывает IP с доменом

1.2.0.192.in-addr.arpa.    PTR    example.com.

SRV запись (Service)

Указывает расположение сервисов

_http._tcp.example.com.    SRV    10 5 80 server.example.com.

Инструменты для работы с DNS

Командная строка

Windows - nslookup:

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

# Запрос к конкретному DNS серверу
nslookup google.com 8.8.8.8

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

# Все записи
nslookup -type=ANY google.com

Linux/Mac - dig:

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

# Запрос к конкретному серверу
dig @8.8.8.8 google.com

# Конкретный тип записи
dig google.com MX
dig google.com AAAA
dig google.com TXT

# Все записи
dig google.com ANY

# Краткий вывод (только IP)
dig +short google.com

# Трассировка DNS запроса
dig +trace google.com

Linux/Mac - host:

# Базовый запрос
host google.com

# Все записи
host -a google.com

# Обратный DNS
host 8.8.8.8

Онлайн инструменты

DNS Checker (dnschecker.org):

• Проверка DNS записей с разных серверов по всему миру
• Полезно для проверки распространения изменений

DNS Lookup (dns.google):

• Интерфейс от Google для DNS запросов
• JSON API для автоматизации

What's My DNS (whatsmydns.net):

• Глобальная проверка DNS записей
• Карта распространения изменений

Время жизни (TTL) и кэширование

Что такое TTL

TTL (Time To Live) - время в секундах, сколько DNS запись должна храниться в кэше

example.com.    300    A    192.0.2.1
                │
                └── TTL = 300 секунд (5 минут)

Типичные значения TTL

300 секунд (5 минут)    - для часто изменяемых записей
3600 секунд (1 час)     - стандартное значение
86400 секунд (24 часа)  - для стабильных записей

Кэширование DNS

Уровни кэширования:

1. Браузер - обычно несколько минут
2. Операционная система - зависит от TTL
3. DNS resolver - зависит от TTL
4. CDN и прокси - могут иметь свой кэш

Очистка кэша:

# Windows
ipconfig /flushdns

# Mac
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux
sudo systemctl restart systemd-resolved
# или
sudo service networking restart

Поддомены и их использование

Типичные поддомены

www - основной сайт:

www.example.com → основной веб-сайт

api - API серверы:

api.example.com → REST API
v1.api.example.com → API версии 1
v2.api.example.com → API версии 2

cdn/static - статические ресурсы:

cdn.example.com → изображения, CSS, JS
static.example.com → статический контент
assets.example.com → ресурсы приложения

Окружения разработки:

dev.example.com → среда разработки
test.example.com → тестовая среда  
staging.example.com → предпродакшн среда
beta.example.com → бета версия

Сервисы:

mail.example.com → веб-почта
blog.example.com → блог
shop.example.com → интернет-магазин
support.example.com → служба поддержки

Wildcard DNS

Wildcard запись отвечает на любой поддомен:

*.example.com.    A    192.0.2.1

Это означает:

• anything.example.com → 192.0.2.1
• test123.example.com → 192.0.2.1
• whatever.example.com → 192.0.2.1

Проблемы DNS и их диагностика

Типичные проблемы

1. DNS не разрешается

Симптомы: "This site can't be reached", "DNS_PROBE_FINISHED_NXDOMAIN"

Диагностика:
dig example.com
nslookup example.com

Возможные причины:
- Домен не зарегистрирован
- Неправильные NS записи
- Проблемы с DNS серверами

2. Медленное разрешение DNS

Симптомы: Долгая загрузка страниц, таймауты

Диагностика:
dig +stats google.com
time nslookup google.com

Возможные причины:
- Медленные DNS серверы
- Высокий TTL при изменениях
- Проблемы сети до DNS серверов

3. Устаревшие DNS записи

Симптомы: Сайт открывается по-разному у разных пользователей

Диагностика:
dig +short example.com @8.8.8.8
dig +short example.com @1.1.1.1

Возможные причины:
- Недавние изменения DNS еще не распространились
- Различный TTL на разных серверах
- Кэширование на уровне провайдера

4. Конфликт записей

Симптомы: Неожиданные IP адреса, сайт ведет не туда

Диагностика:
dig example.com ANY
nslookup -type=ANY example.com

Возможные причины:
- Дублирующиеся A записи
- Неправильные CNAME
- Hijacking или DNS poisoning

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

DNS Propagation Checker:

# Проверка с разных DNS серверов
dig @8.8.8.8 example.com        # Google
dig @1.1.1.1 example.com        # Cloudflare  
dig @208.67.222.222 example.com # OpenDNS

Трассировка DNS:

dig +trace example.com

Проверка NS записей:

dig example.com NS
whois example.com

DNS в контексте тестирования

Тестирование поддоменов

Проверка доступности:

# Проверка основных поддоменов
for subdomain in www api cdn mail blog; do
    echo "Testing $subdomain.example.com"
    dig +short $subdomain.example.com
done

Автоматизированная проверка:

import dns.resolver
import requests

subdomains = ['www', 'api', 'cdn', 'mail']

for sub in subdomains:
    domain = f"{sub}.example.com"
    try:
        # DNS разрешение
        result = dns.resolver.resolve(domain, 'A')
        ip = result[0].to_text()
        
        # HTTP проверка
        response = requests.get(f"http://{domain}", timeout=5)
        print(f"{domain} → {ip} → HTTP {response.status_code}")
    except Exception as e:
        print(f"{domain} → ERROR: {e}")

Тестирование различных окружений

Сценарий тестирования:

1. Проверить DNS записи для всех окружений
2. Убедиться, что каждое окружение указывает на правильные серверы
3. Проверить SSL сертификаты для каждого поддомена
4. Тестировать переключение между окружениями

# Скрипт проверки окружений
environments=("dev" "test" "staging" "prod")

for env in "${environments[@]}"; do
    domain="$env.example.com"
    ip=$(dig +short $domain)
    
    echo "Environment: $env"
    echo "Domain: $domain"
    echo "IP: $ip"
    
    # Проверка доступности
    curl -I -s "https://$domain" | head -1
    echo "---"
done

Мониторинг DNS

Скрипт мониторинга:

#!/bin/bash
# dns_monitor.sh

DOMAIN="example.com"
EXPECTED_IP="192.0.2.1"
CURRENT_IP=$(dig +short $DOMAIN)

if [ "$CURRENT_IP" != "$EXPECTED_IP" ]; then
    echo "DNS ALERT: $DOMAIN resolved to $CURRENT_IP instead of $EXPECTED_IP"
    # Отправить уведомление
    curl -X POST "https://hooks.slack.com/..." \
         -d "{'text':'DNS changed for $DOMAIN'}"
fi

Безопасность DNS

DNS Hijacking

Что это: Злонамеренное перенаправление DNS запросов на поддельные серверы

Как обнаружить:

# Проверка с нескольких DNS серверов
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
dig @208.67.222.222 example.com

# Сравнение результатов
# Если IP адреса кардинально отличаются - возможен hijacking

DNS over HTTPS (DoH)

Что это: Шифрование DNS запросов через HTTPS для приватности

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

# curl с DoH
curl -H 'accept: application/dns-json' \
     'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

DNSSEC

Что это: Криптографическая защита DNS записей от подделки

Проверка DNSSEC:

dig +dnssec example.com
dig +cd +dnssec example.com

Производительность DNS

Оптимизация DNS

Выбор быстрых DNS серверов:

# Тестирование времени ответа
time dig @8.8.8.8 google.com
time dig @1.1.1.1 google.com
time dig @208.67.222.222 google.com

DNS Prefetching:

<!-- Предварительное разрешение DNS для внешних ресурсов -->
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//cdn.example.com">

Мониторинг производительности

Метрики для отслеживания:

• Время DNS разрешения
• Процент успешных DNS запросов
• Доступность DNS серверов
• TTL оптимизация

Практические советы для тестировщика

Чек-лист проверки DNS

□ Все поддомены разрешаются корректно
□ WWW и без WWW ведут на один сайт
□ DNS записи имеют разумный TTL
□ Нет конфликтующих A/CNAME записей
□ MX записи настроены для email
□ NS записи указывают на правильные серверы
□ Обратный DNS (PTR) настроен для IP адресов
□ DNSSEC включен и работает корректно

Автоматизация проверок

# Пример скрипта для регулярной проверки DNS
import dns.resolver
import time
import logging

def check_dns_records(domain, expected_records):
    results = {}
    
    for record_type, expected in expected_records.items():
        try:
            answers = dns.resolver.resolve(domain, record_type)
            actual = [str(rdata) for rdata in answers]
            results[record_type] = {
                'expected': expected,
                'actual': actual,
                'match': set(actual) == set(expected)
            }
        except Exception as e:
            results[record_type] = {'error': str(e)}
    
    return results

# Использование
expected = {
    'A': ['192.0.2.1'],
    'MX': ['10 mail.example.com.'],
    'TXT': ['v=spf1 include:_spf.google.com ~all']
}

results = check_dns_records('example.com', expected)

Заключение

Понимание DNS критически важно для тестировщика, поскольку:

• Многие проблемы с доступностью связаны с DNS
• Различные окружения часто используют разные поддомены
• DNS влияет на производительность приложений
• Безопасность приложений зависит от правильной настройки DNS

Регулярная проверка DNS записей должна быть частью процесса тестирования, особенно при изменениях инфраструктуры или переходе между окружениями.