Вы вводите example.com и через долю секунды видите страницу. Кажется, просто. На самом деле браузер перед тем, как отправить хотя бы один байт HTTP-запроса, должен выяснить, на каком IP-адресе живёт сервер. Этим занимается DNS — система, которую часто описывают как «телефонную книгу интернета», хотя это сравнение давно устарело и скрывает кучу важных деталей.
DNS — это распределённая иерархическая база данных. Никакого единого сервера с «полным списком» не существует. Ответ на вопрос «где живёт example.com» собирается по цепочке из нескольких участников, каждый из которых отвечает только за свой кусок. Вот как это работает изнутри.
Шаг первый: локальный кэш и /etc/hosts
Прежде чем вообще куда-то идти, браузер смотрит в собственный кэш DNS. Если вы открывали example.com недавно и запись ещё не протухла — ответ уже есть локально, и никаких сетевых запросов не будет. Это быстро, бесплатно и работает большую часть времени при повторных визитах.
Если в кэше пусто, система смотрит в файл /etc/hosts (или его аналог на Windows). Именно поэтому старый хак «заблокировать рекламный домен через hosts» работает без всяких DNS-серверов — ОС просто не доходит до них.
Шаг второй: рекурсивный резолвер — главный посредник
Если локальных данных нет, запрос уходит на рекурсивный резолвер — это сервер, который ваш провайдер (или вы сами в настройках) указал как DNS. Чаще всего это 8.8.8.8 (Google), 1.1.1.1 (Cloudflare) или резолвер самого провайдера.
Рекурсивный резолвер — это и есть «умная голова» процесса. Именно он берёт на себя всю работу по обходу иерархии DNS и возвращает вам готовый ответ. Ваш компьютер при этом делает только один запрос: «Резолвер, что такое example.com?» — и ждёт.
У резолвера тоже есть кэш. Если кто-то другой уже спрашивал про example.com, резолвер отдаст закэшированный ответ мгновенно, не обращаясь никуда дальше. Это одна из причин, почему DNS работает глобально, не падая под нагрузкой.
Шаг третий: корневые серверы — вершина иерархии
Если резолвер не знает ответа, он идёт к корневым серверам. Их всего 13 логических адресов (обозначаются от A до M), но за каждым стоит не один физический сервер, а целый кластер — всего по всему миру их несколько сотен. Организация IANA публикует актуальный список операторов и адресов.
Корневые серверы не знают IP конкретных сайтов. Они знают только, кто отвечает за доменные зоны верхнего уровня: .com, .ru, .org и так далее. Резолвер спрашивает корень: «Кто отвечает за .com?» — и получает адрес TLD-сервера.
Шаг четвёртый: TLD-сервер и авторитативный nameserver
TLD-сервер (Top Level Domain) — следующий уровень иерархии. Для .com это серверы Verisign, для .ru — Координационного центра. Они не знают IP конкретных сайтов, но знают, на каком авторитативном nameserver зарегистрирован домен example.com.
Авторитативный nameserver — последняя инстанция. Именно на нём хранятся реальные DNS-записи: A-запись с IPv4-адресом, AAAA с IPv6, MX для почты, TXT для подтверждения домена и всё остальное. Этот сервер отвечает: «example.com — это 93.184.216.34» — и резолвер получает финальный ответ.
Весь этот путь — корневой сервер, TLD, авторитативный nameserver — называется итеративной резолюцией. Резолвер собирает ответ шаг за шагом, и в итоге возвращает его вашему браузеру. Обычно это занимает от 20 до 150 миллисекунд при первом запросе.
TTL: почему изменения в DNS не работают мгновенно
Каждая DNS-запись имеет параметр TTL (Time To Live) — время в секундах, сколько резолверы и клиенты могут держать её в кэше. Если TTL = 3600, ответ будет жить в кэше час. Всё это время серверы не будут перепрашивать авторитативный nameserver — просто отдадут то, что знают.
Это объясняет один из самых распространённых источников путаницы: вы поменяли A-запись у регистратора, но сайт всё равно открывается по старому адресу. Старый TTL ещё не истёк у части резолверов по всему миру. «Распространение DNS» — не магия, а просто ожидание протухания кэшей. Чем меньше TTL выставлен заранее, тем быстрее изменения дойдут до всех.
Есть и обратная история: слишком маленький TTL (5–60 секунд) заставляет резолверы постоянно ходить к авторитативному серверу, что создаёт нагрузку и увеличивает latency для конечных пользователей.
Негативный кэш и NXDOMAIN: когда домена не существует
Менее очевидная деталь: промахи тоже кэшируются. Если домен не существует, авторитативный сервер вернёт ответ NXDOMAIN (Non-Existent Domain), и резолвер закэширует этот «отрицательный» ответ на время, указанное в поле SOA-записи зоны (параметр minimum TTL). Это значит, что если вы опечатались в домене, а потом исправились — браузер всё равно может какое-то время возвращать «не найдено» из кэша.
Где DNS становится уязвимым местом
DNS исторически работает по UDP без шифрования. Запрос летит в открытом виде, ответ тоже. Это открывает путь для DNS-спуфинга: атакующий подделывает ответ резолверу, подсовывая фиктивный IP. Пользователь видит правильный адрес в строке браузера, но попадает на чужой сервер.
DNSSEC частично закрывает эту проблему: записи подписываются криптографически, и резолвер может проверить подлинность ответа. Но DNSSEC не шифрует трафик — только аутентифицирует. Мета-данные о том, какие домены вы запрашиваете, по-прежнему видны провайдеру и всем, кто сидит на пути пакета.
DNS over HTTPS (DoH) и DNS over TLS (DoT) решают именно эту проблему: запросы завёртываются в шифрованный канал. Провайдеры не в восторге от DoH — он уводит DNS-трафик из-под их контроля, в том числе делает сложнее блокировку доменов через DNS. Именно поэтому браузеры, активно внедряющие DoH по умолчанию, вызывают трения с регуляторами.
Что реально кэшируют браузеры — и это не всегда хорошо
Современные браузеры кэшируют DNS независимо от ОС. Chrome, например, держит свой отдельный DNS-кэш с собственными TTL, который иногда агрессивнее системного. Если что-то идёт не так с резолюцией — имеет смысл чистить кэш и там, и там. В Chrome это делается через chrome://net-internals/#dns.
Есть и другая крайность: некоторые провайдеры перехватывают DNS-запросы на уровне сети и не дают вам использовать сторонние резолверы. Вы прописали 1.1.1.1, но запросы всё равно уходят на сервер провайдера. Это называется transparent DNS proxy и встречается чаще, чем хотелось бы.
Практический итог
DNS — это многоуровневая система делегирования, где ни один участник не знает всего. Корень знает TLD, TLD знает nameserver домена, nameserver знает IP. Резолвер собирает цепочку за вас. Кэш на каждом уровне делает систему быстрой, но инертной к изменениям. Шифрование DNS — не параноя, а нормальная гигиена: без DoH или DoT ваши запросы открыты для наблюдения. Если хотите понять, почему у вас «не открывается сайт» или «не работает новый домен» — начинайте с TTL и состояния кэша, а не с перезагрузки роутера.
FAQ по DNS
Сколько времени занимает полная DNS-резолюция?
При первом обращении к домену — от 20 до 150 миллисекунд в зависимости от расположения серверов и загрузки сети. При попадании в кэш резолвера — единицы миллисекунд. При локальном кэше — меньше миллисекунды.
Почему изменение DNS-записи не применяется сразу?
Потому что старый ответ закэширован у резолверов по всему интернету на время, равное TTL записи. Дождитесь истечения TTL. Если заранее снизить TTL до минуты — переключение пройдёт намного быстрее.
Чем отличается рекурсивный резолвер от авторитативного nameserver?
Рекурсивный резолвер — посредник, который обходит иерархию и собирает ответ от имени клиента. Авторитативный nameserver — источник истины для конкретного домена; именно на нём хранятся A-, MX-, TXT- и другие записи.
Безопасен ли обычный DNS?
Нет. Классический DNS передаётся без шифрования по UDP, что делает его уязвимым к перехвату и спуфингу. DoH и DoT шифруют трафик. DNSSEC добавляет аутентификацию записей, но не шифрование.
Могу ли я использовать любой DNS-сервер, или провайдер всё равно перехватывает запросы?
Некоторые провайдеры используют transparent DNS proxy и перехватывают UDP-трафик на порт 53 независимо от ваших настроек. DoH обходит это, так как работает через HTTPS на порту 443 и неотличим от обычного веб-трафика.
Дисклеймер: использование альтернативных DNS-серверов и шифрованных протоколов (DoH, DoT) законно для целей приватности и безопасности. Вместе с тем обход блокировок, установленных в соответствии с законодательством Российской Федерации, может нарушать действующие правовые нормы. Пользователь самостоятельно несёт ответственность за соответствие своих действий применимому законодательству.
