DNS

27 сентября 2026 · ~14 мин чтения

DNS

DNS (Domain Name System, система доменных имён) — распределённая иерархическая база данных, которая превращает человекочитаемые имена вроде example.ru в IP-адреса и другие служебные записи. Это «телефонная книга интернета», у которой нет одного владельца и одного сервера.

История

До DNS интернет (тогда ещё ARPANET) жил на одном текстовом файле. Он назывался HOSTS.TXT, и его вела вручную одна организация — Network Information Center при Стэнфордском исследовательском институте (SRI-NIC) в Калифорнии. Хочешь добавить свой компьютер в сеть — пишешь письмо в SRI-NIC, там вносят строку «имя — адрес», и раз в какое-то время все администраторы скачивают свежую версию файла. Отголосок этой эпохи до сих пор живёт в каждом компьютере: файл /etc/hosts на Mac и Linux — прямой потомок HOSTS.TXT.

К началу 1980-х это перестало работать. Узлов становилось больше, файл рос, изменения расходились с задержкой, имена конфликтовали, а сервер SRI-NIC захлёбывался от скачиваний. Проблема была классической для централизованных систем: одна точка, которая всё знает, не масштабируется.

• 1983 — американский инженер Пол Мокапетрис (Paul Mockapetris) из Института информационных наук Университета Южной Калифорнии (USC ISI) по заказу Джона Постела предложил DNS. Первые спецификации — RFC 882 и RFC 883.
• 1984 — четверо студентов Калифорнийского университета в Беркли написали первую массовую реализацию DNS-сервера — BIND (Berkeley Internet Name Domain). BIND до сих пор живёт и развивается, сейчас его поддерживает некоммерческая организация ISC (Internet Systems Consortium).
• 1985 — зарегистрирован первый домен в зоне .com: symbolics.com.
• 1987 — выходят RFC 1034 и RFC 1035. Это «библия» DNS, актуальная и сегодня: почти всё, что ты видишь в панели регистратора, описано там.
• 1994 — делегирована национальная зона .ru (7 апреля 1994 года, этот день в Рунете отмечают как его день рождения).
• 1997 — RFC 2136 описывает динамическое обновление записей (Dynamic Updates). Это техническая основа того, что потом назовут «динамическим DNS».
• 1998 — создана ICANN, некоммерческая организация, которая с тех пор координирует корневую зону и распределение доменов верхнего уровня.
• 2005 — DNSSEC (RFC 4033–4035): криптографические подписи записей, чтобы ответ нельзя было подделать.
• 2008 — исследователь Дэн Камински (Dan Kaminsky) показывает серьёзную уязвимость «отравления кэша», и весь мир срочно патчит DNS-серверы.
• 2016–2018 — шифрованный DNS: DNS over TLS (RFC 7858, 2016) и DNS over HTTPS (RFC 8484, 2018).

DNS — не продукт, а открытый стандарт IETF. Владельца у протокола нет; корневую зону обслуживают 12 организаций-операторов под координацией IANA/ICANN.

Что это такое

Компьютеры в сети общаются по IP-адресам: 94.141.x.x или 2a02:6b8::… для IPv6. Людям такие числа неудобны, а ещё важнее — адреса меняются. Сервер переехал к другому хостеру, и у него новый IP. Если бы все ссылки в мире были записаны числами, каждый переезд ломал бы их. DNS добавляет уровень косвенности (indirection — ссылку через промежуточное звено): ссылки указывают на имя, а имя уже указывает на адрес. Поменял одну запись — и весь мир (со временем) пошёл на новый сервер.

Устроено это как дерево. На вершине — корень (обозначается точкой, её обычно не пишут: example.ru.). Под корнем — домены верхнего уровня (TLD, top-level domain): .ru, .com, .org. Под ними — домены второго уровня, которые покупаешь ты: moysait.ru. Под ними — сколько угодно поддоменов: api.moysait.ru, admin.moysait.ru. Каждый уровень отвечает только за себя и знает, кто отвечает за уровень ниже. Это называется делегированием (delegation — передачей полномочий).

В DNS хранятся не только адреса. Основные типы записей (resource records):

• A — имя → IPv4-адрес.
• AAAA — имя → IPv6-адрес.
• CNAME — псевдоним: «это имя — то же самое, что вон то имя».
• MX — какой сервер принимает почту для домена.
• TXT — произвольный текст. Через него работают SPF, DKIM, DMARC (защита почты от подделки), подтверждение владения доменом для Google, Яндекса, Let's Encrypt.
• NS — какие серверы отвечают за эту зону.
• SOA — служебная «шапка» зоны: серийный номер, таймеры.
• PTR — обратное преобразование: IP → имя.
• CAA — какие удостоверяющие центры имеют право выпускать TLS-сертификаты для домена.

Важное понятие — TTL (time to live, время жизни). У каждой записи есть число секунд, в течение которого ответ можно держать в кэше. TTL = 3600 означает «запомни на час и не спрашивай». Именно TTL отвечает за знаменитое «DNS обновляется до 72 часов» — на самом деле изменения видны тогда, когда истекут кэши.

DNS vs /etc/hosts. Hosts — локальная табличка на одном компьютере, DNS — глобальная распределённая система. Hosts проверяется первым, поэтому им удобно временно «обмануть» свой компьютер при тестировании переезда.

DNS vs DDNS. Обычный DNS рассчитан на то, что адрес сервера меняется редко и руками. Динамический DNS (DDNS) — это сервис, где запись обновляется автоматически, программой, иногда много раз в сутки. Он появился для домашних серверов и роутеров, у которых провайдер выдаёт «плавающий» IP. Примеры: DynDNS (с 1998 года, потом стал частью Oracle), No-IP, DuckDNS — бесплатный сервис, который выдаёт поддомен вида имя.duckdns.org и обновляет его по простому HTTP-запросу с твоим токеном.

DNS vs URL. DNS знает только имя хоста. Всё, что после него — путь /go, параметры ?utm_source=… — DNS не видит и не касается. Это уже работа веб-сервера.

Аналогии из жизни

1. Справочная служба и записная книжка. Ты хочешь позвонить в ресторан «Пушкин». Номера не помнишь — звонишь в справочную, там дают номер, ты записываешь его себе в книжку и дальше звонишь напрямую. Справочная — это DNS-сервер, книжка — кэш, а срок, через который ты решишь «номер мог устареть, спрошу ещё раз» — TTL.

Где ломается: справочная в жизни одна и знает всё сама. В DNS никто не знает всего: твой резолвер ходит по цепочке — сначала к корню, потом к серверу .ru, потом к серверу конкретного домена. И у тебя нет способа «вычеркнуть» чужую записную книжку: если какой-то провайдер закэшировал старый адрес на сутки, ты ничего с этим не сделаешь, кроме как подождать.

2. Адрес на конверте и переезд. Люди пишут письма не на координаты GPS, а на «улица Такая-то, дом 5». Если дом снесли и организация переехала, почта может переадресовывать письма.

Где ломается: в DNS имя привязано не к «зданию», а к договору с регистратором. Если ты переезжаешь не в новое здание, а на новое имя (как с something.duckdns.org на something.ru), DNS тебе ничем не поможет: старое имя продолжит указывать туда, куда указывало. Переадресацию придётся делать самому на уровне веб-сервера (HTTP-редирект 301), и она сработает только для тех, кто вообще ходит через браузер. Робот, у которого старый адрес зашит в настройках, просто продолжит стучаться по старому.

3. Дерево подразделений в большой компании. Секретарь на ресепшене не знает, как зовут стажёра в отделе аналитики, но знает, что за аналитику отвечает директор по развитию. Тот знает руководителя отдела, руководитель — стажёра. Вопрос спускается по дереву, пока не дойдёт до того, кто знает ответ. Это точная модель делегирования.

Где ломается: в компании начальник может сам решить за подчинённого. В DNS вышестоящий уровень не хранит данные нижнего — сервер .ru не знает IP-адреса твоего сайта, он знает только, какие серверы отвечают за твой домен (NS-записи). И если эти серверы недоступны, никто выше не подстрахует: домен просто «пропадёт».

Как это работает

Разберём, что происходит, когда ты впервые за день открываешь https://moysait.ru/go?....

Шаг 1. Локальные проверки. Операционная система сначала смотрит в файл /etc/hosts, потом в свой кэш. Если ответ там есть и TTL не истёк — всё, дальше можно не ходить.

Шаг 2. Stub-резолвер → рекурсивный резолвер. В компьютере живёт маленький «stub resolver» (заглушка), который ничего сам не ищет. Он отправляет вопрос «какой A-адрес у moysait.ru?» на рекурсивный резолвер — сервер, адрес которого тебе выдал роутер или провайдер, либо публичный: Google 8.8.8.8 (с 2009 года), Cloudflare 1.1.1.1 (с апреля 2018), Яндекс 77.88.8.8. Запрос идёт по UDP на порт 53, обычно это один пакет туда и один обратно.

Шаг 3. Рекурсия (если в кэше резолвера ответа нет).

Резолвер → корневой сервер (.):      «moysait.ru?»
Корень   → резолвер:                 «не знаю, спроси серверы .ru, вот их адреса»
Резолвер → сервер зоны .ru:          «moysait.ru?»
Сервер .ru → резолвер:               «не знаю, вот NS-серверы этого домена»
Резолвер → авторитетный NS домена:   «moysait.ru?»
Авторитетный → резолвер:             «A 94.141.x.x, TTL 300»

Авторитетный (authoritative) сервер — тот, кто по-настоящему «владеет» записями зоны. Обычно это DNS-серверы регистратора или хостинга, где ты правишь записи в панели.

Шаг 4. Кэширование. Резолвер запоминает ответ на TTL секунд — и не только финальный, но и промежуточные (где серверы .ru). Поэтому реальные запросы к корню редки: адреса серверов .ru уже у всех в кэше.

Шаг 5. Соединение. Браузер получил IP, открывает TCP-соединение (или QUIC), делает TLS-рукопожатие. Здесь важная деталь: в TLS браузер сообщает серверу имя, к которому хочет подключиться (SNI, Server Name Indication), а в HTTP — заголовок Host. Поэтому на одном IP может жить много сайтов, и nginx по заголовку Host решает, какой из них показать. DNS привёл тебя к зданию, а Host — к нужной квартире.

Про корневые серверы. Их «13» — буквы от A до M. Но это 13 имён, а физических серверов за ними больше тысячи по всему миру (по данным root-servers.org, порядка 1700–1900 инстансов; точное число меняется). Работает это через anycast — один и тот же IP анонсируется из множества точек, и тебя маршрутизирует к ближайшей.

Как работает динамический DNS. У DDNS-сервиса есть свой авторитетный сервер для зоны (например, duckdns.org) и HTTP-API. Программа на твоём сервере или роутере раз в несколько минут делает запрос вида «обнови мой поддомен, вот токен» — сервис видит, с какого IP пришёл запрос, и записывает его в A-запись с маленьким TTL (десятки секунд или минуты). Всё, имя всегда указывает на твой текущий адрес. Под капотом — тот же DNS, просто с автоматическим обновлением.

Где встречается в обычной жизни

• Любой набранный адрес сайта. Когда пишешь ya.ru в браузере, первые миллисекунды уходят на DNS-запрос. Если «интернет есть, а сайты не открываются, но Telegram работает» — очень часто это сломан именно DNS у провайдера или роутера.
• Wi-Fi в кафе и отелях. Страница «примите условия» (captive portal) часто работает через подмену DNS-ответов: пока не нажал «согласен», любое имя резолвится в адрес страницы авторизации.
• Родительский контроль и блокировщики рекламы. AdGuard DNS, Pi-hole, «семейные» режимы Яндекс DNS — всё это DNS-серверы, которые на запрос к рекламному или взрослому домену отвечают «такого нет».
• Почта. Когда отправляешь письмо на ivan@company.ru, твой почтовый сервер спрашивает DNS: «MX-запись для company.ru?» — и узнаёт, куда отнести письмо. А сервер получателя проверяет TXT-записи (SPF, DMARC), чтобы решить, не спам ли это.
• Домашний видеорегистратор или NAS «из интернета». Если ты открываешь камеру на даче по имени вроде dacha.ddns.net — это динамический DNS, который следит за плавающим IP домашнего роутера.

Где встречается в IT и бизнесе

• Переезд сервера. Нужно, когда меняешь хостера: заранее снижаешь TTL до 60–300 секунд, ждёшь, пока старый длинный TTL истечёт, меняешь A-запись, ждёшь минут пять — и трафик уже на новом сервере. Откат — так же быстро.
• Балансировка и отказоустойчивость. Нужно, когда один сервер не справляется или должен быть запасной: несколько A-записей (round-robin), GeoDNS (разный ответ для разных регионов), health-check с автоматическим переключением. Так работают Route 53 у AWS, Cloudflare, Яндекс Cloud DNS.
• CDN. Нужно, когда статика должна отдаваться быстро во всём мире: CNAME на домен CDN, а CDN уже отдаёт IP ближайшего к пользователю узла.
• Подтверждение владения. Нужно, когда подключаешь домен к Google Search Console, Яндекс Вебмастеру, почте для домена или получаешь сертификат Let's Encrypt через DNS-challenge: сервис просит положить TXT-запись со случайной строкой.
• Бренд и доверие. Нужно, когда проект вырастает из прототипа. Бесплатный DDNS-поддомен удобен на старте, но рекламные площадки, модерация, пользователи и почтовые фильтры доверяют собственному домену больше. Плюс собственный домен можно в любой момент перенести к другому DNS-провайдеру, а поддомен чужого сервиса — нет.

Кто пользуется

Все. DNS — один из немногих протоколов, без которого интернет в привычном виде не существует.

• Верисайн (Verisign) обслуживает зоны .com и .net — это сотни миллионов доменов (порядка 150–160 миллионов в .com, по их ежеквартальным отчётам). Нагрузка на их серверы — сотни миллиардов запросов в сутки.
• Координационный центр доменов .RU/.РФ — администратор российских национальных зон; в .ru порядка 5 миллионов доменов (точное число смотри на cctld.ru, оно меняется).
• Cloudflare 1.1.1.1 и Google Public DNS — крупнейшие публичные резолверы; по заявлениям компаний, это триллионы запросов в месяц.
• Dyn (бывший DynDNS) — в октябре 2016 года его серверы атаковал ботнет Mirai из заражённых камер и роутеров. Итог: на несколько часов для значительной части США «пропали» Twitter, GitHub, Netflix, Reddit. Сами сайты работали, просто никто не мог узнать их адреса. Это лучшая иллюстрация того, насколько DNS — критическая инфраструктура.

Альтернативы и конкуренты

У DNS как у протокола альтернатив в массовом интернете нет, но есть альтернативные подходы и способы доставки:

• Файл hosts / статическая конфигурация.
  Плюс: мгновенно, без сети, полный контроль.
  Минус: работает на одной машине, не масштабируется, забывается и потом ломает всё неожиданно.
• mDNS / Bonjour (локальные имена вида macbook.local).
  Плюс: работает в локальной сети без сервера и настройки.
  Минус: только в пределах одного сегмента сети, не для интернета.
• Шифрованный DNS (DoH, DoT, DoQ).
  Плюс: провайдер не видит и не подменяет твои запросы.
  Минус: сложнее диагностировать, корпоративные фильтры и родительский контроль перестают работать, часть сетей такой трафик блокирует.
• Сервис-дискавери внутри инфраструктуры (Consul, etcd, Kubernetes DNS).
  Плюс: адреса сервисов обновляются за секунды, есть health-check.
  Минус: работает только внутри твоего кластера; наружу всё равно нужен обычный DNS.

Когда НЕ стоит использовать

• Для мгновенного переключения при аварии без запаса по времени — потому что даже с TTL 60 часть клиентов (и некоторые провайдеры, игнорирующие TTL) будут ходить по старому адресу ещё минуты или часы. Для секундного переключения нужен балансировщик или anycast перед серверами.
• Бесплатный DDNS-поддомен для продакшена с деньгами — потому что ты не владеешь зоной: сервис могут отключить, заблокировать, он может упасть (бесплатные DDNS держатся на энтузиастах), а к доменам на duckdns.org и похожих часть почтовых фильтров и модераторов относится настороженно. Для прототипа — отлично, для рекламных кампаний — рискованно.
• Хранить в DNS секреты или часто меняющиеся данные — потому что DNS публичен (любой может запросить любую запись) и кэшируется по всему миру. Всё, что положил в TXT, видят все.

Связанные понятия

• IP-адрес — числовой адрес узла в сети; то, во что DNS превращает имя.
• TTL — сколько секунд ответ можно хранить в кэше; главный рычаг скорости изменений.
• Регистратор доменов — компания, через которую покупаешь домен и указываешь его NS-серверы (в России — например, REG.RU, RU-CENTER).
• DNSSEC — цифровые подписи DNS-записей, защищающие от подделки ответов.
• HTTP-редирект 301/302 — способ сказать браузеру «этот адрес теперь живёт там»; то, чем чинят смену имени, которую DNS починить не может.
• Anycast — один IP-адрес, анонсируемый из многих точек мира; так устроены корневые серверы и публичные резолверы.

Литература и источники

• RFC 1034 и RFC 1035 (1987, en) — оригинальные спецификации, до сих пор читаемые: https://www.rfc-editor.org/rfc/rfc1034 и https://www.rfc-editor.org/rfc/rfc1035
• Wikipedia: Domain Name System — https://en.wikipedia.org/wiki/Domain_Name_System (на русском: https://ru.wikipedia.org/wiki/DNS)
• Cricket Liu, Paul Albitz — «DNS and BIND» (O'Reilly, en; 5-е издание — 2006) — классическая книга, по которой учились администраторы. Есть русский перевод более ранних изданий — ищи «DNS и BIND Альбитц Ли».
• Julia Evans, «How DNS Works» — короткий иллюстрированный зин; искать по запросу «wizard zines dns».
• root-servers.org — https://root-servers.org — карта всех инстансов корневых серверов.
• Инструменты для практики: dig moysait.ru +trace в терминале показывает весь путь рекурсии по шагам; для визуализации — искать «dnschecker propagation».

Где встретилось у меня

Вчера один мой проект переезжал с бесплатного поддомена на DuckDNS на собственный домен .ru: новые рекламные ссылки прошли модерацию Директа, трафик переключился без потерь, а заодно выяснилось, сколько всего завязано на старое имя — вебхук мессенджера, адрес мини-приложения, CORS, тысячи ранее созданных ссылок. Отдельно аудит кода отметил устаревшие скрипты под DuckDNS как кандидатов на удаление.

Краткое резюме

• DNS превращает имена в IP-адреса через дерево делегирования: корень → зона верхнего уровня → авторитетный сервер домена. Придумал Пол Мокапетрис в 1983 году, основа — RFC 1034/1035.
• Скорость изменений определяет TTL и кэши по всему миру; перед переездом снижай TTL заранее.
• Динамический DNS (DuckDNS, No-IP) — тот же DNS с автоматическим обновлением записи; удобен для прототипов, рискован для продакшена.
• Смена IP под тем же именем — одна запись. Смена самого имени — полноценная миграция всех мест, где имя вписано руками.
• DNS — критическая инфраструктура: когда он падает (как Dyn в 2016-м), сайты работают, но до них никто не может дойти.