Коротко. DNS (Domain Name System) — распределённая система, которая превращает имя сайта в IP-адрес сервера. Браузер спрашивает резолвер, тот по цепочке опрашивает корневые, TLD- и авторитативные серверы домена, получает адрес и кладёт ответ в кэш. Без DNS сайты открывались бы только по цифрам, а переезд на новый сервер ломал бы все ссылки на вас.
Что такое DNS простыми словами
Вы набираете enterno.io, но соединение всё равно устанавливается с числом вроде 81.163.20.249. Маршрутизаторы и коммутаторы умеют доставлять пакеты только по IP-адресам — имена им ничего не говорят. DNS стоит ровно между этими двумя мирами: принимает имя, возвращает адрес.
Расшифровывается как Domain Name System — «система доменных имён». Базовые документы — RFC 1034 (концепция) и RFC 1035 (формат сообщений), обоим больше тридцати лет. С тех пор появились шифрование, подписи и десятки типов записей, но сама механика поиска не изменилась.
Почему аналогия с телефонной книгой врёт
Почти любое объяснение DNS начинается со слов «это телефонная книга интернета». Аналогия честна ровно в одном: и там, и там по имени находят номер. Дальше она обманывает — и обманывает именно в тех местах, где потом ломается сайт.
- Единой книги не существует. Нет сервера, где лежал бы полный список доменов мира. Данные разложены по уровням: корень знает, кто отвечает за зону
io; серверыioзнают, кто отвечает заenterno.io; и только последние знают сам адрес. Это не книга, а цепочка перенаправлений. - Ответ бывает устаревшим. Книга на полке всегда показывает то, что напечатано. DNS показывает то, что успел закэшировать конкретный резолвер, — иногда адрес, которого уже нет.
- Одно имя — разные ответы. Телефон у человека один, а крупный сайт для посетителя из Москвы и из Франкфурта может резолвиться в разные IP. Так работают CDN, geo-балансировка и split-horizon во внутренних сетях.
- В DNS лежат не только адреса. Там же маршруты почты (MX), подтверждение владения доменом и антиспам-политики (TXT), адреса служб (SRV), привязка к удостоверяющему центру (CAA). Телефонная книга такого не умеет.
- Обратный поиск — отдельная система. Найти имя по номеру в бумажной книге нельзя, и в DNS «наоборот» тоже не бесплатно: за это отвечают PTR-записи в отдельном дереве
in-addr.arpa. Подробности — в статье про обратный DNS и PTR-записи.
Более точная аналогия — справочная служба с делегированием полномочий. Вы звоните в единственный известный вам номер. Там не знают ответа, но точно знают, кто отвечает за нужный регион, и дают его телефон. Там знают, кто отвечает за конкретную организацию. И только третий звонок даёт результат. При этом каждый участник записывает услышанное на бумажку и следующие несколько минут отвечает по ней, не перезванивая.
Ключевое свойство DNS — не «поиск», а делегирование. Владелец зоны
ioне хранит адрес вашего сайта: он хранит только указание, у каких серверов спрашивать. Поэтому вы меняете записи у себя, ни с кем не согласовывая, — и это же причина, по которой ошибка в делегировании выключает домен целиком.
Зачем нужен DNS и что было бы без него
DNS решает четыре задачи, и только первая очевидна.
- Читаемость. Имя можно продиктовать по телефону, напечатать на визитке и запомнить. IPv6-адрес вида
2001:db8:85a3::8a2e:370:7334— нет. - Отвязка имени от железа. Сервер переехал к другому хостеру, сменился IP — вы правите одну A-запись, и все ссылки, закладки и внешние интеграции продолжают работать. Без DNS переезд означал бы рассылку нового адреса всем, кто на вас ссылается.
- Распределение нагрузки и отказоустойчивость. Одно имя может указывать на несколько адресов, а ответ — зависеть от географии клиента или состояния площадки. На этом построены CDN и DNS-failover.
- Служебные метаданные домена. Куда доставлять почту, кому разрешено выпускать TLS-сертификаты, какие сервисы владеют доменом — всё это живёт в DNS и проверяется автоматикой без участия человека.
Что происходит, когда DNS ломается, — видно по симптомам: сайт «не найден» при живом сервере, почта перестаёт доходить, сертификат не продлевается. Это не гипотеза, а самый частый класс инцидентов у доменов, потому что DNS — единственная точка, через которую проходит вообще весь входящий трафик.
Что такое DNS-сервер и какие они бывают
Словом «DNS-сервер» называют минимум пять разных вещей, и путаница между ними — причина половины неудачных диагностик. Разделим по роли.
Стаб-резолвер: клиент внутри вашего устройства
Это код в операционной системе (и всё чаще — в самом браузере), который принимает от программы имя и отдаёт адрес. Сам он ничего не ищет: у него есть список из одного-двух адресов «куда спрашивать» — тот самый, что прилетает по DHCP от роутера или прописан руками. Стаб-резолвер держит небольшой собственный кэш, поэтому «в браузере старый адрес, а в консоли новый» — нормальная и частая ситуация.
Рекурсивный резолвер: тот, кто делает всю работу
Сервер провайдера, роутера или публичный (например, из подборки лучших публичных DNS-серверов). Именно он обходит иерархию сверху вниз, собирает ответ и хранит большой общий кэш на всех своих пользователей. С точки зрения вашего сайта это самый важный участник: его кэш определяет, как быстро мир увидит изменения.
Корневые серверы: 13 имён, а не 13 машин
Вершина иерархии. Их ровно тринадцать — но тринадцать имён, от a.root-servers.net до m.root-servers.net. Это самая тиражируемая ошибка в объяснениях DNS: «в мире всего 13 корневых серверов, и если их выключить, интернет умрёт».
За тринадцатью именами стоит более тысячи физических площадок по всему миру — их число постоянно растёт. Работает это через anycast: один и тот же IP-адрес анонсируется из десятков точек, и запрос попадает на ближайшую по сетевым метрикам. Ограничение в 13 имён историческое — список корней должен был помещаться в одно UDP-сообщение размером 512 байт, как это описано в RFC 1035. Механику раздачи одного адреса из многих мест разбирает статья про anycast DNS.
Не пишите и не повторяйте «в интернете 13 корневых серверов». Правильно: 13 корневых имён, за которыми стоят тысячи узлов anycast, управляемых двенадцатью независимыми организациями. Отсюда и живучесть корня: отключить его целиком нельзя в принципе.
TLD-серверы: держатели зоны верхнего уровня
Отвечают за com, ru, io, рф и остальные окончания. Они тоже не знают адрес вашего сайта — только имена серверов, которым делегирована ваша зона. Эти данные попадают туда от регистратора, когда вы указываете NS в панели домена.
Авторитативные серверы: единственный источник правды
Здесь физически лежит ваша зона: A, AAAA, MX, TXT и всё остальное. Что написано тут — то и есть правда; остальные участники лишь передают копии с ограниченным сроком годности. Обычно это серверы DNS-хостинга, регистратора или облачного провайдера. Развёрнутое сравнение ролей — в статье про типы DNS-серверов.
| Участник | Что хранит | Кого спрашивает | Есть ли кэш |
|---|---|---|---|
| Стаб-резолвер (ОС, браузер) | Ничего своего | Один настроенный резолвер | Да, маленький и короткий |
| Рекурсивный резолвер | Чужие ответы | Корень → TLD → авторитативный | Да, большой и общий |
| Корневой сервер | Кто отвечает за TLD | Никого | Нет |
| TLD-сервер | NS-записи доменов зоны | Никого | Нет |
| Авторитативный сервер | Саму зону домена | Никого | Нет, он и есть источник |
Что происходит между вводом адреса и открытием страницы
Разберём полный путь. Допустим, кэши пусты — худший и самый показательный случай.
- Браузер и ОС смотрят к себе. Проверяются внутренний кэш браузера, кэш стаб-резолвера и файл
hosts. Если ответ нашёлся — на этом всё, сеть не задействована вообще. - Запрос уходит рекурсивному резолверу. Обычно это UDP на порт 53. Клиент просит: «дай A-запись для
enterno.io, разбирайся сам» — выставлен флаг рекурсии. - Резолвер идёт в корень. Спрашивает про
enterno.io. Корень не знает ответа и отвечает отсылкой: «за зонуioотвечают такие-то серверы». - Резолвер идёт в TLD. Серверы
ioтоже не знают адрес, но знают делегирование: «зонаenterno.io— наdns1.yandex.netиdns2.yandex.net». - Резолвер идёт к авторитативному серверу. Тот отвечает по существу: A-запись и её TTL.
- Резолвер кэширует и отвечает клиенту. Ответ помечается как неавторитативный: это копия, а не первоисточник.
- Браузер открывает TCP-соединение по полученному IP, дальше идут TLS-рукопожатие и HTTP-запрос. Это уже не про DNS.
Всю цепочку видно своими глазами. Ключ +trace отключает рекурсию и заставляет dig пройти иерархию самостоятельно, показывая каждый шаг:
dig +trace enterno.io A
. 80131 IN NS a.root-servers.net.
...
;; Received 525 bytes from 188.93.17.19#53(188.93.17.19) in 0 ms
io. 172800 IN NS a0.nic.io.
io. 172800 IN NS b0.nic.io.
;; Received 650 bytes from 192.5.5.241#53(f.root-servers.net) in 0 ms
enterno.io. 3600 IN NS dns1.yandex.net.
enterno.io. 3600 IN NS dns2.yandex.net.
;; Received 572 bytes from 65.22.160.17#53(a0.nic.io) in 45 ms
enterno.io. 3600 IN A 81.163.20.249
;; Received 103 bytes from 93.158.134.213#53(dns2.yandex.net) in 7 msЧетыре блока — четыре шага: корень, зона io, делегирование, ответ. Обратите внимание на строку Received ... from в конце каждого блока: там видно, кто именно ответил. Если +trace обрывается на середине — вы нашли уровень, где сломано делегирование.
Зачем нужен кэш DNS и почему изменения «не видны сразу»
Если бы каждый запрос шёл через всю иерархию, корневые и TLD-серверы захлебнулись бы в первый же час. Кэш решает это: подавляющее большинство ответов отдаётся из памяти ближайшего резолвера за единицы миллисекунд.
Разницу видно на секундомере. Первый запрос идёт до авторитативного сервера, второй — из кэша, и TTL в ответе уже начал уменьшаться:
# холодный запрос — резолвер обходит иерархию
dig iana.org A | grep -E "^iana|Query time"
iana.org. 3600 IN A 192.0.43.8
;; Query time: 170 msec
# тот же запрос через несколько секунд — ответ из кэша
dig iana.org A | grep -E "^iana|Query time"
iana.org. 3592 IN A 192.0.43.8
;; Query time: 0 msecTTL (Time To Live) — число секунд, которое ответ разрешено хранить. В примере выше 3600 означает «час», и счётчик 3592 показывает, сколько осталось. Когда он дойдёт до нуля, резолвер сходит за свежими данными.
Отсюда главный практический вывод: вы не управляете чужими кэшами. Поменяв A-запись, вы поменяли её на своём авторитативном сервере мгновенно — но все резолверы мира, у которых лежит старый ответ, будут отдавать его до истечения своего TTL. Плюс отдельно кэшируют браузер и операционная система пользователя.
Никакие «изменения вступают в силу в течение 24–72 часов» не являются правилом или гарантией. Это старая формулировка регистраторов. Реальный срок задаётся вашим TTL, а отдельные резолверы могут удерживать запись дольше заявленного или, наоборот, обновиться за минуту. Если планируете переезд — снизьте TTL заранее, за срок больше текущего TTL, и поднимите обратно после.
Кэшируются и отрицательные ответы. Когда имени не существует, авторитативный сервер отдаёт статус NXDOMAIN и SOA-запись, последнее поле которой задаёт срок хранения «отрицательного» результата. Поэтому только что созданная запись иногда «не видна», хотя всё сделано правильно:
dig +noall +authority no-such-host-zz1.enterno.io A
enterno.io. 95 IN SOA dns1.yandex.net. dns-hosting.yandex.ru. 36 900 90 86400 900Последнее число (900) — negative TTL: пятнадцать минут резолвер будет помнить, что имени нет. Как выбирать значения TTL для разных задач, разобрано в статье про TTL DNS-записей, а что и в каком порядке обновляется при смене адреса — в материале про распространение DNS.
Что такое частный DNS: Private DNS, DoH и DoT
Классический DNS ходит открытым текстом по UDP/53. Кто угодно на пути — провайдер, владелец Wi-Fi, транзитный оператор — видит, какие сайты вы запрашиваете, и может подменить ответ. Шифрование закрывает обе проблемы.
Private DNS в Android — это DoT
Пункт «Частный DNS» (Private DNS) в настройках Android включает DNS over TLS: тот же DNS, но внутри TLS-туннеля на порт 853. В режиме «имя хоста провайдера» вы указываете доменное имя резолвера, и система проверяет его сертификат — то есть заодно убеждается, что говорит именно с ним. Спецификация — RFC 7858.
Проверить, что резолвер действительно слушает 853 и его сертификат валиден, можно так:
echo | openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com 2>/dev/null \
| grep -E "subject=|Verify return code"
subject=C=US, ST=California, L=San Francisco, O=Cloudflare, Inc., CN=cloudflare-dns.com
Verify return code: 0 (ok)DoH — DNS внутри HTTPS
DNS over HTTPS (RFC 8484) заворачивает запросы в обычный HTTPS на 443-й порт, где они неотличимы от прочего веб-трафика. Так делают браузеры со своим встроенным резолвером. Многие провайдеры DoH отдают ещё и JSON-вариант, который удобно дёргать из консоли:
curl -s -H "accept: application/dns-json" \
"https://cloudflare-dns.com/dns-query?name=enterno.io&type=A"
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,
"Question":[{"name":"enterno.io","type":1}],
"Answer":[{"name":"enterno.io","type":1,"TTL":3600,"data":"81.163.20.249"}]}| Вариант | Транспорт | Порт | Виден ли трафик со стороны | Где включают |
|---|---|---|---|---|
| Классический DNS (Do53) | UDP, при больших ответах TCP | 53 | Имена видны, ответ можно подменить | По умолчанию везде |
| DoT | TLS | 853 | Скрыт, но факт использования DNS заметен по порту | Android «Частный DNS», systemd-resolved, роутеры |
| DoH | HTTPS | 443 | Скрыт и смешан с обычным веб-трафиком | Браузеры, ОС, приложения |
Шифрование прячет запрос от посредников, но не делает ответ достоверным: вы просто переносите доверие с провайдера на выбранного оператора резолвера. За подлинность самих данных отвечает другая технология — DNSSEC, криптографическая подпись зоны. DoH и DNSSEC решают разные задачи и не заменяют друг друга.
Практическая сторона вопроса — какие бывают провайдеры, чем платят за приватность и как это влияет на корпоративные фильтры — разобрана в статье про DNS over HTTPS. Как поменять резолвер на устройстве или роутере — в инструкции как сменить DNS-сервер.
Как посмотреть, что отвечает DNS для вашего домена
Три инструмента командной строки закрывают почти все вопросы. dig — основной, точный и подробный; nslookup есть везде, включая Windows; host удобен для быстрой проверки.
# адрес домена, коротко
dig +short enterno.io A
# ответ с TTL и типом записи
dig +noall +answer enterno.io A
enterno.io. 3245 IN A 81.163.20.249
# кто авторитативен для зоны
dig +short NS enterno.io
dns1.yandex.net.
dns2.yandex.net.
# спросить напрямую у авторитативного сервера, минуя все кэши
dig +noall +answer +norecurse @dns1.yandex.net enterno.io A
enterno.io. 3600 IN A 81.163.20.249
# сравнить ответ конкретного публичного резолвера
dig +short enterno.io A @8.8.8.8
# то же самое через nslookup и host
nslookup -type=NS enterno.io 1.1.1.1
host -t A enterno.ioПриём с +norecurse и явным указанием сервера — главный в диагностике: он показывает истину без посредников. Если авторитативный сервер отдаёт новый адрес, а публичный резолвер — старый, вопрос закрыт: это кэш, ждите истечения TTL. Если авторитативный отдаёт старый — правка просто не сохранилась.
Смотреть на выдачу нескольких резолверов одновременно удобнее в браузере:
- DNS Lookup — все записи домена: A, AAAA, MX, NS, TXT, CNAME, SOA сразу, с TTL.
- Проверка распространения DNS — что видят резолверы в разных странах прямо сейчас; лучший способ понять, разошлось изменение или нет.
- Проверка отдельной записи — когда нужен один тип и его точное значение.
- WHOIS — какие NS указаны на уровне регистратора; расхождение с реальными NS в зоне — частая причина «то работает, то нет».
- MX Lookup и проверка почтовых записей — если сломалась не веб-часть, а почта.
- Мониторинг — следит за DNS-записями и предупреждает, когда они изменились без вашего ведома или зона перестала отвечать.
Частые ошибки DNS и что они значат
Статус ответа виден в заголовке dig в поле status:. Он сразу сужает круг подозреваемых.
| Что видно | Что это значит | Где искать причину |
|---|---|---|
status: NOERROR, но ANSWER: 0 | Имя есть, записи запрошенного типа нет | Запросили A, а заведена только AAAA или CNAME |
status: NXDOMAIN | Имени не существует | Опечатка в имени, запись не сохранена, домен истёк |
status: SERVFAIL | Резолвер не смог получить ответ | Авторитативные серверы недоступны, битое делегирование, ошибка проверки DNSSEC |
status: REFUSED | Сервер отказался отвечать | Спросили не тот сервер: он не авторитативен для зоны и не обслуживает вас рекурсивно |
connection timed out; no servers could be reached | До сервера не дошли пакеты | Фильтрация UDP/53, сеть, неверный адрес резолвера |
Отдельный коварный случай — расхождение между NS у регистратора и NS в самой зоне. Резолверы идут по делегированию от TLD, поэтому правки на «неподключённом» наборе серверов не видит никто, хотя в панели всё выглядит сохранённым. Сравните два ответа: dig +short NS домен (что видит мир) и список NS в панели регистратора. Пошаговый разбор симптомов — в статье почему DNS не резолвится.
Прежде чем менять что-то ещё, задайте себе один вопрос: авторитативный сервер уже отдаёт правильный ответ? Если да — вся оставшаяся проблема во времени и чужих кэшах, и любые дополнительные правки только удлинят путь. Если нет — менять кэши бессмысленно, чините зону.
Что стоит знать про записи зоны
Ответ DNS — это всегда запись определённого типа. Минимальный набор, который есть почти у каждого домена:
- A — адрес IPv4. AAAA — адрес IPv6.
- CNAME — псевдоним: «спрашивай про другое имя». В примере
www.github.comрезолвер сначала получает CNAME, затем идёт за адресом цели:www.github.com. CNAME github.com.→github.com. A 140.82.121.4. - NS — кто авторитативен для зоны. SOA — служебные параметры зоны, включая negative TTL.
- MX — куда доставлять почту домена.
- TXT — произвольный текст: SPF, DKIM, DMARC, подтверждения владения.
- CAA — каким удостоверяющим центрам разрешено выпускать сертификаты на домен.
Полный разбор с примерами значений и типичными ошибками — в руководстве по DNS-записям. Если вы только разбираетесь с доменом как таковым, начните со статьи что такое домен.
Частые вопросы
Что такое DNS-сервер простыми словами?
Компьютер, который отвечает на вопрос «какой адрес у этого имени». Но роли разные: авторитативный сервер хранит вашу зону и говорит правду, рекурсивный — ищет ответ по иерархии и кэширует его для своих пользователей. В настройках устройства вы указываете именно рекурсивный.
Сколько всего DNS-серверов в мире?
Точного числа не существует: авторитативные серверы поднимает каждый хостер и каждая крупная компания, рекурсивные стоят у провайдеров и внутри роутеров. Фиксировано только количество корневых имён — тринадцать, от a до m, за которыми стоят тысячи физических узлов anycast.
Что такое частный DNS и нужно ли его включать?
Это шифрование DNS-запросов: в Android пункт «Частный DNS» включает DNS over TLS, браузеры чаще используют DNS over HTTPS. Включать стоит, если вы пользуетесь чужими и публичными сетями, — тогда владелец точки доступа не видит и не подменяет запросы. Внутри корпоративной сети сначала уточните у администратора: шифрованный DNS в обход внутреннего резолвера ломает доступ к внутренним именам.
Почему после смены DNS-записи сайт открывается по-старому?
Ответ лежит в кэше — вашего браузера, операционной системы или резолвера провайдера — и будет отдаваться до истечения TTL. Проверьте истину напрямую у авторитативного сервера командой dig +norecurse @ваш-ns домен A: если там новое значение, остаётся только ждать. Гарантированных сроков нет, есть ваш TTL.
Влияет ли DNS на скорость сайта?
Да, но не там, где обычно ищут. Резолвинг происходит один раз перед соединением и обычно занимает единицы или десятки миллисекунд; из кэша — практически нисколько. Заметная задержка появляется, когда авторитативные серверы далеко или отвечают медленно, а страница тянет ресурсы с нескольких разных доменов — тогда каждый новый домен стоит отдельного резолвинга. Измерить общий эффект удобно через проверку скорости.
Чем DNS отличается от хостинга?
DNS отвечает на вопрос «где», хостинг — на вопрос «что». DNS только сообщает адрес сервера; сам сайт лежит и работает на хостинге. Поэтому сайт может быть жив, но недоступен из-за DNS, и наоборот — DNS отвечает корректно, а по указанному адресу ничего не отдаётся.
Чеклист: DNS домена в порядке
- NS в панели регистратора совпадают с тем, что отдаёт
dig +short NS домен. - Авторитативных серверов минимум два, и они в разных сетях.
dig +trace домен Aпроходит все четыре шага без обрыва.- A/AAAA-записи указывают на действующий сервер, а не на адрес прошлого хостинга.
- TTL осмысленный: короткий перед плановым переездом, обычный в спокойное время.
- MX и TXT (SPF, DKIM, DMARC) на месте, если домен отправляет или принимает почту.
- CAA-запись выставлена, если вы хотите ограничить выпуск сертификатов.
- Ответы авторитативного сервера и публичных резолверов совпадают.
- Домен и зона под мониторингом: изменение записей и падение зоны видно сразу, а не по жалобам пользователей.