Про DNS

Олег

13 июля 2026

DNS (Domain Name System) — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста, получения информации о маршрутизации почты и/или обслуживающих узлах для протоколов в домене.

Большинство людей думают, что DNS — это просто телефонная книга Интернета, которая превращает название сайта в цифровой адрес. Но на самом деле это гораздо более важная вещь, без которой ничего в сети не работает.

Доставка писем. Когда вы отправляете письмо на почту (@mail.ru), система не знает, куда его нести. Именно DNS подсказывает ей адрес почтового сервера, чтобы письмо не потерялось.

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

Бесшовные переадресации. Если вы вводите адрес с www, а вас перенаправляет на адрес без www — это тоже работа DNS. Она делает это на лету, еще до того, как страница начнет загружаться.

Инструмент блокировки. Когда какой-то сайт перестает открываться, скорее всего, провайдер просто выключает его в своей DNS-таблице. Для пользователя это выглядит так, будто сайт исчез из Интернета.

Удобство в офисе. Внутри компаний DNS помогает не запоминать сложные IP-адреса (например, 192.168.1.5), а обращаться к принтеру или внутреннему серверу по понятному имени, вроде printer.office.

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

Nginx Proxy Manager — настраиваем SSL для всех сайтов домашней лаборатории

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

Какие бывают DNS серверы

Есть 4 типа DNS-серверов.

1. Рекурсивный сервер (Recursive Resolver)

Это точка входа для клиентского запроса. Как правило, он разворачивается провайдером (ISP) или публичными сервисами (Google Public DNS, Cloudflare, OpenDNS). Он принимает рекурсивный запрос от клиента (stub resolver) и берёт на себя полный цикл разрешения имени. Резолвер последовательно опрашивает корневые, TLD и авторитативные серверы, кешируя промежуточные ответы согласно TTL (Time To Live).

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

2. Корневой сервер (Root Server)

Глобальная точка входа в иерархию. В мире существует 13 логических корневых зон, обозначаемых буквами от A до M, физически реализованных как сотни распределённых узлов (anycast-сети). Не содержит информации о конкретных доменах (кроме корневой зоны "."). Хранит только NS-записи (Name Server) для всех TLD-зон первого уровня (.com, .org, .ru, .net и т.д.).

На запрос о домене example.com корневой сервер вернёт список авторитативных серверов для зоны .com.

3. TLD-сервер (Top-Level Domain Server)

Отвечает за конкретную доменную зону верхнего уровня. Управляется регистраторами (например, Verisign для .com, RU-CENTER для .ru). Хранит информацию о делегировании доменов второго уровня в своей зоне. Содержит NS-записи для каждого зарегистрированного домена (например, для example.com указывает, на каких авторитативных NS-серверах хранится его зона).

TLD-сервер не знает IP-адрес конечного хоста (A/AAAA-записи), он только направляет запрос к нижестоящим авторитативным серверам.

4. Авторитативный сервер (Authoritative Name Server)

Конечный держатель эталонной DNS-информации для конкретной зоны (домена). Это сервер, который обслуживает непосредственно вашу DNS-зону. Содержит ресурсные записи (RR — Resource Records) всех типов: A, AAAA, MX, CNAME, TXT, SRV, NS, SOA и др. На запрос об A-записи example.com он возвращает точный IPv4-адрес (или NXDOMAIN, если записи нет).

Бывают первичные (Primary/Master — источник данных, где правятся зоны) и вторичные (Secondary/Slave — реплики для отказоустойчивости, получающие зону через AXFR/IXFR-трансферы).

Процесс публикации сайта

Чтобы опубликовать сайт, необходимо не просто залить файлы на хостинг, а корректно делегировать домен и настроить зону. Этапы:

Приобретение домена — вы регистрируете имя в регистраторе через реселлера.
Выбор хостинга — вы получаете от хостинг-провайдера выделенный IPv4/IPv6-адрес и, возможно, NS-серверы для обслуживания вашей зоны (или используете собственные).
Делегирование домена — в панели регистратора вы указываете, какие NS-серверы являются авторитативными для вашего домена. Эта информация сохраняется у регистратора и передаётся в TLD-зону.
Создание DNS-зоны — на вашем авторитативном NS-сервере создаётся конфигурация зоны. Минимально обязательные записи:
- SOA (Start of Authority) — содержит техническую информацию: серийный номер (обновляется при изменениях), время рефреша, ретрая, экспайра и TTL.
- NS-записи — указывают, какие серверы обслуживают эту зону (должны совпадать с делегированными).
- A-запись (или AAAA для IPv6) — привязывает имя хоста (например, @ для корня зоны или www) к IP-адресу сервера.
Распространение (Propagation) — после изменения TTL у старых кешей информация будет заменена в течение времени, указанного в SOA/записях. Резолверы по всему миру постепенно обновят кеш.

Если вы настраиваете recursive resolver, вы управляете кешированием, политиками блокировок (RPZ — Response Policy Zone) и производительностью (оптимизация очередей).

Если вы настраиваете authoritative server (например, на базе BIND, PowerDNS или NSD), вы управляете файлами зон, динамическими обновлениями (RFC 2136), подписью DNSSEC (RRSIG, NSEC/NSEC3) и политиками передачи зоны (ACL на AXFR).

Таким образом, публикация сайта технически сводится к добавлению ресурсной записи типа A/AAAA в авторитативную зону и корректному делегированию полномочий через вышестоящие иерархические уровни (TLD → Root). Без этого домен не будет резолвиться, и трафик не достигнет вашего сервера.

Если изменяется доменное имя или IP адрес

Изменение доменного имени или IP-адреса — это не атомарная операция в глобальной распределённой системе DNS. Это событие вызывает каскадный эффект, затрагивающий множество независимых компонентов инфраструктуры.

Изменение IP-адреса

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

Когда администратор переносит веб-сервис на новый хостинг или меняет сетевую топологию, он обновляет ресурсные записи типа A (для IPv4) или AAAA (для IPv6) в авторитативной зоне своего домена. Технически это выглядит как правка файла зоны с инкрементом серийного номера в SOA-записи, после чего вторичные NS-серверы забирают изменения через зонный трансфер (AXFR/IXFR).

Однако есть критическая задержка — проблема кеширования.

Инфраструктура DNS построена на многоуровневом кеше, и каждый элемент имеет собственную политику хранения полученных данных:

Stub-резолвер браузера. Встроенный кеш в Chrome, Firefox, Safari — хранит результаты DNS-запросов до 1–5 минут (не регулируется TTL), чтобы ускорить загрузку вкладок.
Операционная система. Системный кеш (в Windows — DNSCache, в Linux — nscd или systemd-resolved). Соблюдает TTL, но может применять минимальный порог (например, игнорировать TTL ниже 30 секунд).
Рекурсивный резолвер провайдера. Кеширует записи строго на время, указанное в TTL, полученном от авторитативного сервера. Может применять собственные ограничения сверху (максимальный TTL).
Прокси-серверы и CDN-сети. Могут кешировать не только IP, но и весь HTTP-ответ, что добавляет дополнительную задержку.

Таким образом, глобальная конвергенция (когда все резолверы мира начнут возвращать новый IP) занимает от нескольких минут до 48–72 часов. Ключевой метрикой здесь является TTL (Time To Live) — значение в секундах, указанное в SOA-записи и в каждой ресурсной записи отдельно.

Если TTL был задан как 86400 (сутки) — все кеширующие серверы обязаны хранить старый адрес сутки.
Если TTL был установлен в 300 (5 минут) — обновление произойдёт значительно быстрее, но увеличится нагрузка на авторитативные серверы из-за частых запросов.

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

Изменение доменного имени

Изменение доменного имени — это создание новой сущности в иерархии DNS, требующее полной перенастройки всей сопутствующей инфраструктуры (сертификаты, веб-серверы, почтовые записи), и не наследует параметры старого имени автоматически.

С технической точки зрения, доменное имя является ключом (primary key) в глобальной DNS-базе данных. При замене example.com на example.org создаётся новый объект, который не имеет никакого отношения к старому, за исключением совпадения контента на уровне приложения.

Что происходит при смене домена:

Старое имя (example.com) продолжает существовать в корневой и TLD-зонах, пока вы не прекратите его делегирование.
Для нового имени (example.org) требуется полный цикл регистрации — проверка доступности, заключение договора с регистратором, внесение в зону .org.
Все DNS-записи (A, AAAA, MX, CNAME, TXT, SRV) настраиваются заново для нового домена — они не переносятся автоматически.
SSL/TLS-сертификаты необходимо перевыпускать, так как они привязаны к конкретному FQDN (Fully Qualified Domain Name). Исключение — мультидоменные (SAN) сертификаты, куда можно добавить новый домен, но старый остаётся в поле subjectAltName.
HTTP-редиректы с старого имени на новое настраиваются на уровне веб-сервера (например, через директиву rewrite в Nginx или Redirect в Apache), либо через CNAME-запись, указывающую на новый домен (если нужно, чтобы старый адрес продолжал работать).

Сам по себе факт покупки нового домена не влияет на существующие кеши старого. Пользователи, перешедшие по закладкам на example.com, будут видеть либо старый IP (если он ещё активен), либо ошибку NXDOMAIN, если вы удалили зону.

Простая диагностика проблем после изменения IP

Если после смены IP сайт недоступен или открывается старая версия — это классический случай опережающего кеша. Для выявления актуального состояния сетевого стека используются следующие инструменты:

slookup domain.ru

Определяет, какой IP возвращает указанный DNS-сервер (по умолчанию — системный резолвер). Не показывает кеш ОС, только результат опроса внешнего сервера.

dig domain.ru A

Более детальный инструмент с выводом TTL, времени ответа и пути запроса (если включить +trace). Позволяет явно указать конкретный NS-сервер через @ns1.example.com.

ping domain.ru или tracert

Проверяет достижимость IP-адреса, но использует системный кеш, что может ввести в заблуждение. Показывает сетевую задержку, но не даёт информации о TTL записи.

curl -v https://domain.ru

Выполняет HTTP-запрос, показывая IP, с которым устанавливается соединение (через заголовок Connected to). Обходит браузерный кеш, но использует системный DNS.

DNS хайку

Методы принудительной инвалидации кеша

Если ожидание 24–48 часов критично, существует несколько способов сброса кеша на клиентской стороне (серверные кеши вы контролировать не можете, они обновляются только по истечении TTL).

На уровне браузера (Google Chrome):

Открыть chrome://net-internals/#dns
Нажать кнопку "Clear host cache" — это удаляет все DNS-записи, закешированные самим браузером (отдельно от системного кеша).
Дополнительно можно очистить сокет-пулы через chrome://net-internals/#sockets → "Flush socket pools", чтобы разорвать старые TCP-соединения.

На уровне операционной системы:

Windows. Очищает кеш DNS-резолвера (служба DNSCache).

ipconfig /flushdns

macOS (до 10.10). Сбрасывает кеш mDNSResponder.

sudo discoveryutil mdnsflushcache

macOS (10.10+). Очищает системный кеш и перезапускает демон.

sudo dscacheutil -flushcache + sudo killall -HUP mDNSResponder

Linux (systemd-resolved). Сбрасывает кеш через systemd-resolved.

sudo resolvectl flush-caches

Linux (nscd). Перезапускает кеширующий демон, что очищает его хранилище.

sudo /etc/init.d/nscd restart

Linux (dnsmasq). Перезапускает локальный DNS-прокси.

sudo systemctl restart dnsmasq

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

Сброс кеша на локальной машине — это временное решение для конкретного клиента. Единственный гарантированный способ заставить интернет увидеть новый адрес — это дождаться естественного обновления кешей, следуя закону TTL.

Стратегия подготовки к миграции

Чтобы минимизировать время недоступности при смене IP, инженерная практика рекомендует:

Заблаговременно снизить TTL — за 24–48 часов до миграции установить TTL для A-записи в 300 секунд. Это позволит старым кешам быстрее освободиться и принять новые данные.
Произвести миграцию в часы минимальной активности — чтобы снизить число пользователей, пострадавших от рассогласованности.
Сохранить старый IP активным — если есть возможность, поддерживать оба адреса в рабочем состоянии в течение переходного периода (например, настроить балансировщик, перенаправляющий часть трафика).
Использовать DNSSEC — хотя это не влияет на время кеширования, но гарантирует, что клиенты не получат поддельные ответы от промежуточных атакующих (например, при кешеотравлении).
Мониторить с разных географических точек, чтобы наблюдать за распространением нового IP в реальном времени. Можно использовать Интернет-сервисы.

Защита DNS-серверов

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

DNS Spoofing (Cache Poisoning) — отравление кэша

Атакующий внедряет в кэш рекурсивного резолвера фальшивую ресурсную запись (например, поддельный A-ответ для домена bank.com). В результате все пользователи, обслуживаемые этим резолвером, вместо реального IP получают адрес вредоносного сервера.

Методы защиты:

DNSSEC (Domain Name System Security Extensions) — механизм криптографической верификации, использующий асимметричное шифрование и цифровые подписи (RRSIG-записи). Резолвер проверяет цепочку доверия от корневой зоны до конкретного домена и отклоняет неподписанные или повреждённые ответы.
Короткий TTL — уменьшает время жизни фальшивой записи в кеше (например, до 60–300 секунд). Даже если подмена произошла, окно уязвимости будет минимальным.
Регулярная очистка кеша — как на клиентских машинах, так и на серверной стороне (особенно на рекурсивных резолверах в пределах управляемой сети).

DDoS-атаки на DNS-инфраструктуру

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

Метод защиты:

Anycast-маршрутизация. Технология, при которой один и тот же IP-адрес объявляется из множества географически распределённых точек присутствия (PoP). Запросы автоматически направляются к ближайшему активному узлу, благодаря чему нагрузка распределяется между десятками независимых серверов. Даже при выходе из строя одного узла маршрутизация переключается на следующий, что сохраняет доступность сервиса.

Компрометация клиентского роутера (атака на локальный DNS)

Взлом бытового маршрутизатора через дефолтные учётные данные (admin/admin) или уязвимости веб-интерфейса позволяет хакеру изменить параметры DHCP-сервера, раздающего клиентам адрес DNS-резолвера. В итоге все устройства в локальной сети начинают использовать вредоносный DNS, который подменяет ответы для любых доменов.

Метод защиты:

Отключение удалённого администрирования (доступа к веб-панели из внешней сети).
Смена заводского пароля на сложный (желательно с использованием генератора).
Принудительная установка статических DNS-серверов на клиентах (например, через групповые политики или вручную), игнорируя значения, выдаваемые по DHCP.
Использование проверенных публичных резолверов: 1.1.1.1 (Cloudflare) или 8.8.8.8 (Google).

Подмена DNS через фальшивые точки доступа (Rogue Access Points)

В общественных местах (кафе, аэропорты, торговые центры) атакующий может развернуть поддельную Wi-Fi-сеть с привлекательным названием. При подключении к такой сети трафик пользователя (включая DNS-запросы) проходит через прокси-сервер злоумышленника. Это позволяет перехватывать и модифицировать ответы DNS, перенаправляя пользователя на вредоносные ресурсы даже при условии, что он вводит абсолютно корректный домен.

Методы защиты:

Использование VPN-туннеля — весь трафик инкапсулируется в зашифрованный канал до вашего корпоративного или доверенного сервера, минуя локальный резолвер точки доступа.
DNS-over-HTTPS (DoH) — DNS-запросы передаются по протоколу HTTPS (порт 443), что делает их неотличимыми от обычного веб-трафика и защищает от перехвата и подмены.
DNS-over-TLS (DoT) — шифрование DNS-сессии поверх TLS (порт 853), гарантирующее конфиденциальность и целостность запросов на уровне транспорта.

Обе технологии (DoH/DoT) предотвращают перехват и модификацию DNS-запросов неавторизованными третьими лицами (включая провайдера и владельца точки доступа), так как резолвер устанавливает защищённое соединение с авторитативными источниками.

Заключение

DNS — это фундаментальная распределённая система, обеспечивающая не только преобразование доменных имён в IP-адреса, но и маршрутизацию почты, верификацию прав на домены, бесшовные переадресации и удобство управления сетевой инфраструктурой.

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

Безопасность DNS остаётся критической проблемой: спуфинг, DDoS, компрометация роутеров и фальшивые точки доступа — реальные угрозы. Их эффективно минимизируют DNSSEC, Anycast-маршрутизация и шифрование трафика через DoH/DoT.

Глубокое понимание механик DNS — от разрешения имён до защиты — является обязательным навыком для инженеров, работающих с сетевыми сервисами. Это знание позволяет строить стабильную, безопасную и доступную инфраструктуру в условиях, где без DNS интернет немыслим