System Design Space
Граф знанийНастройки

Обновлено: 23 июня 2026 г. в 08:31

Система доменных имен (DNS)

средний

Иерархия DNS-серверов, делегирование зон, кэширование, TTL и путь резолвинга от клиента до авторитетного сервера.

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

На практике она помогает видеть всю цепочку резолвинга: от локального и рекурсивного резолвера до TTL, устаревших записей и задержки распространения изменений, из-за которых проблема может жить в кэше, а не в приложении.

В интервью и архитектурных обсуждениях материал полезен тем, что делает видимым скрытый слой, через который проходят почти все внешние вызовы и на котором часто ломается устойчивость.

Практическая польза главы

Путь разрешения имен

Помогает разбирать цепочку резолвинга и понимать, где кэш действительно ускоряет систему, а где скрывает устаревшие ответы.

Риски доступности

Учит учитывать TTL, устаревшие записи и задержку распространения изменений при проектировании отказоустойчивости.

Глобальное поведение

Показывает, как решения на уровне DNS влияют на задержку, геораспределение и выбор маршрута до сервиса.

Сценарии на интервью

Усиливает ответы на кейсы, где точка отказа скрыта не в коде приложения, а в слое имен и кэшей.

RFC

RFC 1035 (DNS)

Базовая спецификация DNS: формат сообщений, типы записей, делегирование зон и поведение резолверов.

Перейти на сайт

— это интернета. Она связывает имена с адресами, ведёт запрос по цепочке делегирования, а через ответов решает, когда изменения дойдут до кэшей. Любая ошибка в этом контуре отдаётся не в одном сервисе, а сразу везде.

В цепочке участвуют , , и нередко для геораспределения узлов. Из-за этого Система доменных имён (DNS) одновременно задаёт и , и нагрузку в на авторитетные серверы, и характер с . Разбор такого инцидента без отдельной уходит не туда.

Ключевые свойства системы доменных имен

Иерархическое делегирование

Ответственность размазана по дереву: корневые серверы знают про домены верхнего уровня, те — про авторитетные серверы конкретной зоны. Никто не держит карту целиком, и это сознательное архитектурное решение.

Рекурсивное разрешение имен

Рекурсивный резолвер берёт обход цепочки делегирования на себя: собирает ссылки на следующую ступень и отдаёт клиенту уже готовый ответ. Клиенту не нужно знать, сколько прыжков ушло на этот ответ.

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

Кэш снимает нагрузку с авторитетных серверов и сокращает задержку — ценой того, что изменения доходят не мгновенно. На практике это значит: переключение записи всегда отложено на величину времени жизни.

Разные типы записей

A/AAAA, CNAME, NS, MX, TXT и другие записи описывают не только адрес, но и делегирование зон, маршрутизацию почты, проверку владения доменом. Большая часть инцидентов вокруг домена сводится к ошибке именно в типе записи, а не в самом адресе.

Критичный контур управления

Почти каждый внешний вызов начинается с резолвинга, поэтому отказ системы доменных имён (DNS) выглядит как массовый отказ всего сразу. Это редкая зависимость, у которой нет тихой деградации.

Как устроен заголовок сообщения системы доменных имён (DNS)

Счётчики в заголовке говорят, сколько в сообщении вопросов, ответов и дополнительных записей. От этих небольших полей зависит и поведение кэша, и размер ответа, и то, удержится ли запрос в протоколе UDP.

Базовый заголовок сообщения системы доменных имён (DNS)

12 байт + переменные секции

ID

16 бит

Flags

16 бит

QDCOUNT

16 бит

ANCOUNT

16 бит

NSCOUNT

16 бит

ARCOUNT

16 бит

Секция вопроса (переменная)

32 бит

Секции ответа, авторитета и дополнительных данных (переменные)

32 бит

Заголовок занимает фиксированные 12 байт, всё, что после, — переменной длины. Именно эти переменные секции и определяют, поместится ли ответ в один датаграммный пакет, как его закэшируют и не уйдёт ли запрос на протокол TCP.

Жизненный цикл запроса к системе доменных имён (DNS)

Запрос от клиента

Локальный резолвер не пытается решать задачу сам — он перекладывает её на рекурсивный резолвер: провайдерский, корпоративный или публичный.

Обход иерархии

Если ответа в кэше нет, рекурсивный резолвер идёт от корня к домену верхнего уровня и далее к авторитетному серверу зоны. Этот путь добавляется ко времени любого первого запроса до домена.

Ответ и кэширование

Ответ возвращается клиенту и оседает в кэше на время жизни записи. Дальше выигрывает не скорость сети, а размер кэша и его попадания.

Связанная глава

Модель OSI

Система доменных имён (DNS) относится к прикладному уровню и хорошо читается через диагностику по слоям.

Открыть главу

Иерархия серверов системы доменных имён (DNS)

Пространство имён — это дерево: корень, домены верхнего уровня, дальше конкретная зона. Авторитетные серверы знают истину про свою зону, рекурсивный резолвер держит свежий слепок ответа в кэше. Никакая сторона не знает систему целиком, и именно из-за этого она вообще работает.

Иерархия DNS-серверов

Выберите уровень, чтобы подсветить его роль в процессе резолвинга

Рекурсивный резолвер

Принимает запрос клиента, обходит иерархию и кэширует ответ

Корневые серверы

Направляют к нужному домену верхнего уровня

Серверы доменов верхнего уровня

Указывают, какой сервер отвечает за конкретную зону

Авторитетные серверы

Хранят итоговые записи домена и отвечают за зону

Корневые серверы и серверы доменов верхнего уровня передают ответственность вниз по иерархии.
Авторитетные серверы отвечают только за свою зону и ее записи.

Как происходит разрешение доменного имени

Рекурсивный резолвер стартует с известного списка корневых серверов и идёт по ссылкам — корень, домен верхнего уровня, авторитетный сервер зоны. Успешный ответ оседает в кэше на время жизни записи, и в этот момент дальше уже выигрывает не сеть, а удачное попадание в кэш.

Разрешение доменного имени

Запускайте шаги по одному или проигрывайте всю цепочку от клиента до авторитетного сервера

Текущий шаг

Нажмите «Запустить», чтобы пройти цепочку разрешения доменного имени.

Клиент
Рекурсивный резолвер
Корневые серверы
Серверы TLD
Авторитетный сервер

Кэш

И клиент, и рекурсивный резолвер держат недавние ответы в кэше, чтобы не обходить дерево при каждом запросе.

Маршрут резолвинга — это только половина картины. Вторая половина — динамика кэша: время жизни записей, доля попаданий и то, как нагрузка на авторитетные серверы растёт во время всплесков трафика и частых изменений.

Динамика DNS-кэша и времени резолвинга под нагрузкой

Пошагово смотрите, как TTL, доля попаданий в кэш и нагрузка на авторитетные серверы меняют время ответа.

ШагИнтервал 1 (1 из 6)
Попадания в кэш (%)Нагрузка на авторитетные серверы (%)Время резолвинга (мс)

Фаза

Тёплый кэш

Попадания в кэш

93.0%

Среднее время резолвинга

12 ms

Нагрузка на авторитетные серверы

0.8k QPS

NXDOMAIN

0.3%

TTL-политика: Стандартный TTL

Что происходит: Большинство запросов обслуживается из кэша рекурсивного резолвера, а авторитетная зона почти не нагружена.

Расшифровка обозначений

  • QPS (queries per second) — количество DNS-запросов в секунду.
  • NXDOMAIN — доменное имя не существует в DNS.

Что означают метрики

  • Доля запросов, обслуженных из кэша рекурсивного резолвера без полного обхода иерархии.
  • Среднее время полного DNS-резолвинга до получения ответа клиентом.

Связанная глава

Балансировка трафика

Система доменных имён (DNS) часто работает первым слоем выбора региона или площадки еще до балансировщиков L4/L7.

Открыть главу

Как сеть и маршрутизация меняют поведение системы доменных имён (DNS)

Промах кэша и лишние обходы

Промах кэша превращается в несколько лишних сетевых переходов до авторитетной зоны. Эта задержка не прячется за абстракцией протокола HTTP — пользователь видит её как медленный первый запрос.

Компромисс вокруг времени жизни (TTL)

Короткое время жизни ускоряет распространение изменений, но прямо пропорционально растёт число запросов в секунду (QPS) на авторитетные серверы и счёт за инфраструктуру. Точное значение — это всегда торг между скоростью и нагрузкой.

Эникаст и география

Глобально распределённые резолверы и авторитетные узлы убирают самые тяжёлые межконтинентальные обходы. На длинном хвосте это меняет 99-й перцентиль (p99) заметнее, чем оптимизация самого приложения.

Потери пакетов и переход на протокол TCP

Усечение ответа или потери пакетов отправляют часть запросов на протокол TCP, и тогда вместо одного датаграмного обмена получается полноценное рукопожатие. Время ответа и стоимость растут вместе.

Распределенная атака отказа в обслуживании (DDoS) и аномальный трафик

Без жёсткого ограничения частоты запросов всплеск ответов NXDOMAIN или усиливающая атака валит инфраструктуру системы доменных имён (DNS) быстрее, чем срабатывает любой пользовательский алерт.

Где система доменных имён (DNS) особенно важна

  • Обнаружение сервисов для клиентских и внутренних приложений
  • Выбор региона или площадки по географии, весам и сценарию переключения после отказа
  • Маршрутизация в сети доставки контента (CDN) и выбор ближайшей точки доставки
  • Подтверждение владения доменом и маршрутизация почты через MX, TXT, SPF и DKIM
  • Политики безопасности и фильтрации на уровне резолвера

Почему это важно для системного дизайна

  • Разрешение имени добавляет задержку ещё до первого сетевого запроса — и потому садится прямо в пользовательские p95 и 99-й перцентиль (p99).
  • Политика времени жизни (TTL) — это явный компромисс: скорость распространения изменений в обмен на нагрузку на авторитетную инфраструктуру.
  • Ошибки в конфигурации системы доменных имён (DNS) маскируются под проблемы приложения. Без отдельного слоя наблюдаемости разбор инцидента уходит не в ту сторону.
  • Грамотный дизайн системы доменных имён (DNS) сокращает радиус поражения инцидента и удерживает геораспределённую систему, когда падает один из регионов.

Частые ошибки

Выставлять слишком короткое время жизни (TTL) ради быстрых переключений и не считать, во что это превратится по нагрузке на авторитетные серверы в час пика.

Забывать про кэширование отрицательных ответов — и получать шторм повторных запросов по несуществующим именам.

Разбирать прикладной инцидент без отдельной наблюдаемости по попаданиям в кэш и времени резолвинга. Симптомы в приложении и причина в системе доменных имён (DNS) выглядят одинаково.

Держать систему доменных имён (DNS) у одного провайдера без запасного сценария: это скрытая единая точка отказа, которая всплывает только в инциденте.

Связанные главы

  • Модель OSI - показывает систему доменных имён (DNS) как прикладной протокол и помогает разбирать сетевые инциденты по слоям.
  • IPv4 и IPv6: эволюция IP-адресации - объясняет, как записи A/AAAA и свойства адресации влияют на выбор маршрута и стратегию публикации сервисов.
  • Протокол UDP - показывает, почему система доменных имён (DNS) по умолчанию идет по протоколу UDP и как потери пакетов влияют на время ответа.
  • Протокол TCP - объясняет, когда система доменных имён (DNS) переключается на протокол TCP, например при усечении ответа или переносе зоны.
  • Протокол HTTP - напоминает, что любой запрос по протоколу HTTP сначала упирается в разрешение имени — система доменных имён (DNS) отвечает раньше, чем само приложение.
  • Балансировка трафика - разбирает, как система доменных имён (DNS) работает первым слоем выбора региона или площадки еще до балансировщиков L4/L7.
  • Разбор кейса: инфраструктура сети доставки контента (CDN) - показывает практическую сторону глобальной маршрутизации через систему доменных имён (DNS) и сеть точек доставки.
  • Зачем нужны распределённые системы и консистентность - связывает решения в системе доменных имён (DNS) с отказоустойчивостью, распределением нагрузки и радиусом поражения инцидента.

Чтобы отмечать прохождение, включи трекинг в Настройки