Глава про DNS важна тем, что DNS в системе - это не справочник имен, а управляющий слой для маршрутизации, failover и распространения изменений через кэши.
На практике она помогает видеть всю цепочку resolution: зоны, делегирование, TTL, stale records и propagation delay, из-за которых проблема может жить не в приложении, а в имени и его кэшах.
В интервью и архитектурных обсуждениях материал полезен тем, что делает видимым одно из самых частых скрытых узких мест распределенных систем.
Практическая польза главы
Resolution path
Помогает разбирать цепочку резолвинга и видеть, где кэширование ускоряет или ломает ожидания.
Availability risks
Учит учитывать TTL, stale records и propagation delay при проектировании отказоустойчивости.
Global behavior
Показывает влияние DNS-решений на latency, геораспределение и балансировку трафика.
Interview scenarios
Усиливает ответы на кейсы, где точка отказа скрыта в DNS слое, а не в приложении.
RFC
RFC 1035 (DNS)
Классическая спецификация DNS: формат сообщений, типы записей и поведение резолвинга.
DNS - критический control plane интернета. Он сопоставляет имена и адреса, управляет делегированием зон, а через TTL и кэш напрямую влияет на latency, доступность и стоимость сетевой инфраструктуры.
Ключевые свойства DNS
Иерархическая модель
DNS разделяет ответственность по дереву root -> TLD -> authoritative зоны.
Рекурсивный резолвинг
Recursive resolver обходит иерархию DNS и возвращает готовый ответ клиенту.
TTL и кэш
Кэширование снижает latency и нагрузку на authoritative серверы, но усложняет rollout изменений.
Разные типы записей
A/AAAA, CNAME, NS, MX, TXT и другие записи формируют основу сетевой адресации сервисов.
Критичный control plane
DNS влияет на доступность почти всех внешних запросов: сбой резолвинга быстро становится инцидентом.
Визуализация содержимого DNS-сообщения
Формат DNS-заголовка и состав секций определяют поведение кэша, нагрузку на authoritative и transport overhead.
DNS Message Header
12 bytes + sectionsID
16 bits
Flags
16 bits
QDCOUNT
16 bits
ANCOUNT
16 bits
NSCOUNT
16 bits
ARCOUNT
16 bits
Question section (variable)
32 bits
Answer/Authority/Additional (variable)
32 bits
DNS header фиксированный (12 байт), далее идут variable секции вопроса и ответов. Размер и состав ответа влияют на транспорт и latency резолвинга.
Жизненный цикл DNS-запроса
Запрос от клиента
Stub resolver отправляет запрос на recursive resolver (обычно локальный DNS или публичный резолвер).
Рекурсивный обход иерархии
При cache miss resolver проходит root -> TLD -> authoritative, собирая referral и финальный ответ.
Ответ и кэширование
Результат возвращается клиенту и кэшируется по TTL для ускорения следующих lookup.
Связанная глава
Модель OSI
DNS относится к прикладному уровню OSI (Layer 7): он определяет логику резолвинга имен.
Иерархия DNS серверов
Пространство имён DNS представляет собой дерево: root → TLD → домен. Каждая зона обслуживается авторитетными серверами, а рекурсивный резолвер кэширует ответы. В модели OSI DNS работает на прикладном уровне (Layer 7).
Иерархия DNS серверов
Выберите уровень, чтобы подсветить его роль в системе
Recursive Resolver
Кэш и рекурсивные запросы
Root Name Servers
Делегирование к TLD
TLD Name Servers
.com, .org, .ru и др.
Authoritative Servers
Записи зоны домена
Интерактивный процесс resolve
Рекурсивный резолвер проходит по иерархии DNS серверов, получает референсы на авторитетные сервера и возвращает клиенту ответ, сохраняя его в кэше.
Resolve доменного имени
Нажмите на шаг или используйте кнопки для проигрывания
Active Step
Нажмите «Начать», чтобы запустить процесс разрешения доменного имени.
Cache
Ответы кэшируются у resolver и клиента, чтобы снизить задержку последующих запросов.
Динамика DNS-кэша и latency под нагрузкой
Пошагово смотрите, как TTL, cache hit ratio и authoritative нагрузка меняют время резолвинга.
Фаза
Тёплый кэш
Cache hit ratio
93.0%
Средний lookup
12 ms
Authoritative нагрузка
0.8k QPS
NXDOMAIN
0.3%
TTL-политика: Стандартный TTL
Что происходит: Большинство запросов обслуживаются из recursive cache, authoritative зона почти не нагружена.
Расшифровка обозначений
- QPS (queries per second) — количество DNS-запросов в секунду.
- NXDOMAIN — доменное имя не существует в DNS.
Что означают метрики
- Доля запросов, обслуженных из кэша recursive resolver без обхода иерархии.
- Среднее время полного DNS-резолвинга до получения ответа клиентом.
Связанная глава
Load Balancing
DNS часто используется как первый уровень traffic steering до L4/L7 балансировщиков.
Как сеть и маршрутизация меняют поведение DNS
Cache miss и latency
Каждый cache miss добавляет сетевые hop-ы до authoritative зоны и увеличивает user-visible delay.
TTL trade-off
Низкий TTL ускоряет rollout изменений, но растит QPS на authoritative и стоимость инфраструктуры.
Anycast и география
Распределение резолверов и authoritative узлов по регионам снижает lookup latency и tail spikes.
Packet loss/UDP fallback
Потери и truncation могут переключать часть запросов на TCP, увеличивая стоимость и время ответа.
DDoS и аномальный трафик
Всплески NXDOMAIN и amplification-атаки быстро перегружают DNS-инфраструктуру без rate limiting.
Где DNS особенно важен
- Service discovery для клиентских и серверных приложений
- Traffic steering (geo/latency routing, weighted failover)
- CDN маршрутизация и выбор ближайшей edge-точки
- Проверка владения доменом и email-маршрутизация (MX, TXT, SPF/DKIM)
- Политики безопасности и фильтрации на уровне резолвера
Почему это важно для System Design
- DNS lookup добавляет latency перед первым сетевым запросом и влияет на p95/p99 end-to-end метрики.
- TTL-политика напрямую определяет баланс между скоростью rollout и нагрузкой на authoritative инфраструктуру.
- Ошибки в DNS-конфигурации часто выглядят как “проблемы приложения”, поэтому нужен отдельный слой observability.
- Грамотный DNS-дизайн снижает blast radius инцидентов и повышает устойчивость multi-region систем.
Частые ошибки
Ставить слишком низкий TTL без расчёта нагрузки на authoritative инфраструктуру.
Не учитывать negative caching (NXDOMAIN) и получать лишний шторм повторных запросов.
Смешивать бизнес-инциденты и DNS-проблемы без отдельной observability по cache hit/lookup latency.
Игнорировать multi-provider или DR-стратегию для DNS и создавать единую точку отказа.
Связанные главы
- Модель OSI - позиционирует DNS как прикладной протокол и помогает диагностировать проблемы по слоям.
- IPv4 и IPv6: эволюция IP-адресации - A/AAAA записи и маршрутизация напрямую влияют на DNS-стратегию и доставку трафика.
- UDP протокол - базовый transport для DNS-запросов и причина, почему latency и потери так важны.
- TCP протокол - fallback для DNS в случаях truncation, zone transfer и сложных сетевых сценариев.
- HTTP протокол - каждый HTTP-запрос начинается с DNS lookup; ошибки резолвинга быстро бьют по SLA.
- Load Balancing - DNS-based routing и балансировка по регионам/весам перед L4/L7 уровнем.
- Разбор кейса: CDN инфраструктура - практика глобального traffic steering через DNS и edge-сети.
- Зачем нужны распределённые системы и консистентность - связь DNS-контроля с распределённой архитектурой и отказоустойчивостью.