Что такое DNS и как настроить домен на VPS

Что такое DNS и почему ваш домен еще не указывает на ваш VPS

DNS (domain name system) преобразует имя, например example.com, в IP-адрес (internet protocol), такой как 203.0.113.10. Браузер не может подключиться к имени. Он подключается к адресу, поэтому любая загрузка страницы начинается с DNS-запроса и ответа на него. Если вы только что купили домен и собственный VPS, но ничего не загружается, верна одна из двух причин: еще нет записи, связывающей имя с адресом вашего сервера, либо такая запись есть, но где-то на пути к вам все еще выдается старый ответ.

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

Для всех проверок здесь используется dig, который не установлен по умолчанию в чистой системе Ubuntu или Debian.

sudo apt update && sudo apt install -y bind9-dnsutils

Регистратор, серверы имен, DNS-хостинг: что именно нужно редактировать

Эти три понятия описывают разные задачи. Их путаница — самая частая причина, по которой изменения не вступают в силу.

• Регистратор — это компания, у которой вы приобрели домен. Его основная задача — делегирование: он сообщает реестру, управляющему вашей TLD (доменной зоной верхнего уровня, часть .com), какие серверы имен являются авторитетными для вашего домена.
• Авторитетные серверы имен хранят актуальные записи для вашей зоны. Зона — это ваш домен и все имена внутри него.
• DNS-хостинг — это организация или сервис, которые управляют этими серверами имен. Это может быть сам регистратор, сторонний провайдер или bind9, запущенный на вашем собственном сервере.

Покупка осуществляется у регистратора. Редактирование записей — на стороне DNS-хостинга. Если вы перенесли домен на серверы имен другого провайдера, панель управления DNS у регистратора всё равно будет показывать зону и сохранять изменения, но никто в интернете не будет обращаться к этой зоне за ответами. Записи будут корректными, но к ним просто никто не обратится.

Узнайте, куда именно направляются запросы из сети:

dig example.com NS +short
dig +trace example.com

Первая команда выводит серверы имен, которые отвечают за домен в данный момент. Вторая команда проходит по цепочке, начиная с корневых серверов, и выводит информацию о делегировании, которую предоставляют серверы TLD; именно этим делегированием управляет ваш регистратор. Если эти имена принадлежат провайдеру, который вам не знаком, значит, именно у него находится панель управления, которая вам нужна.

Как происходит один запрос

В процессе участвуют четыре стороны, и каждая из них сохраняет копию полученных данных.

1. Stub resolver на вашем компьютере. Он не выполняет поиск. Он отправляет запрос одному настроенному серверу и доверяет полученному ответу. В Ubuntu /etc/resolv.conf обычно является символической ссылкой на /run/systemd/resolve/stub-resolv.conf и указывает на 127.0.0.53, который представляет собой systemd-resolved, работающий локально и имеющий собственный кэш.
2. Рекурсивный резолвер. Это резолвер, который предоставляет ваш интернет-провайдер (ISP), либо публичный сервис, такой как 1.1.1.1, или же сервер, который вы запустили самостоятельно. Он выполняет основную работу по поиску ответа.
3. Корневые серверы и серверы TLD. Рекурсивный резолвер обращается к корневому серверу, который не знает ваш адрес, но возвращает ссылку на серверы .com. Они, в свою очередь, возвращают ссылку на ваши серверы имен.
4. Авторитетный сервер имен. Он никого не спрашивает. Он отвечает на основе вашей зоны и помечает ответ как авторитетный.

dig +trace example.com демонстрирует этот процесс, так как он начинает работу непосредственно с корня и выводит каждое перенаправление вместо обращения к кэшу. Это самый быстрый способ проверить, согласованы ли делегирование и зона.

DNS-записи, важные при работе с сервером

• A: соответствие имени IPv4-адресу. example.com. A 203.0.113.10. Эта запись указывает домен на ваш VPS.
• AAAA: соответствие имени IPv6-адресу, например 2001:db8::10. Публикуйте её только в том случае, если ваш сервис действительно ожидает соединений на этом адресе. Клиенты в сетях IPv6 сначала пытаются использовать ответ AAAA, поэтому адрес, на котором нет активного сервиса, вызывает задержку при каждом посещении.
• CNAME: псевдоним одного имени для другого. www.example.com. CNAME example.com. перенаправляет посетителей www на адрес, к которому разрешается основной домен. Запись CNAME не может находиться в корне зоны (основной домен example.com), так как корень должен содержать собственные записи SOA (start of authority) и NS, а CNAME не может сосуществовать с другими записями для одного и того же имени. Провайдеры предлагают обходные пути под названиями ALIAS, ANAME или CNAME flattening.
• MX: адрес доставки почты для домена. Содержит имя хоста и числовой приоритет; сначала опрашивается запись с меньшим числом. MX должен указывать на имя, у которого есть адресная запись. Указывать MX на CNAME некорректно, и некоторые почтовые серверы могут отклонить такую запись.
• TXT: произвольный текст, используемый для подтверждения прав и политик. Здесь размещаются записи аутентификации почты (SPF, DKIM, DMARC), а также токены ACME (automatic certificate management environment) для выпуска wildcard-сертификатов.
• NS: указывает, какие серверы имён обслуживают зону. Копия, определяющая, куда обращается внешний мир, находится в родительской зоне и управляется через делегирование у вашего регистратора, а не через копию внутри вашей собственной зоны.

Две детали вызывают больше путаницы, чем сами типы записей. Имя, заканчивающееся точкой, является абсолютным, поэтому www.example.com. означает именно это и ничего больше. Большинство панелей управления ожидают относительное имя и автоматически добавляют к нему домен, поэтому ввод www.example.com в поле имени даст вам www.example.com.example.com, которое ни для кого не разрешится. Другая деталь — @, что почти во всех панелях означает корень зоны: домен сам по себе, без поддомена.

Настройка A-записи для вашего VPS

Сначала узнайте IP-адрес вашего сервера, видимый из интернета:

curl -4 https://ifconfig.me
ip -brief -4 address show

Затем создайте запись у вашего DNS-провайдера: тип A, имя @, значение — полученный адрес, TTL (time to live) 300. Добавьте вторую запись для www: либо еще одну A с тем же адресом, либо CNAME, указывающую на основной домен.

Теперь проверьте разрешение имен, желательно с вашего локального компьютера, а не с самого сервера:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

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

Проблемы с разрешением имен

Успешное разрешение имени подтверждает работу DNS. Это не дает информации о состоянии вашего веб-сервера. Как только dig возвращает корректный адрес, проверьте соединение:

curl -I http://example.com

curl: (6) Could not resolve host: example.com указывает на проблему с DNS. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused не является проблемой DNS: имя было разрешено, пакет доставлен, следовательно, на данном порту нет активного процесса. Запрос, который зависает и завершается по таймауту, обычно означает, что межсетевой экран отбросил пакет без уведомления, вместо того чтобы отклонить его. На этом этапе DNS перестает быть предметом обсуждения, и в дело вступают порты и слушающие сокеты, а также правила межсетевого экрана ufw на вашем VPS. После установления соединения дальнейшая загрузка страницы выполняется средствами HTTP.

Почему браузер всё ещё показывает старый хост

Никакого распространения данных не существует. Ни один сервер не рассылает ваши изменения принудительно. Ваш авторитетный nameserver содержит новое значение сразу после сохранения, а каждая кэшированная копия предыдущего ответа остается валидной до истечения собственного таймера. Этот таймер — TTL (в секундах), который был указан в записи на момент её выдачи.

Копии хранятся в большем количестве мест, чем принято считать: в собственном кэше браузера, в stub resolver на локальной машине, в рекурсивном резолвере сети и в любом резолвере, установленном VPN-клиентом. Каждый из них хранит копию до истечения полученного TTL. Два пользователя в разных сетях могут часами видеть разные ответы, и обе системы при этом работают корректно.

Отслеживайте обратный отсчёт на кэширующем резолвере:

dig @1.1.1.1 example.com +noall +answer

Запустите команду дважды с интервалом в несколько секунд. TTL в ответе будет уменьшаться. Когда он достигнет нуля, резолвер удалит запись и снова обратится к вашему nameserver.

Существует второй тип кэша, который почти никто не учитывает: отрицательные ответы. Когда резолвер получает сообщение о том, что имя не существует, он кэширует этот NXDOMAIN на время, указанное в последнем поле записи SOA вашей зоны.

dig example.com SOA +short

Последнее число в этой строке — это отрицательный TTL, часто равный 3600. Поэтому попытка запросить staging.example.com до того, как вы создали запись, может скрыть её от вас на целый час после создания. Сначала создайте запись, затем делайте запрос.

Смена nameserver происходит медленнее, чем изменение записи, и причина здесь техническая. Делегирующие записи в зоне .com отдаются с TTL 172800 секунд, что составляет двое суток. Поэтому резолвер, закэшировавший ваши старые nameserver, может продолжать обращаться к ним в течение этого времени. Именно отсюда берется рекомендация «подождать до 48 часов». Она относится к смене nameserver, а не к обычному редактированию записей.

Планируйте миграцию с учётом TTL, а не вопреки ему:

1. Уменьшите TTL записи до 300 и сохраните изменения.
2. Подождите дольше, чем длился старый TTL, чтобы все кэшированные копии со старым значением истекли.
3. Измените адрес.
4. После того как трафик переключится, верните TTL на 3600 или выше, так как низкий TTL заставляет все резолверы обращаться к вашим nameserver гораздо чаще.

Чтобы очистить кэш на вашей собственной машине:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics выводит секцию кэша со счётчиками попаданий (hit) и промахов (miss), поэтому сразу после очистки следующий запрос будет отображаться как промах. Браузеры ведут отдельный кэш, поэтому Chrome может продолжать использовать старый ответ даже после очистки системного кэша. Очистите его по адресу chrome://net-internals/#dns. Также проверьте /etc/hosts, так как оставшаяся там строка имеет приоритет над DNS на этой конкретной машине. getent hosts example.com показывает ответ, который система будет использовать на самом деле, включая /etc/hosts.

Wildcard-сертификаты подтверждаются через TXT-запись

Центр сертификации (CA) проверяет контроль над именем перед выпуском сертификата. Проверка HTTP-01 предполагает размещение файла на порту 80 по конкретному имени хоста, что подходит для одного домена. Wildcard-сертификат охватывает *.example.com — неограниченный набор имен, для которых CA не может получить файл, поэтому Let's Encrypt выпускает wildcard-сертификаты только через проверку DNS-01. Вы публикуете TXT-запись по адресу _acme-challenge.example.com, содержащую токен от CA, и контроль над зоной служит доказательством владения.

Это делает ваш DNS-хостинг участником процесса обновления сертификатов. Certbot должен создавать и удалять эту TXT-запись при каждом обновлении без вашего участия, поэтому ему требуется API и соответствующий плагин для вашего провайдера. Если проверка завершается ошибкой, обычно выводится сообщение DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com. Это означает, что CA отправил запрос до того, как запись стала доступна: она либо не была сохранена, либо в кэше остался отрицательный ответ. Полная процедура описана в руководстве по wildcard-сертификатам с использованием проверки DNS-01.

Когда VPN перехватывает ваш резолвер

VPN-клиент (virtual private network) обычно подменяет системный резолвер на время подключения. Это необходимо, так как отправка запросов в локальную сеть раскрыла бы этой сети имена всех посещаемых вами сайтов. Это корректное поведение, однако оно может приводить к сбоям в двух направлениях.

Если туннель поднят, но имена перестали разрешаться, хотя доступ по IP-адресам работает, значит, резолвер, установленный клиентом, недоступен изнутри туннеля. ping 1.1.1.1 выполняется успешно, а curl https://example.com возвращает curl: (6) Could not resolve host: example.com. Если же туннель поднят, но запросы всё равно уходят в сеть, к которой вы подключены, ваш трафик проходит через туннель, но локальный резолвер продолжает видеть все имена, которые вы запрашиваете.

resolvectl status

Эта команда выводит резолвер, используемый для каждого соединения. Так вы сможете увидеть, какой из них установил туннель и является ли он тем, который вы планировали использовать. Туннель WireGuard задает этот параметр через строку DNS = в конфигурации клиента, а исправление DNS при перехвате резолвера через WireGuard подробно описывает случаи с systemd-resolved и resolvconf.

Коды ответов и их значения

• NXDOMAIN: авторитетный сервер сообщает, что имя не существует. Проверьте написание, отсутствие дублирующегося суффикса домена и убедитесь, что вы внесли изменения в ту зону, на которую указывает делегирование.
• NOERROR с пустым ANSWER SECTION: имя существует, но для него нет записи запрошенного типа. Запрос AAAA при наличии только A приводит именно к такому результату.
• SERVFAIL: резолвер попытался выполнить запрос, но не смог получить ответ. Две наиболее частые причины: авторитетные серверы не отвечают или произошел сбой проверки DNSSEC (domain name system security extensions). Протестируйте с помощью dig @1.1.1.1 example.com A +cd, что отключает проверку. Если ответ с +cd и SERVFAIL приходит без этой опции, значит, проблема в подписях; это случается после переноса сервера имен, когда родительская зона все еще публикует старую запись DS (delegation signer).
• REFUSED: сервер, к которому вы обратились, не будет отвечать на этот вопрос. Обычно это происходит, если вы направили dig на авторитетный сервер для домена, который он не обслуживает.
• ;; connection timed out; no servers could be reached: dig не смог связаться с резолвером. Это сетевая проблема или проблема резолвера на вашей стороне, домен здесь ни при чем.

ping: example.com: Temporary failure in name resolution — это тот же тип ошибки, сообщаемый glibc, а не утилитой dig.

Стоит ли запускать собственные DNS-серверы на VPS?

Вы можете это сделать. bind9, knot или nsd позволят обслуживать вашу зону прямо с сервера, что даст вам больше знаний о работе DNS, чем любая панель управления. Возражения носят практический характер. У домена должно быть как минимум два DNS-сервера в разных сетях, поэтому один VPS становится единой точкой отказа для всех сервисов домена, включая почту. DNS-серверы, названные внутри домена, который они обслуживают, требуют наличия glue records у регистратора — это IP-адрес ns1.example.com, хранящийся в родительской зоне, иначе процесс разрешения имен не сможет начаться. Если резолвер не может связаться с вашим DNS-сервером, он не переключается на ваш веб-сайт: весь домен становится недоступным для пользователя. Использование хостинг-провайдера DNS с API — выбор с меньшим риском для большинства пользователей. Запуск кэширующего резолвера на вашем VPS для собственных нужд — это другая задача, требующая гораздо меньших усилий.

FAQ

Почему мои изменения DNS еще не вступили в силу?

Никакого распространения (propagation) не существует. Авторитетные DNS-серверы содержат новое значение сразу после сохранения, а все резолверы, которые уже запрашивали запись, хранят её в кэше до истечения времени TTL. Запросите авторитетный сервер напрямую с помощью dig @ns1.your-dns-host.net example.com A +short. Если он возвращает новый адрес, значит, изменение активно, а задержка вызвана кэшированием. Если вы меняли сами DNS-серверы, а не записи, ожидайте более длительного процесса, так как делегирование на уровне TLD обычно имеет TTL в два дня.

Как узнать, какие DNS-серверы фактически использует мой домен?

dig example.com NS +short выводит DNS-серверы, отвечающие за домен в данный момент, а dig +trace example.com показывает цепочку делегирования от корневых серверов, включая записи, которые выдают серверы TLD. Если эти серверы не принадлежат провайдеру, в панели которого вы вносите правки, значит, проблема в этом. Либо редактируйте записи у провайдера, указанного в делегировании, либо измените делегирование у регистратора домена, чтобы оно указывало на нужные вам серверы.

Домен резолвится, но сайт не открывается. Что делать?

Работа DNS завершена, как только dig example.com A +short возвращает IP-адрес вашего сервера. После этого проблема заключается в сетевом соединении. Если curl -I http://example.com возвращает Connection refused, значит, на этом порту никто не слушает запросы. Если запрос «зависает» до истечения времени ожидания, значит, пакеты отбрасываются брандмауэром. Убедитесь, что веб-сервер запущен и привязан к публичному IP-адресу, затем проверьте локальный брандмауэр на сервере и внешний сетевой брандмауэр в панели управления вашего провайдера.

Почему я не могу создать CNAME для корневого домена?

Запись CNAME означает, что имя является псевдонимом для другого имени, и имя, имеющее CNAME, не может содержать никаких других записей. Ваш корневой домен обязан содержать записи SOA и NS, чтобы существовать как зона, поэтому он не может быть CNAME. Используйте запись A, содержащую IP-адрес для корня, либо воспользуйтесь функцией провайдера, которая называется ALIAS, ANAME или CNAME flattening: она сохраняет имя и отвечает на запросы тем адресом, в который это имя резолвится в данный момент.