Зачем все это вообще придумали
У любого устройства в сети есть свой IP-адрес. Это либо классический IPv4 — что-то вроде 192.0.2.1, либо более длинный IPv6, например, 2001:db8::1. По этим числовым меткам компьютеры и находят друг друга. Логично? Логично. Но представьте, что вам нужно держать в голове такие адреса для каждого сайта, на который вы ходите. Просто невозможно. Поэтому для людей придумали доменные имена — те самые понятные названия, которые легко запомнить и продиктовать.
Если объяснить, что такое DNS простыми словами, — это адресная книга интернета. Помните, как раньше у всех была записная книжка с телефонами? Захотел позвонить — нашел имя, набрал номер. Здесь то же самое, только вместо имени — название сайта, а вместо номера — IP-адрес. Не было бы DNS — пришлось бы помнить наизусть все «телефоны» интернета. Звучит как ад.
Хотя на самом деле задачи у системы давно шире, чем просто «перевод» имен в адреса. Сегодня DNS отвечает сразу за несколько вещей:
- помогает доставлять электронную почту;
- подтверждает права на домен, когда нужно выпустить SSL/TLS-сертификат;
- распределяет нагрузку между серверами;
- разводит пользователей по географии, чтобы каждый попадал на ближайший узел.
Как это работает, если разобрать пошагово
Чтобы понять, что такое DNS сервер простыми словами, проще всего посмотреть, что происходит, когда я открываю обычный сайт. Допустим, ввел www.example.com и жму Enter. Дальше события идут по такому сценарию:
- Сначала компьютер смотрит «у себя дома». Операционная система заглядывает в файл hosts и в кеш браузера. Если адрес уже там — отлично, дальше идти не надо.
- Если локально пусто — идем к резолверу. Это сервис на стороне провайдера. У него тоже есть свой кеш со свежими ответами от других пользователей.
- Если и у резолвера пусто — поднимаемся к корневым серверам. Они сами IP конкретного сайта не знают, зато подскажут, куда идти дальше — в нашем случае в зону .com.
- Следующий шаг — TLD-сервер. У него хранится информация о том, какие авторитативные серверы отвечают за example.com.
- Финал — авторитативный сервер. Именно у него есть та самая запись, где www.example.com сопоставлен конкретному IP.
- Возврат и кеширование. Резолвер отдает адрес браузеру и заодно сохраняет его у себя — чтобы в следующий раз не повторять весь маршрут заново.
Звучит, конечно, как целая экспедиция. Но в реальности все это укладывается буквально в несколько миллисекунд. Поэтому со стороны кажется, что сайт открывается без всяких посредников — хотя на самом деле под капотом успело пройти штук пять обращений к разным серверам.
Что за серверы вообще участвуют
В этой цепочке задействовано несколько типов узлов, и у каждого своя роль. Вместе они выстраиваются в иерархию — от общего к частному.
| Тип сервера | Чем занимается |
|---|---|
| Корневой | Самая верхушка. IP сайтов не возвращает, но подсказывает резолверу, к какому TLD-серверу обращаться |
| TLD-сервер | Отвечает за домены верхнего уровня — .ru, .com, .org, .рф и так далее. Знает, где лежат авторитативные серверы для доменов второго уровня |
| Авторитативный | Конечная точка. Хранит ресурсные записи конкретной зоны и выдает финальный IP |
Тут есть один любопытный момент. Логических корневых серверов в мире всего тринадцать — от a.root-servers.net до m.root-servers.net, и управляют ими двенадцать независимых организаций под общим присмотром ICANN. Звучит будто бы мало, но физических машин намного больше. За счет технологии Anycast по миру разбросано больше 1800 копий-зеркал, и несколько из них работают в России — в Москве, Санкт-Петербурге, Екатеринбурге, Новосибирске и Ростове-на-Дону.
С авторитативными серверами история похожая. Один сервер на весь домен — это слишком хрупко: упал — и сайт пропал. Поэтому их всегда дублируют. Первичный хранит эталонную копию зоны, а вторичные периодически с ним синхронизируются — это называется трансфером зоны. На запросы отвечают и те и другие, нагрузка распределяется, и единая точка отказа исчезает как класс.
Кто такой DNS-резолвер
Резолвер — пожалуй, самый трудолюбивый участник всей этой схемы. По-английски название звучит как DNS resolver, то есть буквально «тот, кто разрешает». Обычно резолвер живет на стороне интернет-провайдера или публичного сервиса. Знаменитые публичные адреса знают многие: у Google это 8.8.8.8, у Cloudflare — 1.1.1.1.
Что он делает? Принимает запрос от моего устройства, потом по очереди опрашивает корневые, TLD- и авторитативные серверы и в итоге возвращает финальный IP. А заодно складывает все, что узнал, в кеш — поэтому в следующий раз, когда я зайду на тот же сайт, ему не придется проходить весь путь заново. Грубо говоря, резолвер — это диспетчер, который берет на себя всю беготню, чтобы браузер мог быстро получить ответ и заняться своим делом.
Ресурсные записи и их типы
Вся информация внутри DNS лежит в виде ресурсных записей — Resource Records, или сокращенно RR. Каждая такая запись содержит имя домена, тип, класс сети, значение TTL и сами данные. Если задаться вопросом, что такое DNS сервер с прикладной точки зрения, то, по сути, это и есть хранилище таких записей плюс логика, которая отдает их по запросу. Типов записей много, но в реальной работе обычно крутятся вокруг небольшого набора.
| Тип | Назначение |
|---|---|
| A | IPv4-адрес домена |
| AAAA | IPv6-адрес домена |
| CNAME | Псевдоним, указывающий на другое каноническое имя; чаще всего используется для поддоменов |
| MX | Адреса почтовых серверов домена с указанием приоритета |
| NS | Авторитативные серверы зоны — основа делегирования |
| TXT | Произвольный текст; применяется для SPF, DKIM и подтверждения владения доменом |
| SOA | «Заголовок» зоны: первичный сервер, контакт администратора, серийный номер |
| SRV | Описание сетевых сервисов с указанием хоста и порта |
| PTR | Обратное соответствие IP → имя |
Через эти записи администраторы рулят маршрутизацией трафика, настраивают почту, выпускают сертификаты и решают кучу других задач, связанных с доменом. Со стороны список выглядит пугающим, но на практике в 90% случаев достаточно понимать три-четыре типа — A, MX, CNAME и TXT. Остальные нужны реже и обычно появляются в работе, когда возникает конкретная задача.
Чем DNS-зона отличается от домена
Все пространство доменных имен поделено на административные участки — DNS-зоны. За каждую такую зону кто-то отвечает: компания, частное лицо, иногда целая организация. Внутри зоны хранятся ресурсные записи — те самые, о которых говорилось выше.
Тут легко запутаться, поэтому два понятия лучше держать в голове отдельно:
- домен — это имя в иерархии, например company.com;
- зона — контейнер с записями, который относится к одному или нескольким доменам.
Пример. Допустим, у компании есть домен company.com, а у инженеров — свой поддомен engineering.company.com. Если вынести этот поддомен на отдельные серверы со своими записями, у него появится самостоятельная зона. В родительской при этом останутся только NS-записи — они скажут резолверу: «за этой веткой иди вон туда».
Кроме того, зоны делят по двум признакам. Прямые (Forward Lookup) превращают имя в IP — это привычный сценарий, с которым сталкиваются почти все. Обратные (Reverse Lookup) работают наоборот — по IP определяют имя, используя PTR-записи. Зоны еще бывают публичные, доступные всему интернету, и внутренние — такие используют только внутри корпоративных сетей.
Почему изменения в DNS видны не сразу
Параметр TTL (Time To Live, дословно «время жизни») определяет, сколько секунд резолверы по всему миру будут хранить ответ у себя в кеше. Звучит как мелкая техническая настройка, но именно от нее зависит, насколько быстро распространятся любые правки.
Покажу на примере. Допустим, у A-записи установлен TTL 86 400 секунд — это ровно сутки. Я меняю IP-адрес, а рекурсивные резолверы по всему миру еще целые сутки продолжают отдавать старый ответ. В итоге часть пользователей попадает на новый сайт, а часть — все еще на старый. Со стороны кажется, что DNS «тормозит», но на самом деле он просто отдает то, что у него уже лежит в кеше. Этот эффект часто называют «распространением DNS», хотя, по сути, речь именно о кешировании.
Что с этим делают на практике? Перед плановой миграцией опытные администраторы заранее уменьшают TTL у нужных записей — например, до 300 секунд. Тогда после переезда все обновится быстро. А когда работа стабилизировалась, TTL возвращают к обычному значению — иначе кеширование почти теряет смысл, и серверы получают лишнюю нагрузку.
Безопасность: что может пойти не так и как с этим жить
Раз DNS — фундамент почти всего, что работает в сети, неудивительно, что он часто становится мишенью. Последствия атак бывают разные: где-то сайт просто перестает открываться, а где-то пользователей тихо уводят на фишинговые ресурсы — внешне такие же, как настоящие.
| Угроза | Что происходит | Как защищаться |
|---|---|---|
| DDoS-атаки | Сервер заваливают запросами, ресурсы заканчиваются, обычные пользователи остаются без ответов | Anycast-сети, фильтрация трафика на периметре |
| Перехват запросов | Кто-то посередине читает и подменяет DNS-трафик между пользователем и резолвером | Шифрование транспорта — DoT (DNS over TLS) и DoH (DNS over HTTPS) |
| Отравление кеша | Поддельная запись пробирается в кеш резолвера, и легитимное имя начинает указывать на чужой IP | DNSSEC — проверка подлинности ответов цифровой подписью |
Чтобы понять, насколько все это серьезно, достаточно вспомнить случай октября 2002 года: тогда крупной DDoS-атаке подверглись 10 из 13 корневых серверов. Помимо описанных базовых мер, на практике применяют и более специфические штуки — uRPF (Unicast Reverse Path Forwarding) для отсечения подделанных пакетов, IP Source Guard для контроля DHCP-трафика, утилиту dns-validator, которая сравнивает запросы с ответами и тычет администратора в нос, если что-то не сходится.
Если коротко
DNS — это та самая невидимая инфраструктура, на которой держится почти весь привычный мне интернет. Каждый раз, когда я открываю сайт, проверяю почту или подключаюсь к облачному сервису, где-то в фоне срабатывает целая цепочка: резолвер, корневые серверы, TLD, авторитативные. И все это работает быстро благодаря распределенной архитектуре, иерархии зон, кешированию на разных уровнях и постоянно эволюционирующим механизмам защиты.
Принципы системы доменных имен пригодятся не только сетевым инженерам и админам. Понимать, как устроены ресурсные записи, что такое TTL и почему правки иногда применяются не моментально, полезно любому, у кого есть свой сайт. Это та самая разница между «у меня все сломалось, не понимаю, что делать» и «ага, кеш еще не обновился, подожду пару часов» — и она в какой-то момент может сильно облегчить жизнь.
