DNS — что это простыми словами и как домен находит сервер

Ты опубликовал приложение, купил красивый домен и ждёшь, что по нему сразу откроется сайт, но браузер сообщает об ошибке или показывает старую страницу. Чаще всего код здесь ни при чём: между доменным именем и сервером ещё нужно правильно настроить DNS. Разберём эту систему без сетевой магии — от первого запроса браузера до проверки записей вместе с Claude Code.

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

DNS — это система доменных имён, от английского Domain Name System. Её часто называют телефонной книгой интернета: человек помнит понятное имя сайта, а DNS находит связанный с ним технический адрес. Если тебе нужен короткий ответ на вопрос «DNS что это», то он звучит так: это распределённая система, которая превращает домен вроде snake.example.ru в IP-адрес сервера вроде 203.0.113.42.

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

Сравнение с телефонной книгой полезно, хотя и не описывает всех деталей. В контактах телефона имя «Анна» связано с номером, по которому можно позвонить. В DNS имя example.ru связано с одной или несколькими записями: адресом сервера, почтовым сервисом, подтверждением владения доменом и другими настройками. Сам домен при этом не хранит файлы сайта и не запускает приложение.

Когда в поиске спрашивают «DNS что это значит», обычно хотят понять роль DNS в открытии сайта. У браузера есть доменное имя, но нет маршрута к приложению. DNS возвращает данные, по которым браузер находит нужный сервер. Это похоже не на перевозку содержимого, а на выдачу адреса: посылка поедет позже и по другим протоколам.

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

Запрос «DNS сети что это» часто возникает в настройках роутера или подключения. Для домашней сети DNS — это служба, к которой устройства обращаются за преобразованием имён в адреса. Роутер может передавать запрос провайдеру или выбранному публичному резолверу. Это не отдельный интернет и не место, где лежит сайт: DNS лишь помогает найти узел, с которым затем будет установлено соединение.

У DNS нет одной центральной таблицы со всеми сайтами мира. Система распределена между множеством серверов и организаций. Благодаря этому владельцы доменов могут менять свои записи, доменные зоны обслуживаются независимо, а весь интернет не зависит от одного компьютера. За удобством привычной строки в браузере скрывается цепочка коротких запросов.

Полезно разделять четыре сущности:

• регистратор оформляет право использовать домен и даёт управлять его делегированием;
• DNS-хостинг хранит записи домена и отвечает на запросы о них;
• хостинг или сервер запускает приложение и отдаёт его файлы;
• браузер получает адрес через DNS, а потом обращается к серверу по HTTP или HTTPS.

Иногда регистратор одновременно предоставляет DNS-хостинг, поэтому обе настройки находятся в одной панели. Иногда приложение размещено на платформе, которая просит добавить DNS-запись у регистратора. Совпадение компаний не меняет логику: домен должен сообщать браузеру, где находится приложение.

Как проходит запрос, когда ты вводишь адрес сайта

Допустим, ты вводишь snake.example.ru и нажимаешь Enter. Снаружи всё занимает мгновения, но внутри участвуют браузер, несколько уровней кэша и DNS-серверы с разными обязанностями.

1. Браузер разбирает адрес

Сначала браузер отделяет доменное имя от остальных частей адреса. В строке https://snake.example.ru/game?level=2 доменом будет snake.example.ru, https обозначает протокол, /game — путь, а level=2 — параметр. DNS работает с доменным именем, а не со всем URL.

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

2. Устройство проверяет локальные данные

Если браузер не нашёл подходящий ответ, запрос передаётся операционной системе. У неё тоже есть DNS-кэш. Кроме того, система может учитывать локальный файл hosts, в котором имя вручную связывают с IP-адресом. Обычному пользователю менять этот файл не требуется, но старая тестовая строка в нём иногда объясняет, почему сайт только на одном компьютере открывается не там.

3. Запрос получает рекурсивный резолвер

Следующий участник — рекурсивный DNS-резолвер. «Рекурсивный» здесь означает, что он ищет окончательный ответ за клиента. Обычно адрес резолвера устройство получает от интернет-провайдера или роутера, но можно использовать и другую DNS-службу.

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

4. Резолвер обращается к корневым серверам

Если ответа в кэше нет, начинается поиск по иерархии. Резолвер спрашивает корневую систему DNS, где искать сведения о домене. Корневой сервер обычно не сообщает IP нужного сайта. Он направляет запрос к серверам доменной зоны верхнего уровня — например, зоны .ru или .com.

Корень можно сравнить со справочной, которая знает не адрес каждого дома, а нужный городской отдел. Такой подход позволяет распределить огромный каталог по уровням.

5. Сервер зоны верхнего уровня даёт следующую подсказку

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

Если запрашивается поддомен snake.example.ru, авторитетный сервер зоны example.ru ищет запись для имени snake. Он может вернуть IP-адрес, указать на другое имя через CNAME или сообщить, что записи не существует.

6. Авторитетный сервер возвращает ответ

Получив нужную запись, резолвер сохраняет её в кэше на разрешённое время и отдаёт устройству. Операционная система и браузер тоже могут временно запомнить результат. Затем браузер обращается к найденному IP-адресу, начинает сетевое соединение и запрашивает страницу по HTTPS.

Весь путь можно свернуть в одну вертикальную схему:

flowchart TB
    browser["Браузер пользователя"] --> cache["Локальный кэш DNS"]
    cache --> resolver["Резолвер провайдера"]
    resolver --> root["Корневой DNS-сервер"]
    root --> tld["Сервер доменной зоны"]
    tld --> auth["Авторитетный DNS-сервер"]
    auth --> ip["IP-адрес сайта"]

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

DNS-запрос отвечает лишь на часть пути. После него браузеру ещё нужно установить соединение, согласовать шифрование для HTTPS, отправить HTTP-запрос и получить HTML, стили, скрипты и изображения. Поэтому правильный DNS не гарантирует, что код приложения исправен, но без правильного DNS браузер не найдёт точку назначения.

Основные типы DNS-записей, которые встретит новичок

DNS-запись — строка данных в зоне домена. В ней обычно есть имя, тип, значение и TTL. Интерфейсы называют поля по-разному: вместо имени могут встретиться «хост», «поддомен» или Name, а корень домена часто обозначается символом @. Не копируй обозначение вслепую: документация регистратора объясняет, как именно его панель задаёт корневой домен.

При публикации первого приложения чаще всего встречаются шесть типов:

A: прямой путь к IPv4-адресу

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

Буква A не означает «главная запись». Это отдельный тип данных. Для корневого домена example.ru и поддомена www.example.ru обычно нужны отдельные записи или перенаправление на стороне платформы. Наличие A-записи для одного имени не создаёт автоматически все остальные варианты.

AAAA: адрес в IPv6

AAAA-запись выполняет ту же задачу для IPv6 — более нового формата сетевых адресов. Она состоит не из четырёх десятичных чисел, а из групп шестнадцатеричных символов. Добавлять AAAA «на всякий случай» нельзя: если запись существует, но сервер по этому адресу не отвечает, часть посетителей может получить ошибку, хотя IPv4 работает.

Если хостинг дал и IPv4, и IPv6 и просит использовать оба, обычно создают A и AAAA для одного имени. Если он дал только IPv4, достаточно A-записи. Решение должно опираться на параметры сервера или инструкцию платформы.

CNAME: одно имя ссылается на другое

CNAME полезен для платформ, где конечные IP-адреса контролирует провайдер. Вместо адреса вида 203.0.113.42 сервис выдаёт имя вроде project.hosting.example. Ты создаёшь CNAME для www или другого поддомена, а платформа может менять свои IP без твоего участия.

CNAME не является перенаправлением страницы. Браузер не переходит на другой URL и посетитель продолжает видеть твой домен. DNS лишь следует ссылке от одного имени к другому, чтобы в итоге получить адрес.

У корневого домена есть особые ограничения: классический CNAME нельзя безусловно совмещать с другими обязательными записями на том же имени. Некоторые DNS-хостинги предлагают похожие механизмы с другими названиями, но их поведение зависит от сервиса. Если платформа даёт отдельные рекомендации для example.ru и www.example.ru, следуй им и не заменяй типы по догадке.

TXT: служебный текст и подтверждение владения

TXT-запись часто появляется, когда платформа хочет убедиться, что домен действительно твой. Сервис выдаёт уникальную строку, ты помещаешь её в DNS, а сервис выполняет запрос и находит совпадение. Эта запись не направляет посетителя на сервер и не заменяет A или CNAME.

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

MX: маршрут для электронной почты

MX-записи сообщают, куда доставлять письма, адресованные домену. У них бывает приоритет: отправляющая система сначала пробует сервер с более предпочтительным значением, а затем резервные. Настройка сайта и настройка почты связаны общим доменом, но выполняют разные задачи.

Если ты публикуешь только «Змейку» и не заводишь почту на своём домене, менять MX не нужно. Ошибочная замена этих записей может остановить получение писем, не оказав никакой пользы сайту.

NS: кто отвечает за всю зону

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

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

Как привязать домен к своему приложению

Общая логика не зависит от названий кнопок у регистратора или хостинга. Меняются панели, формулировки и набор автоматических проверок, но связь всегда строится между доменом и точкой, где опубликовано приложение.

Шаг 1. Получи домен

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

Перед настройкой реши, какой адрес будет основным: корневой домен example.ru, вариант www.example.ru или поддомен вроде snake.example.ru. Можно поддерживать несколько вариантов, но один обычно выбирают главным, а остальные перенаправляют на него средствами платформы или веб-сервера.

Шаг 2. Узнай, какое значение ждёт хостинг

Открой документацию места, где работает приложение. Собственный VPS обычно требует A-запись на публичный IP. Облачная платформа или сервис статических страниц может выдать доменное имя и попросить CNAME. Иногда для корневого домена и www нужны разные записи.

Не проси ИИ угадать значение. IP-адрес, целевое имя и проверочный TXT должен выдать именно твой хостинг. Claude Code может объяснить инструкцию и проверить формат, но не знает параметры аккаунта, если ты их не передал.

Если приложение размещено на виртуальном сервере, пригодится материал про публикацию в Timeweb Cloud. Условия доступа и оплаты зависят от провайдера, поэтому актуальные тарифы смотри на сайте сервиса.

Шаг 3. Создай нужную DNS-запись

В активной панели DNS создают запись для выбранного имени:

• A — если хостинг дал IP-адрес сервера;
• CNAME — если платформа дала целевое доменное имя;
• TXT — дополнительно, если сервис проверяет владение доменом.

Вводить протокол и путь обычно не нужно. Значение A-записи — это IP, а не https://203.0.113.42/app. Значение CNAME — доменное имя, а не полный URL страницы. Если платформа показывает точный формат с завершающей точкой или без неё, используй её подсказку с учётом правил панели DNS.

Не создавай одновременно несколько вариантов «для надёжности». Лишняя A-запись может отправить часть пользователей на неправильный сервер. Лишняя AAAA — направить устройства по неработающему IPv6. Сначала выполни схему, которую поддерживает хостинг, затем проверь результат.

Шаг 4. Добавь домен на стороне платформы

Одной DNS-записи иногда недостаточно. Платформа должна знать, что запросы с этим доменным именем относятся к твоему проекту. Иначе трафик дойдёт до общего сервера, но сервер не поймёт, какое приложение показать.

Добавление домена на стороне хостинга также запускает проверку владения и подготовку HTTPS-сертификата. Названия разделов и последовательность действий меняются, поэтому точные шаги смотри в официальной документации выбранного сервиса.

Шаг 5. Подожди обновления и проверь ответ

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

Последовательность можно держать как короткий чек-лист:

• домен зарегистрирован;
• понятно, где находятся активные DNS-записи;
• хостинг сообщил IP или целевое имя;
• A либо CNAME создан без лишнего протокола и пути;
• домен добавлен к проекту на стороне хостинга;
• проверочная TXT-запись добавлена, если её запросил сервис;
• DNS отвечает ожидаемым значением;
• платформа выпустила сертификат и сайт открывается по HTTPS.

Пример: «Змейка» на своём домене вместо адреса GitHub Pages

Допустим, игра уже опубликована на GitHub Pages и открывается по техническому адресу, связанному с аккаунтом и репозиторием. Такой адрес рабочий, но собственный домен проще продиктовать, разместить на визитке и сохранить. Подготовка самого проекта и особенности публикации разобраны в материале про GitHub Pages и PWA.

Пусть ты хочешь открывать игру по адресу snake.example.ru. Сценарий состоит из двух встречных настроек:

1. На стороне GitHub Pages указываешь пользовательский домен для проекта. Так платформа узнаёт, что запросы к snake.example.ru нужно обслуживать файлами твоей «Змейки».
2. В DNS домена создаёшь запись, которая направляет snake на адрес, указанный платформой. Для поддомена это обычно CNAME, но точное значение и поддерживаемый вариант нужно взять из актуальной документации сервиса.

После сохранения DNS-записи платформа проверяет домен. Когда проверка проходит, она может подготовить сертификат, и игра начинает открываться по собственному HTTPS-адресу. Старый технический адрес при этом может продолжать работать — собственный домен становится ещё одним входом к тому же проекту.

Здесь легко перепутать три адреса:

• адрес репозитория показывает код и историю изменений;
• адрес GitHub Pages открывает опубликованную версию;
• собственный домен открывает ту же опубликованную версию через выбранное тобой имя.

DNS не копирует игру с GitHub и не хранит её файлы у регистратора. Он сообщает, что имя snake.example.ru связано с инфраструктурой платформы. Когда запрос приходит на эту инфраструктуру, настройка пользовательского домена помогает выбрать нужный проект.

Если после изменения показывается прежняя версия игры, сначала раздели две возможные причины. DNS мог сохранить старый адрес в кэше, либо GitHub Pages ещё отдаёт предыдущую сборку. Команда проверки DNS покажет, куда ведёт имя; открытие технического адреса поможет понять, обновилась ли сама публикация.

Почему изменения DNS видны не сразу

У каждой DNS-записи есть TTL — Time To Live, то есть срок жизни ответа в кэше. Значение сообщает резолверам, как долго можно использовать сохранённую копию, не спрашивая авторитетный сервер снова. Пока срок не истёк, один пользователь может уже получать новый IP, а другой — всё ещё старый.

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

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

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

Как проверить DNS через nslookup

nslookup доступен во многих системах и подходит для быстрой проверки. Передай ему домен без https:// и без пути:

nslookup snake.example.ru

В выводе найди адрес ответа. Если проверяешь A-запись, ожидаешь IPv4-адрес сервера. Команда может также показать, какой DNS-сервер выполнил запрос. Формат различается между операционными системами, поэтому важнее смысл полей, а не их положение.

Можно спросить конкретный публичный резолвер, чтобы сравнить результаты. Его адрес бери из официальной документации выбранной DNS-службы:

nslookup snake.example.ru <адрес-DNS-резолвера>

Если обычный запрос возвращает старый IP, а другой резолвер уже видит новый, вероятна разница кэшей. Если оба видят старое значение, проверь авторитетный источник и активные NS.

Как проверить DNS через dig

dig чаще встречается в Linux и macOS; в некоторых системах его нужно установить отдельно. Короткий запрос A-записи выглядит так:

dig snake.example.ru A

Для проверки других типов замени последний аргумент:

dig snake.example.ru CNAME
dig example.ru NS
dig example.ru TXT

В полном выводе dig полезны раздел ответа и число TTL. Краткий режим выводит только найденные значения:

dig +short snake.example.ru A

Пустой результат не всегда означает поломку всей DNS-системы. Возможно, у имени нет записи именно запрошенного типа. Например, прямой запрос CNAME ничего не покажет, если имя настроено через A.

Как отличить DNS-проблему от проблемы приложения

Проверяй уровни по очереди:

1. NS показывает ожидаемые авторитетные серверы.
2. A, AAAA или CNAME возвращает значение, которое дал хостинг.
3. Сервер принимает запросы для нужного домена.
4. HTTPS-сертификат выпущен и подходит этому имени.
5. Приложение отдаёт страницу без собственной ошибки.

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

Что попросить у Claude Code

Claude Code удобно поручить сбор фактов и объяснение вывода, не передавая ему управление аккаунтом регистратора. Например:

Проверь DNS для snake.example.ru командами nslookup и dig. Покажи отдельно A, AAAA, CNAME и NS, ничего не изменяй. Объясни простыми словами, какой ответ получен, какой TTL виден и есть ли конфликт записей. Не делай вывод о настройках панели, которых ты не видишь.

Для сравнения ожидаемого и фактического значения подойдёт более конкретная задача:

Хостинг сообщил, что snake.example.ru должен вести на <ожидаемое-значение>. Выполни только диагностические DNS-запросы и сравни результат. Если значение не совпадает, перечисли вероятные причины и команды для следующей проверки. Не меняй файлы проекта и системные настройки.

Угловые скобки здесь обозначают место, куда ты подставляешь данные своего хостинга. Не отправляй ИИ пароли, ключи доступа и содержимое секретных файлов. Для DNS-диагностики обычно достаточно публичного домена и ожидаемой записи.

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

DNS и HTTPS: почему сертификат появляется после привязки домена

DNS отвечает, где находится сервер, а HTTPS защищает обмен данными между браузером и этим сервером. Для HTTPS нужен цифровой сертификат, в котором указано доменное имя. Браузер проверяет, что сертификат выдан для открываемого адреса, не истёк и образует доверенную цепочку.

Когда платформа автоматически выпускает сертификат, ей сначала нужно подтвердить контроль над доменом. В типичном сценарии публикации она проверяет, что DNS-запись ведёт на её инфраструктуру, либо ищет выданную ею проверочную запись. Пока домен указывает на старый сервер или вообще никуда не ведёт, автоматическая проверка не проходит и сертификат для нового проекта не появляется.

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

HTTPS нельзя заменить одной DNS-записью. A или CNAME приводит посетителя к серверу, а сертификат позволяет установить защищённое соединение именно с этим доменом. Если DNS уже правильный, но сертификат ещё готовится, браузер может показывать предупреждение, ошибку соединения или временно не открывать HTTPS-версию.

Сертификат привязан к именам. Работающий сертификат для example.ru не всегда покрывает www.example.ru, а сертификат для технического адреса платформы не обязан подходить собственному домену. Оба варианта должны быть добавлены и подтверждены согласно правилам хостинга.

После выпуска сертификата сервер также должен перенаправлять посетителей с HTTP на HTTPS, если платформа не делает это сама. Общая схема и назначение шифрования подробнее разобраны в статье про SSL-сертификат для сайта.

Если сертификат долго не появляется, проверь не код приложения, а цепочку условий:

• нужный домен добавлен к правильному проекту;
• DNS возвращает адрес, который ожидает платформа;
• нет лишней A- или AAAA-записи на другой сервер;
• проверочная TXT-запись находится на правильном имени;
• у варианта с www есть собственная настройка, если он используется;
• в панели нет сообщения о незавершённой проверке.

Точные сроки выпуска и названия состояний зависят от сервиса. Актуальное описание процесса смотри в документации платформы.

Частые ошибки новичка при настройке DNS

DNS-зона выглядит как небольшая таблица, поэтому желание поменять несколько строк сразу понятно. Но каждая строка влияет на отдельную службу, а результат может задерживаться кэшем. Безопаснее менять только то, что относится к задаче, записывать прежние значения и проверять каждый уровень отдельно.

Запись всё ещё ведёт на старый IP

После переноса приложения новый сервер получает другой адрес, а A-запись остаётся прежней. Браузер честно идёт туда, куда указывает DNS, и показывает старую версию, заглушку хостинга или ошибку. Сравни результат nslookup или dig с IP из панели нового сервера.

Если в авторитетном DNS уже новый адрес, а локальный запрос возвращает старый, вероятен кэш. Если авторитетный сервер тоже отдаёт старый IP, запись изменена не там, не сохранена или для домена активны другие NS.

Забыли настроить www

example.ru и www.example.ru — разные DNS-имена. Запись для корня не обязана автоматически распространяться на www. В результате один адрес открывает сайт, а второй сообщает, что сервер не найден.

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

TXT добавили не на то имя

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

Другая ошибка — случайно изменить символы в проверочном значении. Такой текст обычно нужно копировать целиком, без добавленных кавычек или пробелов, если сервис не требует обратного. Не публикуй в TXT секреты: DNS-записи доступны извне.

Одновременно существуют две A-записи с разными адресами

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

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

Рабочая A-запись соседствует с ошибочной AAAA

Сайт отвечает по IPv4, но AAAA указывает на неработающий IPv6-сервер. Устройства и сети, предпочитающие IPv6, получают ошибку, тогда как остальные посетители ничего не замечают. Поэтому фраза «у меня открывается» ещё не доказывает, что все DNS-ответы верны.

Попроси ИИ проверить A и AAAA отдельно. Если хостинг не выдавал IPv6 и не требует AAAA, выясни происхождение записи и удали её только после подтверждения, что она не нужна.

Изменения внесены не на активных DNS-серверах

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

Запрос dig example.ru NS показывает, какие серверы считаются авторитетными. Сравни их с панелью, где редактируешь записи. Не меняй NS ради одной A-записи, если не планируешь переносить всю DNS-зону: при смене делегирования придётся воспроизвести также почтовые и проверочные записи.

В значение записи вставлен полный URL

В A-запись пытаются поместить https://example.ru, а в CNAME — адрес с /game. DNS не работает с протоколами и путями страниц. A ожидает IPv4-адрес, CNAME — другое доменное имя.

Адрес https://example.ru/game разбирается по слоям: DNS находит сервер для example.ru, HTTPS устанавливает защищённое соединение, а /game обрабатывает уже веб-сервер или приложение. Разделение слоёв помогает не искать настройку маршрута страницы в DNS-панели.

Старый ответ сохранился только на одном устройстве

Телефон через мобильную сеть уже видит новый сайт, а ноутбук через домашний Wi‑Fi — старый. Это похоже на ошибку записи, но часто объясняется разными резолверами и кэшами. Сравни DNS-ответы из обеих сетей, перезапусти браузер и дождись истечения TTL.

Очистка локального DNS-кэша иногда помогает, но команда зависит от операционной системы и её версии. Попроси Claude Code сначала определить систему и предложить безопасную диагностическую команду. Не сбрасывай все сетевые настройки только ради одной записи.

Удалены записи, которые казались лишними

При привязке сайта человек оставляет A и стирает MX, TXT или NS, чтобы «навести порядок». После этого сайт может заработать, но перестаёт приходить почта или ломается подтверждение другого сервиса. DNS-зона обслуживает не только веб-страницу.

Перед изменением сохрани список существующих записей без секретных данных и выясни назначение каждой. Добавление сайта редко требует удаления почтовых записей. Если инструкция хостинга просит заменить конкретную конфликтующую строку, меняй только её.

Частный DNS и защищённый DNS-трафик в телефоне — другая история

Пункты «Частный DNS» на Android и «защищённый DNS-трафик» в настройках устройств или приложений относятся к тому, как телефон отправляет свои DNS-запросы к резолверу: соединение может шифроваться с помощью технологий вроде DNS over TLS или DNS over HTTPS, чтобы посторонним в сети было сложнее читать или подменять запросы. Эти настройки не привязывают домен к твоему сайту, не создают A, CNAME или TXT и не заменяют панель DNS-хостинга; они действуют на стороне пользователя, тогда как публикация приложения требует изменить авторитетные записи домена. Если телефон пишет об ошибке частного DNS, это проблема его способа находить сайты, а не доказательство поломки DNS-зоны твоего проекта.

Короткий итог

DNS связывает понятное имя сайта с техническими данными, по которым браузер находит сервер. Для первого приложения тебе чаще всего понадобятся A-запись на IP или CNAME на имя платформы, иногда — TXT для подтверждения владения. MX отвечает за почту, NS — за обслуживание зоны, AAAA — за IPv6.

При сбое двигайся по цепочке: проверь активные NS, затем A, AAAA или CNAME, после этого привязку домена на хостинге и только потом приложение. Учитывай TTL и кэш, не создавай лишние записи и проси Claude Code показывать команды вместе с сырым результатом. Такой порядок помогает отделить ошибку адресации от проблемы сертификата или кода.

Частые вопросы

Можно ли открыть сайт без DNS?

Иногда сервер доступен по IP-адресу, но это не полноценная замена домену. Сервер может обслуживать несколько сайтов и выбирать нужный по имени, а HTTPS-сертификат обычно выпускается для домена. Пользователям тоже проще запомнить имя, чем набор цифр.

Чем DNS отличается от домена и хостинга?

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

Какую запись выбрать: A или CNAME?

Выбирай то, что указал хостинг. A нужна для прямой связи с IPv4-адресом, CNAME — для ссылки одного доменного имени на другое. Не создавай обе записи для одного имени, если платформа прямо этого не требует.

Почему сайт открывается у меня, но не открывается у другого человека?

Чаще всего устройства используют разные DNS-резолверы и кэши, поэтому временно получают разные ответы. Сравни результаты nslookup или dig, проверь TTL и убедись, что нет нескольких конфликтующих A- или AAAA-записей.

Нужно ли платить отдельно за DNS?

Регистратор или хостинг часто включает базовое управление DNS, но набор услуг зависит от компании. Отдельная DNS-служба тоже может иметь свои тарифы. Актуальные тарифы смотри на сайте сервиса.

Ускорит ли смена DNS обновление записи?

Не обязательно. Уже сохранённые ответы живут в кэшах до окончания TTL, а смена NS переносит обслуживание всей зоны и может создать новые ошибки. Для обычного изменения A или CNAME лучше проверить активную зону и дождаться обновления кэшей.