DNS — это система, которая помогает браузеру найти нужный сайт по его имени. Когда вы вводите, например, thecode.media, DNS переводит это имя в IP-адрес сервера, на котором расположен сайт. Без этого интернет просто не работал бы: машины понимают только адреса типа 31.184.208.243, а не красивые имена.
В этой статье разберёмся, как устроена система DNS, как работает запрос к сайту, какие бывают DNS-серверы, зачем нужен кэш, где находятся корневые узлы и как DNS используют не только для связи, но и для атак.
Что такое DNS и для чего он нужен
DNS (Domain Name System) — это система, которая переводит понятные человеку адреса сайтов (например, ya.ru) в IP-адреса, понятные компьютерам адреса серверов, где эти сайты располагаются (77.88.44.242). Компьютеры работают только с цифрами, и без DNS нам с вами пришлось бы запоминать цифровые наборы вместо привычных названий.
С точки зрения пользователя всё выглядит просто: набрали адрес — сайт открылся. Но под капотом браузер запускает цепочку запросов по DNS-серверам, которые шаг за шагом находят нужный IP. По сути, DNS — это справочная служба интернета: вы называете имя — она отвечает точным адресом сервера, куда подключаться. Быстро, автоматически и незаметно.
Что такое DNS-сервер и какие они бывают
DNS-сервер хранит информацию о доменах и знает, какому IP-адресу какой сайт соответствует. Именно эти сервера обрабатывают миллиарды запросов ежедневно: вы вводите адрес сайта — они находят IP и возвращают его браузеру.
В интернете работает целая сеть таких серверов. У каждого своя задача: одни просто запоминают адреса, другие отвечают за конкретные зоны (например, .ru), а третьи передают запрос дальше, если не знают ответ.
Типы DNS-серверов
Всего есть 4 типа DNS-серверов.
Рекурсивный (резолвер) — получает запрос от браузера и берёт на себя всё остальное. Если не знает ответа, идёт по цепочке дальше: к корневым, TLD и авторитативным серверам. Похож на курьера, который доставляет результат пользователю.
Корневой сервер — самый первый в иерархии. Он не знает IP нужного сайта, но знает, к какому TLD-серверу, отвечающему за домены верхнего уровня (.com, .org, .ru и т. д.), нужно обратиться.
TLD-сервер (Top-Level Domain) — отвечает за домены верхнего уровня. Знает, где искать все .com, .net, .ru и т. д. Если он не знает, то никто не знает.
Авторитативный сервер — финал путешествия. У него хранится точная информация об IP-адресе сайта. Именно он в итоге и отвечает: «Вот нужный IP, подключайся».
Как работает DNS
DNS — это цепочка посредников, которая помогает браузеру найти нужный сайт. Когда вы вводите в адресной строке thecode.media, начинается серия запросов: от ближайших к вам серверов — до тех, кто точно знает, где находится этот сайт. И всё — за доли секунд.
Для примера можно привести такое: представьте, что вы работаете в офисе и вам нужно по работе связаться с Натальей, которая занимается оплатой хостинга. Но вы первый раз слышите и про Наталью, и про оплаты, поэтому дальше цепочка может быть такой:
- Вы идёте к своему руководителю и спрашиваете про Наталью, которая оплачивает хостинг, мол, как её найти?
- Руководитель её не знает, но знает Антона из технарей, который в курсе про хостинг (и, наверное, про оплату).
- Вы идёте к Антону, который вас отправляет к Сергею Геннадьевичу, главному айтишнику компании.
- Сергей Геннадьевич выслушивает вас, улыбается и говорит, что да, он её знает, вот её телефон, можно звонить.
Вот примерно так и работает DNS. А как это устроено технически — читайте дальше.
Принцип работы DNS
В общем виде схема выглядит так:
- Вы вводите в браузере thecode.media.
- Сначала система проверяет кэш: если нужный IP уже сохранён в браузере или в ОС — сразу идёт подключение к сайту.
- Если нет — запрос отправляется на рекурсивный DNS-сервер (например, от провайдера или Google DNS 8.8.8.8).
- Этот сервер обращается к корневому DNS-серверу, который отвечает: «Смотри в зоне .media».
- Дальше подключается TLD-сервер зоны .media и говорит, какой авторитативный сервер обслуживает thecode.media
- Наконец, авторитативный сервер отдаёт рекурсивному серверу точный IP сайта — и браузер подключается к нему напрямую.
👉 Кстати, вопрос про работу DNS часто задают на собеседованиях на позицию фронтенд-разработчика. Поэтому важно понимать, как устроен интернет и что именно происходит, когда браузер открывает сайт.
Дальше разберём подробно.
Резолвер и его роль
Резолвер (или DNS-рекурсор) — это тот, кто берёт на себя всю основную работу. Когда вы вводите адрес сайта, именно резолвер получает этот запрос от вашего устройства и начинает бегать по другим DNS-серверам, выясняя, где хранится нужный IP.
Он не хранит всю базу сам, а действует так: сначала спрашивает корневой сервер, потом TLD (например, .com или .ru), потом авторитативный. Когда получает ответ, то возвращает IP вашему браузеру — и сайт загружается.
Но тут есть важный момент: чтобы не бегать туда-сюда по серверам каждый раз, резолвер кэширует (то есть запоминает) полученный IP-адрес. Кэш может быть, например, на вашем устройстве — в браузере и в системе. Если вы уже заходили на сайт, то, скорее всего, нужный IP уже где-то лежит в памяти. Кэш может также храниться у вашего провайдера — его DNS-сервер тоже хранит ответы, чтобы быстрее отдать их другим пользователям. Ну а если мы внутри корпоративной сети, то там может быть свой резолвер с кэшем внутри компании.
Поэтому когда вы вводите сайт в адресной строке, система сначала проверяет:
- Есть ли IP в локальном кэше браузера? Если да — грузим сайт сразу.
- Нет? Проверяем системный DNS-кэш устройства.
- Тоже нет? Идём к DNS-серверу провайдера.
- Если и он не знает — тогда запускается вся цепочка: корневой → TLD → авторитативный.
У каждой записи в кэше есть TTL (Time to Live) — время жизни в секундах. После этого срока запись считается устаревшей и удаляется. Поэтому, если после смены IP сайт не открывается, дело, скорее всего, в устаревшем DNS-кэше — у вас или у провайдера. Обычно нужно просто подождать, но если срочно — можно вручную сбросить кэш (об этом чуть позже).
Корневой DNS-сервер и TLD-сервер
Когда резолвер получает запрос на thecode.media, то сначала стучится в корневой DNS-сервер. Тот не знает IP-адрес сайта, но знает, кто отвечает за зону .media, и отправляет резолвер к TLD-серверу (Top-Level Domain).
TLD-сервер уже обслуживает конкретную зону (например, .com, .ru, .media) и указывает, на каком авторитативном DNS-сервере лежит информация о домене thecode.media. То есть он не даёт сам IP, а говорит: «Вот адрес, где точно знают».
Авторитативный DNS-сервер
Авторитативный (authoritative) DNS-сервер — финальная точка цепочки запроса. Это сервер, который имеет всю официальную информацию о домене: где он живёт, где принимать почту и какие дополнительные настройки заданы. Вся эта информация хранится в виде DNS-записей — по сути, это просто структурированные строки, в которых указано, что и как связано с этим доменом. Самые важные из них:
- A-запись — основной IP-адрес сайта. Без неё браузер не сможет подключиться.
- AAAA-запись — то же, что и A-запись, но для IPv6-адресов. Используется, если сайт работает по протоколу IPv6.
- MX-запись — указывает, на какой сервер доставлять почту, если у домена есть email.
- TXT-запись — используется для технических целей: подтверждения владения доменом, настроек для почты и прочего.
- CNAME — если домен ссылается на другой (например, www.thecode.media → thecode.media).
- NS — указывает, какие DNS-серверы отвечают за этот домен.
- SOA — указывает основной DNS-сервер для домена, содержит дату последнего обновления и управляет параметрами зоны (включая TTL по умолчанию и интервал обновления для вторичных серверов).
Когда резолвер доходит до этого сервера, то получает нужную запись (чаще всего — A-запись) и возвращает её браузеру. Браузер берёт IP — и подключается к сайту. Всё, DNS-запрос завершён.
👉 Если у вас есть свой домен, все эти записи можно посмотреть и отредактировать в панели управления хостинга или у регистратора домена — например, в разделе «DNS-зоны» или «DNS-записи». Там же добавляются и верификационные записи для почты, сервисов и поддоменов.
Где находятся DNS-серверы
DNS-сервер — это не один суперсервер где-то в пустыне, а целая распределённая сеть, которая покрывает весь мир. Они есть у провайдеров, хостингов, крупных компаний типа Google и Cloudflare, а также у специальных организаций, которые поддерживают работу интернета.
Самые важные — корневые DNS-серверы. Всего их 13 (обозначаются буквами от A до M). Но это не значит, что они есть только в 13 экземплярах — у каждого из них есть десятки и сотни копий (реплик) по всему миру, чтобы справляться с нагрузкой и не упасть от одной атаки.
А вот где они расположены:
- США и Европа — большинство реплик (больше половины);
- Россия — есть копии F-root, K-root, L-root и других в Москве, Петербурге, Новосибирске, Екатеринбурге и Ростове-на-Дону;
- Азия, Южная Америка, Австралия, Африка — тоже есть, чтобы интернет везде работал стабильно.
Каждым сервером управляет своя независимая организация (иногда университет или фонд). Всё это координирует ICANN — международная некоммерческая организация, которая следит, чтобы в интернете был порядок с доменами и IP.
Когда вы отправляете DNS-запрос, он не уходит на какой-то один конкретный сервер в другой стране. Применяется технология Anycast, которая позволяет направить ваш запрос к ближайшей копии нужного сервера. Это ускоряет отклик, снижает нагрузку на сеть и повышает надёжность: если один сервер недоступен, запрос автоматически пойдёт к другому. И даже если случится сбой, DNS продолжит нормально работать.
Что происходит, если изменяется доменное имя или IP-адрес
Иногда домен меняет IP-адрес — например, сменили хостинг, перенесли инфраструктуру или передали сайт другому владельцу. В этом случае обновляются записи типа A или AAAA.
Но даже после обновления DNS-записей новые данные не распространяются мгновенно. Причина — кэш. И браузеры, и резолверы, и DNS-серверы ещё какое-то время могут хранить старый IP-адрес, чтобы ускорить повторные запросы. Это удобно, но может вызвать проблемы, если адрес уже изменился. В течение 24–48 часов (в зависимости от TTL в DNS-записях) пользователи могут видеть старую версию сайта или вообще не иметь к нему доступа. Пока кэш не обновится, будут использоваться устаревшие данные.
Если меняется доменное имя — был example.com, а стал example.org, — то технически это уже другой сайт. Нужно заново настраивать все DNS-записи, подключать SSL-сертификаты и обновлять ссылки. Старое имя перестанет работать, если не оставить редирект или прежние записи.
Если после смены IP сайт не открывается или грузится старая версия, то сработал DNS-кэш — в браузере, системе или роутере. Чтобы всё корректно заработало, можно сделать вот что:
- В Chrome перейти по адресу
chrome://net-internals/#dnsи нажать Clear host cache — это сбросит кэш браузера. - В ОС вручную выполнить команду для сброса DNS —
ipconfig /flushdnsдля Windows иsudo dscacheutil -flushcacheдля Linux/Mac. - Проверить текущий IP через
nslookup siteилиdig site— они покажут, какой адрес видит ваш DNS прямо сейчас.
Кэш обычно обновляется в течение 24–48 часов (в зависимости от TTL в DNS-записях), но если не хотите ждать, то чистим, перезагружаем и проверяем.
Защита DNS-серверов от атак
DNS — это один из самых уязвимых участков интернета. Если его взломают, вас могут отправить куда угодно: вместо сайта банка — на фейк, вместо госуслуг — на вирусную страницу. Поэтому DNS-серверы защищают от разных типов атак.
DNS spoofing, или отравление кэша
Это атака, при которой злоумышленник внедряет поддельную DNS-запись — то есть меняет соответствие между доменным именем и IP-адресом. Вы вроде ввели всё правильно — google.com, а в ответ получили IP фальшивого сайта, который внешне полностью копирует оригинал. Браузер не подозревает подмены, потому что доверяет DNS-серверу.
Хакер может «отравить» кэш DNS-сервера или резолвера, подкинув в него ложную информацию. И при следующем запросе других пользователей DNS-сервер вернёт уже поддельный IP.
Для защиты от спуфинга есть целый набор техник. Один из главных способов — DNSSEC. Это цифровая подпись DNS-записей, которая позволяет проверить, что данные пришли от реального авторитетного сервера, а не были заменены где-то по дороге.
Помогает и короткий TTL — если запись в кэше живёт недолго, даже если она окажется фейковой, долго она там не задержится. А регулярная очистка кэша (на клиенте и на серверах) вообще сводит риски к минимуму.
DDoS-атаки на DNS
При такой атаке злоумышленники закидывают DNS-сервер миллионами запросов, пока тот не падает. В этот момент сайты «исчезают» из интернета: вроде работают, но никто не может узнать их IP. Чтобы такого не случалось, используется технология Anycast — когда один и тот же IP-адрес обслуживается десятками серверов по миру и нагрузка распределяется.
Подмена через взлом роутера
Хакер может взломать ваш роутер и прописать свои DNS-сервера. В итоге даже при ручном вводе правильного адреса вы попадаете не туда. Решается всё просто: выключаете удалённый доступ к роутеру, чтобы нельзя было управлять настройками через интернет, ставите нормальный пароль (а не admin/admin) и вручную прописываете проверенные DNS типа 1.1.1.1 (Cloudflare) или 8.8.8.8 (Google).
Фальшивые точки Wi-Fi
Вы подключаетесь в кафе к какому-нибудь «Free_Coffee_WiFi», а самом на деле все запросы идут через злоумышленника. И DNS-запросы — тоже. Это значит, что, даже если вы набираете правильный адрес, злоумышленник может подменить ответ и отправить вас на фейковый сайт, не меняя ни буквы в URL.
Поэтому при работе в публичных сетях важно использовать VPN, а ещё лучше — подключить DNS-over-HTTPS (DoH) или DNS-over-TLS (DoT). Эти технологии шифруют не только контент, но и сами DNS-запросы, так что никто (ни провайдер, ни владелец точки Wi‑Fi) не узнает, какие сайты вы открываете.
Всё это можно настроить и на телефоне, и в браузере. Например, в Chrome в разделе «Конфиденциальность и безопасность» включаем тумблер в блоке «Безопасный DNS-сервер», а в качестве поставщика услуг прописываем Cloudflare (1.1.1.1) или Google (8.8.8.8):
Варианты использования DNS
Обычно DNS ассоциируют только с веб-сайтами — ввели в браузере адрес, DNS нашёл IP, и всё загрузилось. Но DNS — это ещё и универсальный механизм маршрутизации, без которого не работает ни один современный сервис.
Например, почта. Когда вы отправляете письмо на user@yandex.ru, именно DNS помогает понять, куда его доставить. Через MX-записи (Mail Exchange) он находит нужный почтовый сервер — и только потом начинается передача письма. Без DNS письмо просто бы зависло.
А ещё DNS используется в системах аутентификации. Многие сервисы (Google, GitHub и т. д.) просят добавить TXT-запись, чтобы подтвердить, что домен — действительно ваш. Это важно для защиты от фейков и фишинга.
Например, вас просит подтвердить, что вы владеете доменом. Для этого заходим в панель DNS своего хостинга и добавляем туда TXT-запись, которую вам выдал сервис:
Другой кейс — DNS-редиректы. Если вы набираете www.example.com, а в DNS указана CNAME-запись на example.com, то вас просто и незаметно перебрасывает. Это работает не на уровне HTML или JavaScript, а сразу на этапе разрешения имени.
Блокировки тоже работают через DNS. Когда сайт блокируют, то чаще всего провайдер просто убирает или подменяет нужную DNS-запись. И тогда сайт перестаёт «существовать» для обычных пользователей.
Ну и, конечно, DNS нужен в любой локальной сети. В офисе может быть локальный DNS-сервер, который позволяет обращаться к внутренним ресурсам не по IP, а по удобным именам — вроде crm.local или printer.office.
Короче, DNS — это не просто «вбил адрес и получил IP». Это фундамент коммуникации в интернете: от открытия сайта до доставки писем, авторизации сервисов и работы корпоративной инфраструктуры.
Вам слово
Приходите к нам в соцсети поделиться своим мнением о статье и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте — шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!
