DNS: что это, как работает и что в нём меняет владелец сайта

Что такое DNS: система, которая превращает имя сайта в адрес сервера. Браузер не умеет открывать страницу по названию — ему нужен IP-адрес, и DNS этот адрес подсказывает. Отсюда и большинство странностей: сайт переехал, а открывается старый; у вас всё работает, а у клиента нет; письма с домена уходят в спам.

Что такое DNS простыми словами

DNS — это распределённая система, которая по имени домена отдаёт адрес сервера. Расшифровывается как Domain Name System, система доменных имён. Вы набираете example.ru, а в сеть уходит запрос на 203.0.113.10 — это и есть работа DNS.

Сравнение с телефонной книгой хромает: книга лежит у вас на полке целиком, а DNS нигде целиком не лежит. Это скорее справочная служба, которая переспрашивает коллег: каждый сервер знает свою часть и подсказывает, к кому обратиться дальше. Поэтому ответ приходит за десятки миллисекунд, хотя доменов в мире больше трёхсот миллионов.

Вторая важная особенность: ответы хранятся в кеше. Один раз узнав адрес, резолвер держит его у себя и повторно никого не спрашивает. Из-за этого правка в DNS не действует мгновенно — к этому мы вернёмся в разделе про TTL.

Три вещи DNS не делает, хотя их ему регулярно приписывают. Страниц и файлов в нём нет, только указатели: сам сайт всё время лежит на сервере хостинга. На скорость загрузки он тоже не влияет, потому что его работа заканчивается до того, как браузер запросит первую страницу. И сайт он не переносит: смена записи переключает посетителей на другой адрес, а файлы и базы данных туда нужно перевезти отдельно.

Как браузер находит сайт

Путь запроса выглядит так. Браузер смотрит свой кеш, затем кеш операционной системы и файл hosts. Если адреса нет, запрос уходит на резолвер — рекурсивный сервер провайдера или публичный сервис. Дальше работает он.

Резолвер спрашивает корневой сервер: кто отвечает за зону .ru. Получает список серверов зоны и спрашивает их: кто отвечает за example.ru. Получает NS-записи домена и спрашивает уже их: какой адрес у этого имени. Последний сервер отвечает по существу, потому что записи домена хранятся именно у него.

Четыре обращения — и браузер получает адрес. Дальше он открывает соединение с сервером напрямую, DNS в этом больше не участвует. Если хостинг отвечает медленно, виноват уже не DNS.

Отличать одно от другого полезно при поломках. Если имени в зоне нет, резолвер отвечает «такого домена не существует» — браузер пишет, что адрес не найден, и это вопрос к записям. Если адрес получен, но сервер молчит, сообщение будет другим: страница недоступна или слишком долго отвечает. Тогда DNS свою работу сделал, и смотреть надо на хостинг.

Иерархия серверов имён

Домены устроены деревом, и серверы имён повторяют его структуру. Читать имя нужно справа налево: сначала корень, потом зона верхнего уровня, потом ваш домен, потом поддомены.

Наверху корневая зона. У неё тринадцать адресов серверов, за которыми стоят сотни машин по всему миру: запрос попадает на ближайшую. Корневые серверы не знают ни одного сайта, их работа — подсказать сервер нужной зоны верхнего уровня.

Ниже зоны верхнего уровня: .ru, .com, .рф и остальные. Ими распоряжаются реестры, и они знают, какие серверы имён указаны для каждого домена внутри зоны. Сами записи сайта там не хранятся.

На нижнем уровне — авторитативный сервер вашего домена. Авторитативный значит, что его ответ окончательный: он не пересылает запрос дальше, а отдаёт записанное в зоне. Обычно это серверы регистратора или хостинг-провайдера.

Резолвер и кеш: почему второй раз быстрее

Рекурсивный резолвер — тот самый посредник, который обходит иерархию за вас. Его адрес устройство получает от роутера вместе с остальными сетевыми настройками, обычно это сервер провайдера. Вместо него можно указать публичный резолвер, работа от этого не изменится.

Главное в резолвере — кеш. Получив ответ, он запоминает его на срок, указанный в самой записи. Все абоненты этого провайдера получают уже готовый ответ, не тревожа ни корневые серверы, ни ваш хостинг. Без кеша каждое открытие страницы начиналось бы с похода к корню иерархии.

Свой кеш есть и на устройстве. В Windows его сбрасывают командой ipconfig /flushdns, в macOS — sudo dscacheutil -flushcache. Это первое, что стоит сделать, если вы уверены в записях, а старый адрес всё ещё открывается.

DNS-зона и домен — не одно и то же

Домен — это имя. Зона — набор записей для этого имени, который лежит на конкретном сервере. Когда говорят «добавьте запись в зону», речь про файл или строку в базе на авторитативном сервере, а не про регистрацию имени.

Связь между ними называется делегированием. В зоне .ru для вашего домена стоят NS-записи: вот серверы, которые отвечают за него. Пока делегирование указывает на одни серверы, правки на других не действуют — об этом подробнее в разделе про частые поломки. Как устроено само имя, разобрано в статье что такое домен.

Поддомен может оставаться в той же зоне, а может быть делегирован отдельно. Для shop.example.ru достаточно одной записи в зоне домена — отдельную регистрацию никто не требует.

Ресурсные записи: какие бывают

Записи в зоне и есть содержимое DNS. Каждая отвечает за свой вопрос: где сайт, куда нести почту, какие серверы распоряжаются доменом.

Обратная зона отличается от остальных: ею распоряжается не владелец домена, а тот, кому принадлежит адрес, то есть провайдер или хостер. Поэтому PTR-запись не добавляют в панели домена — её запрашивают у владельца адреса.

A-запись: как домен привязать к серверу

A-запись связывает имя с адресом IPv4. Это та самая строка, которую вам дают при заказе хостинга: имя @ или сам домен, значение равно адресу сервера. Что такое адрес и откуда он берётся, разобрано отдельно в статье что такое IP-адрес.

Про www забывают чаще всего. Это обычный поддомен, и сам по себе он не появляется: нужна либо своя A-запись с тем же адресом, либо CNAME на корень домена. Если её нет, сайт открывается без префикса и не открывается с ним.

Одному имени можно задать несколько A-записей с разными адресами — запросы разойдутся между ними по очереди. Это простейшая балансировка, но на отказ сервера она не реагирует: резолвер продолжит отдавать адрес, пока запись не убрать.

Отдельная история — запись вида *.example.ru, её называют wildcard. Она отвечает за все поддомены, для которых нет собственной записи, и выручает, когда поддомены создаются на ходу: клиентские имена или тестовые копии сайта. Побочный эффект тоже есть: домен начинает отвечать на любое имя, включая опечатки, и ошибку в адресе посетитель увидит не как «страница не найдена», а как ваш сайт.

NS-записи: серверы регистратора или хостера

NS-записи решают, кто вообще распоряжается зоной. Выбор небольшой: серверы регистратора, у которого куплен домен, или серверы хостинг-провайдера, где лежит сайт. Технически оба варианта равноценны, разница в удобстве и в том, где вы потом будете искать нужное поле.

Практический вывод: если домен и сайт живут у разных компаний и почта настроена на внешнем сервисе, спокойнее держать зону у регистратора. Тогда переезд сайта — это правка одной записи, а не перенос всей зоны. Если сайтов много и все они на одном хостинге, удобнее обратное.

Отдельный случай — VPS: там серверы имён остаются у регистратора или у сторонней службы, а на самом сервере достаточно поднять веб-сервер и указать его адрес в A-записи.

Почта: MX, SPF, DKIM и DMARC

Почта держится на DNS целиком. MX-запись говорит, какой сервер принимает письма для домена, а три TXT-записи отвечают за то, дойдут ли ваши письма до чужих ящиков.

SPF перечисляет серверы, которым разрешено отправлять письма от имени домена. DKIM добавляет к письму подпись, а в DNS лежит открытый ключ для её проверки. DMARC говорит, что делать с письмом, которое проверки не прошло: пропустить, отправить в спам или отклонить.

Пока этих записей нет, крупные почтовые службы считают письма с вашего домена подозрительными, и рассылка с сайта (уведомления о заказах, письма со сбросом пароля) оседает в спаме. Причина при этом одна: в зоне пусто.

Вторая по частоте беда касается переезда. При смене NS-записей зона создаётся заново, и MX в ней по умолчанию ведёт на нового хостера. Если почта работала на внешнем сервисе, её записи нужно перенести вручную, иначе письма начнут приходить не туда ровно в момент переключения.

TTL: почему изменения видны не сразу

У каждой записи есть TTL — время, которое её разрешено держать в кеше. Указывается в секундах: 3600 означает час, 300 — пять минут. Пока срок не вышел, резолверы отдают старый ответ и не спрашивают ваш сервер.

Отсюда знаменитое «у меня работает, а у клиента нет». Ваш резолвер уже обновил запись, а у клиента другой провайдер и другой кеш. Пока он не истечёт, человек видит старый сервер. Настройки здесь ни при чём, так устроено кеширование.

Распространённое утверждение про сутки или трое — про запас. Реальный срок равен TTL записи, которую вы поменяли, плюс кеш устройства. Если заранее не трогать TTL, он обычно часовой, то есть ждать придётся час.

Низкий TTL не бесплатен: резолверы спрашивают ваш сервер чаще, и каждый запрос посетителя начинается с лишнего обращения. Разница измеряется десятками миллисекунд и на живом сайте почти не заметна, но держать пятиминутный TTL постоянно смысла нет — его ставят на время переезда и возвращают обратно.

Перенос сайта: что делать с DNS

Переезд — самый частый повод открыть настройки DNS, и самый обидный: ошибка здесь видна всем посетителям сразу. Порядок, при котором простоя не будет.

1. За сутки снизьте TTL у записей, которые будете менять, до 300 секунд. Это нужно сделать заранее: пока старое значение в кешах, оно ещё действует.
2. Поднимите сайт на новом сервере и проверьте его, не меняя DNS. Для этого достаточно прописать адрес нового сервера в файле hosts на своём компьютере — у остальных сайт в это время работает по-старому.
3. Переключите запись. Если зона остаётся на месте, меняется только A-запись. Если переезжает и зона, сначала соберите её на новых серверах полностью, вместе с MX и TXT, и лишь затем меняйте NS.
4. Подождите срок TTL. Старый сервер в это время не выключайте: часть посетителей ещё идёт на него.
5. Верните TTL к обычному значению, когда убедитесь, что трафик пришёл на новый сервер.

Перенос сайтов на нашу сторону делают бесплатно: файлы, базы данных и почту переносит поддержка, а домен вы переключаете сами на последнем шаге — как раз по этому порядку. Подробнее о самой услуге — в статье что такое хостинг.

Как проверить записи своего домена

Угадывать не нужно: всё видно из командной строки. nslookup есть в Windows по умолчанию, dig — в macOS и Linux, оба показывают то же, что видят резолверы.

nslookup example.ru
nslookup -type=NS example.ru
nslookup -type=MX example.ru

Первая команда покажет адрес из A-записи, вторая — серверы имён, третья — почтовые. На macOS и Linux то же самое короче:

dig +short example.ru
dig +short NS example.ru
dig +short TXT example.ru

Полезный приём — спросить конкретный резолвер: dig @8.8.8.8 +short example.ru. Если ваш резолвер отдаёт новый адрес, а публичный ещё старый, значит правка верна и дело только в кеше. Команда whois example.ru показывает серверы имён со стороны реестра: именно их, а не содержимое зоны, видит весь остальной интернет.

Так же проверяют и выпуск сертификата: проверка домена идёт через TXT-запись, и если сертификат не выпускается, первым делом смотрят, видна ли она командой dig. Про сам сертификат — в статье что такое SSL-сертификат.

Что чаще всего ломается

Ошибок, которые ломают сайт после правок в DNS, немного. Вот пять самых частых.

Правки сделаны не на тех серверах. Человек меняет записи в панели регистратора, а домен делегирован на серверы хостера — или наоборот. Записи сохраняются и ни на что не влияют. Проверяется командой whois: NS-записи в ответе реестра и есть то место, где нужно править.

CNAME на корень домена запрещён стандартом: на корне уже есть служебные записи, а CNAME не терпит рядом с собой других. Панель либо откажет, либо примет запись, после чего домен перестанет открываться. Для корня нужна A-запись, CNAME годится только поддоменам.

Зона не создана: NS-записи переключили на хостера, а домен в панели хостинга не добавили. Серверы отвечают, что про такой домен ничего не знают, и сайт пропадает целиком, вместе с почтой.

Потерянные MX-записи — классика переезда: сайт открылся на новом сервере, а письма перестали приходить, потому что в новой зоне почтовых записей нет.

Забытый www: сайт открывается по короткому имени и не открывается с префиксом, потому что для поддомена записи нет.