Узнайте, как Пол Мокапетрис создал DNS, заменив громоздкие списки хостов на масштабируемую систему имён. Поясняем, как работает DNS, зачем нужно кеширование и основы безопасности.
Каждый раз, когда вы вводите веб‑адрес, нажимаете ссылку или отправляете письмо, вы полагаетесь на простую идею: людям должны быть доступны запоминающиеся имена, а компьютеры должны искать нужную машину.
DNS решает бытовую проблему: компьютеры общаются с помощью числовых адресов (IP‑адресов), например 203.0.113.42, но людям не хочется запоминать наборы цифр. Вы хотите помнить example.com, а не тот адрес, который использует сайт сегодня.
Система доменных имён (DNS) — это «адресная книга» интернета, которая переводит понятные человеку домены в IP‑адреса, используемые компьютерами для соединения.
На первый взгляд этот перевод выглядит незначительным, но он делает разницу между удобным интернетом и сетью, похожей на телефонную книгу, написанную одними только цифрами.
Это недетализированная экскурсия — без требований к знаниям сетей. Мы пройдём по:
По ходу знакомства вы встретите Пола Мокапетрisa — инженера, который разработал DNS в начале 1980‑х. Его работа важна потому, что он не просто придумал новый формат имён — он спроектировал систему, способную масштабироваться по мере того, как интернет вырос из небольшой исследовательской сети в ресурс для миллиардов людей.
Если у вас когда‑нибудь «падал» сайт, вы ждали, пока изменения домена «распространятся», или удивлялись, почему настройки почты требуют загадочные DNS‑записи, — вы уже видели DNS снаружи. Остальное — что происходит за кулисами — я объясню понятно и без жаргона.
Задолго до того, как кто‑то набирал знакомый веб‑адрес, в ранних сетях стояла более простая задача: как достучаться до конкретной машины? Компьютеры могли общаться через IP‑адреса (числа вроде 10.0.0.5), но людям нравились имена хостов — короткие метки вроде MIT-MC или SRI-NIC, которые было легче запомнить и передать.
В раннем ARPANET решением был единый общий файл под названием HOSTS.TXT. По сути это была таблица соответствий: список имён хостов и связанных с ними IP‑адресов.
Каждый компьютер хранил локальную копию этого файла. Если вы хотели подключиться по имени, система смотрела в HOSTS.TXT и находила соответствующий IP.
Это работало сначала, потому что сеть была небольшой, изменения были относительно редкими, и существовало понятное место для получения обновлений.
По мере присоединения всё большего числа организаций подход начал давать сбои:
Сердце проблемы — координация. HOSTS.TXT был как единый адресный справочник для всего мира. Если все зависят от одной книги, любое исправление требует глобального редактирования, и все должны быстро скачать самую новую версию. Как только сеть достигла определённого размера, модель «один файл для всего» стала слишком медленной, централизованной и ненадёжной.
DNS не отменил идею сопоставления имён с числами — он заменил хрупкий способ, которым это сопоставление поддерживалось и распространялось.
В начале 1980‑х интернет переходил от небольшой исследовательской сети к чему‑то большему и более разнородному. Подключалось всё больше машин, организации хотели автономии, и людям нужен был более удобный способ добираться до сервисов, чем запоминание числовых адресов.
Пол Мокапетрис, работая в этой среде, обычно считается автором дизайна DNS. Его вклад не был эффектным продуктом — это было инженерное решение практической задачи: как сохранить удобство имён при постоянном росте сети?
На первый взгляд система имён кажется простой, пока вы не представите себе, что «простая» означала тогда: один общий список имён, который каждый должен скачивать и обновлять. Такой подход ломается, как только изменения становятся постоянными. Каждая новая машина, переименование или исправление превращается в работу по координации для всех.
Главная идея Мокапетриса была в том, что имена — это не просто данные, это совместные договорённости. Если сеть растёт, система для создания и распространения этих договорённостей должна расти тоже — без того, чтобы каждый компьютер постоянно загружал мастер‑список.
DNS заменил идею «одного авторитетного файла» на распределённую конструкцию:
В этом и заключается тихая гениальность: DNS не был задуман как хитроумный механизм — он был спроектирован так, чтобы работать в реальных условиях: ограниченная пропускная способность, частые изменения, множество независимых администраторов и сеть, которая не собиралась останавливаться в росте.
DNS не был придуман как хитрое упрощение — его проектировали, чтобы решить конкретные практические проблемы, возникшие по мере роста раннего Интернета. Подход Мокапетриса состоял в том, чтобы сначала определить чёткие цели, а затем создать систему имён, которая выдержит десятилетия.
Ключевая концепция — делегирование: разные группы управляют разными частями дерева имён.
Например, одна организация управляет тем, что находится под .com, регистратор помогает зарезервировать example.com, а вы (или ваш DNS‑провайдер) управляете записями для www.example.com, mail.example.com и т.д. Это чисто разделяет ответственность, так что рост не создаёт узкого места.
DNS предполагает, что проблемы будут происходить — серверы падают, сети фрагментируются, маршруты меняются. Поэтому он опирается на несколько авторитетных серверов для домена и на кеширование в резолверах, чтобы временный сбой не ломал все запросы сразу.
DNS переводит понятные человеку имена в технические данные, наиболее известные — IP‑адреса. Он не «интернет сам по себе» — это служба именования и поиска, помогающая устройствам находить адреса, куда подключаться.
DNS делает имена управляемыми, организуя их как дерево. Вместо одного гигантского списка, где каждое имя должно быть уникальным глобально (и кто‑то должен это контролировать), DNS разбивает именование на уровни и делегирует ответственность.
DNS‑имя читается справа налево:
www.example.com. технически заканчивается точкой ..com, .org, .net, коды стран вроде .ukexample в example.comwww в www.example.comТак www.example.com разбивается на:
com (TLD)example (домен, зарегистрированный в .com)www (метка, которую владелец домена создаёт и контролирует)Структура уменьшает конфликты, потому что имена должны быть уникальны только в пределах родителя. Многие организации могут иметь поддомен www, потому что www.example.com и www.another-example.com не конфликтуют.
Это также распределяет нагрузку. Операторы .com не должны управлять записями каждого сайта; они лишь указывают, кто отвечает за example.com, а затем владелец example.com управляет деталями.
Зона — это просто управляемая часть дерева: набор DNS‑данных, за публикацию которых кто‑то отвечает. Для многих команд «наша зона» означает «DNS‑записи для example.com и поддоменов», хранящиеся на их авторитетных серверах.
Когда вы вводите имя сайта в браузере, вы не спрашиваете «интернет» напрямую. Несколько специализированных помощников разделяют работу, чтобы ответ нашли быстро и надёжно.
Вы (ваше устройство и браузер) начинаете с простого запроса: «Какой IP соответствует example.com?» Ваше устройство обычно ещё не знает ответа и не хочет опрашивать десятки серверов.
Рекурсивный резолвер выполняет поиск от вашего имени. Его обычно предоставляет ваш ISP, IT вашей организации или публичный резолвер. Главное преимущество: он может использовать кешированные ответы, ускоряя работу для всех, кто им пользуется.
Авторитетные DNS‑серверы — источник истины для домена. Они не «ищут» по интернету; они хранят официальные записи, указывающие, какие IP, почтовые серверы или токены верификации принадлежат домену.
example.com.Представьте, что рекурсивный резолвер — это библиотекарь, который может поискать для вас (и запомнить популярные ответы), а авторитетный сервер — официальный каталог издателя: он не просматривает другие каталоги, а просто сообщает, что верно для его книг.
Когда вы вводите example.com в браузере, браузеру на самом деле не нужно имя — ему нужен IP‑адрес (число вроде 93.184.216.34), чтобы знать, куда подключаться. DNS — это система «найди мне номер для этого имени».
Браузер сначала обращается к ОС вашего компьютера/телефона: «Мы знаем IP для example.com?» ОC проверяет свою краткосрочную память (кеш). Если там есть свежий ответ, запрос заканчивается.
Если ОС не знает ответа, она пересылает вопрос DNS‑резолверу — обычно от провайдера, организации или публичного провайдера. Резолвер действует как «консьерж по DNS»: он делает всю работу, чтобы ваше устройство не теряло время.
Если у резолвера нет ответа в кеше, он начинает направленный поиск:
.com). Root‑сервер не даёт финального IP — он возвращает направления: «Спросите эти .com‑серверы»..com): резолвер спрашивает сервера .com, где обрабатывается example.com. Опять же, не финальный IP — только направление: «Обратитесь к этому авторитетному серверу для example.com».A или AAAA) с IP‑адресом.Резолвер отправляет IP обратно вашей ОС, затем браузеру, который может подключиться. Большинство запросов ощущаются мгновенными, потому что резолверы и устройства кешируют ответы на период, заданный владельцем домена (TTL).
Последовательность: Браузер → ОС‑кеш → Резолвер‑кеш → Root (направление) → TLD (направление) → Авторитетный (ответ) → обратно к браузеру.
DNS казался бы мучительно медленным, если бы при каждом заходе на сайт пришлось заново начинать поиск и опрашивать несколько серверов. Вместо этого DNS опирается на кеширование — временную «память» недавних запросов — поэтому большинство пользователей получают ответы за миллисекунды.
Когда устройство спрашивает рекурсивный резолвер про example.com, резолверу может потребоваться время в первый раз. Узнав ответ, он сохраняет его в кеше. Следующий, кто спросит то же имя, получит ответ сразу.
Кеширование существует по двум причинам:
Каждая DNS‑запись отдаётся с значением TTL (Time To Live). TTL — это инструкция: храните этот ответ X секунд, затем отбросьте и спросите снова.
Если запись имеет TTL 300, резолверы могут использовать её до 5 минут, прежде чем обновить.
TTL — это баланс:
Если вы переносите сайт на нового хоста, меняете CDN или переключаете почту (меняете MX), TTL определяет, как быстро пользователи перестанут попадать в старое место.
Обычная практика — понизить TTL заранее перед запланированными изменениями, сделать переключение, затем снова поднять TTL, когда всё стабильно. Так DNS остаётся быстрым в обычной работе и не слишком «упрямится» после обновления.
В панели управления DNS вы в основном будете редактировать несколько типов записей. Каждая запись — небольшая инструкция о том, куда отправлять людей (веб), куда доставлять почту или как подтверждать владение.
| Запись | Что делает | Простой пример |
|---|---|---|
| A | Указывает имя на IPv4‑адрес | example.com → 203.0.113.10 (ваш веб‑сервер) |
| AAAA | Указывает имя на IPv6‑адрес | example.com → 2001:db8::10 (то же, новый адрес) |
| CNAME | Делает одно имя псевдонимом другого | www.example.com → example.com (оба идут в одно место) |
| MX | Говорит, куда доставлять почту для домена | example.com → mail.provider.com (приоритет 10) |
| TXT | Хранит «заметки», которые читают машины (верификация, политики почты) | example.com имеет SPF v=spf1 include:mailgun.org ~all |
| NS | Говорит, какие авторитетные сервера хостят DNS для зоны | example.com → ns1.dns-host.com |
| SOA | «Шапка» зоны: первичный NS, контакт администратора и тайминги | SOA example.com содержит ns1.dns-host.com и параметры retry/expire |
Несколько распространённых ошибок:
example.com). Многие провайдеры не разрешают это, потому что корневое имя должно нести записи типа NS и SOA. Если нужно «корень → хост», используйте A/AAAA или поддерживаемые провайдером ALIAS/ANAME.CNAME и A для одного и того же хоста (например, для www). Выберите один подход.mail.provider.com может сломать почту; пропущенные/лишние точки и неверное поле (например, @ вместо www) — частая причина простоев.Если вы готовите руководство для команды, небольшая таблица вроде приведённой выше в ваших документах или в runbook ускорит проверку и устранение неполадок.
DNS работает потому, что ответственность распределена между множеством организаций. Благодаря этому вы можете менять провайдеров, настраивать сервисы и поддерживать имя в сети, не спрашивая у «интернета» разрешения.
Регистрация домена — это покупка права использовать имя (например, example.com) на определённый период. Это похоже на резервирование ярлыка, чтобы никто другой не мог его занять.
Хостинг DNS — это управление настройками, которые говорят миру, куда указывает имя: сайт, почтовый провайдер, записи верификации и т.д. Вы можете регистрировать домен у одного провайдера, а хостить DNS у другого.
.com, .org, .uk). Она ведёт базу, кто владеет какими именами в этом TLD и какие name server‑ы за них отвечают.Root‑серверы стоят на вершине DNS. Они не знают IP вашего сайта и не хранят записи вашего домена. Их задача уже более узкая: они говорят резолверам, где искать авторитетные серверы для каждого TLD (куда обращаться за .com и т.п.).
Когда вы вноите name server‑ы для домена в настройках регистратора, вы создаёте делегирование. Реестр .com (через свои авторитетные серверы) затем будет направлять запросы для example.com на указанные вами name server‑ы.
С этого момента эти name server‑ы контролируют ответы, которые получает остальной интернет — пока вы снова не измените делегирование.
DNS основан на доверии: когда вы вводите имя, вы предполагаете, что ответ указывает на реальный сервис. В большинстве случаев так и есть, но DNS — популярная цель для атак, потому что небольшая смена «куда указывает имя» может перенаправить множество людей.
Классическая проблема — спуфинг или кеш‑отравление. Если злоумышленник обманет резолвер и заставит его сохранить фальшивый ответ, пользователи будут попадать на неправильный IP, даже если они ввели правильный домен. Это может привести к фишинговым страницам, загрузке вредоносного ПО или перехвату трафика.
Другая угроза — захват домена через регистратор. Если кто‑то получит доступ к вашей учётной записи у регистратора, он может сменить name server‑ы или DNS‑записи и фактически «захватить» домен, не трогая хостинг.
Ещё обычная проблема — неправильные настройки. Лишний CNAME, старая TXT‑запись или неверный MX могут нарушить логин‑флоу, доставку почты или проверки. Такие сбои часто выглядят как «интернет не работает», хотя причина — мелкая правка DNS.
DNSSEC добавляет криптографические подписи к DNS‑данным. Проще говоря: ответ DNS можно проверить, чтобы убедиться, что его не подменили в пути и что он действительно пришёл от авторитетного сервера домена. DNSSEC не шифрует запросы и не делает DNS анонимным, но он предотвращает многие виды поддельных ответов.
Традиционные DNS‑запросы легко наблюдать в сети. DNS‑over‑HTTPS (DoH) и DNS‑over‑TLS (DoT) шифруют соединение между вашим устройством и резолвером, уменьшая возможность подслушивания и некоторой степени вмешательства «по пути». Они не делают DNS полностью анонимным, но меняют, кто может видеть и модифицировать запросы.
Используйте MFA на аккаунте регистратора, включайте блокировки трансфера домена и ограничивайте, кто может править DNS. Относитесь к изменениям DNS как к релизу в продакшн: требуйте ревью, ведите журнал изменений и настраивайте мониторинг/оповещения на смену записей или name server‑ов, чтобы быстро узнавать о неожиданных изменениях.
DNS может казаться «настроил и забыл», пока какая‑то мелочь не выведет сайт или почту из строя. Хорошая новость: несколько привычек сделают управление предсказуемым даже для маленькой команды.
Начните с лёгкого и повторяемого процесса:
Большинство проблем с DNS несложны — их просто трудно заметить быстро.
Если вы часто деплоите приложения, DNS становится частью процесса релиза. Например, команды, которые разворачивают веб‑приложения на платформах вроде Koder.ai (где можно билдить и деплоить приложения через чат, а затем привязывать кастомные домены), всё равно опираются на те же принципы: корректные A/AAAA/CNAME‑цели, разумные TTL при переключениях и ясный путь отката при ошибочном указании адреса.
Если вы отправляете почту с домена, DNS напрямую влияет на то, попадут ли сообщения в почтовые ящики.
Дружелюбные человеку имена позволили интернету вырасти далеко за рамки маленького исследовательского сообщества. Относитесь к DNS как к общей инфраструктуре — немного внимания заранее сохранит сайт доступным и почту доверенной по мере роста.
DNS (Domain Name System) переводит дружелюбные для человека имена вроде example.com в IP‑адреса вроде 93.184.216.34, чтобы вашему устройству было понятно, куда подключаться.
Без DNS вам пришлось бы запоминать числовые адреса для каждого сайта и сервиса.
Ранние сети использовали единый общий файл (HOSTS.TXT), в котором сопоставлялись имена и IP‑адреса.
По мере роста сети такой подход стал неудобным: обновления требовались постоянно, имена конфликтовали, а устаревшие копии вызывали простои. DNS заменил «один глобальный файл» распределённой системой.
Пол Мокапетрис спроектировал DNS в начале 1980‑х, чтобы решить проблему масштабирования имён в быстро растущей сети.
Ключевая идея — делегирование: разделять ответственность между множеством организаций, чтобы ни один мастер‑список и один администратор не становились узким местом.
DNS‑имена иерархичны и читаются справа налево:
www.example.com..comexample.comwww.example.comЭта иерархия делает возможным делегирование и управление именами в глобальном масштабе.
Рекурсивный резолвер выполняет поиск ответов от имени клиента и кеширует их (обычно это провайдер интернет‑услуг, корпоративный или публичный резолвер).
Авторитетный DNS‑сервер — это источник истины для зоны: он не ищет по интернету, а отвечает за свои записи.
Типичный запрос проходит так:
.com) → авторитетные серверы домена.A/AAAA).TTL (Time To Live) указывает, как долго резолверы могут кешировать ответ, прежде чем проверять его заново.
«Пропагация» — в основном результат того, что кеши истекают в разное время.
Чаще всего управляют такими записями:
A / : указывают имя на IPv4/IPv6 адрес (веб‑серверы).Регистратор — это сервис, где вы регистрируете/продлеваете домен (право использовать example.com).
DNS‑хостинг — это сервис, который публикует ваши DNS‑записи на авторитетных серверах. Вы можете регистрировать домен у одной компании и хостить DNS у другой: для этого в настройках регистратора меняют NS‑записи.
Основные риски:
NS или записей и фактический «захват» домена.MX, опечатки или конфликтующие записи ломают сервисы.AAAACNAME: делает одно имя псевдонимом другого (часто для www).MX: куда доставлять почту для домена.TXT: верификация и почтовая аутентификация (SPF, DKIM, DMARC).NS: какие сервера авторитетны для домена.Практическое правило: не ставьте одновременно CNAME и A на одно и то же имя.
Практические меры: