Домен куплен, запись создана, прошло десять минут — сайт не открывается. Следующие два часа обычно уходят на то, чтобы создать ещё три записи, удалить две, поменять их местами и в итоге сделать хуже.
В большинстве таких случаев домен работает. Не работает ваша проверка: браузер держит кэш, операционная система держит кэш, провайдерский резолвер держит кэш, и все трое отвечают вам старым значением. Ниже — как отличить настоящую поломку от кэша, какие записи вообще нужны и что проверять после каждого изменения.
#Что понадобится
- Домен и доступ к панели управления его записями. Панель может быть у регистратора, у хостинга или у отдельного DNS-провайдера — это три разных места, и путаница между ними даёт четвёртую типовую ошибку.
- Адрес сервера. Если сервиса ещё нет — начните с выбора VPS под личный ИИ-сервис.
- Утилита
dig(Linux, macOS) илиResolve-DnsName(Windows).
#Шаг 1. Понять, где на самом деле управляются записи
Первая ошибка, которую совершают почти все: записи правятся не там.
У домена есть делегирование — список серверов имён, которые считаются источником истины по этому домену. Он задаётся у регистратора. Панель хостинга тоже показывает записи и позволяет их менять — но её изменения ни на что не влияют, если делегирование указывает на другого провайдера.
# кто на самом деле отвечает за домен
dig NS example.com +short
Если в ответе не те серверы, чью панель вы редактируете, — вы правите записи, которых никто не спрашивает. Это чинится до всего остального.
#Шаг 2. Создать нужные записи и не создавать лишних
| Тип | Что задаёт | Когда нужен |
|---|---|---|
A |
адрес IPv4 | всегда, если у сервера есть IPv4 |
AAAA |
адрес IPv6 | если сервер доступен по IPv6 |
CNAME |
псевдоним другого имени | для поддоменов, указывающих на чужое имя |
MX |
почтовые серверы домена | если домен принимает почту |
TXT |
произвольный текст | подтверждение владения, почтовые политики |
Минимум для веб-сервиса — одна запись A на корень домена и одна на www (либо A, либо CNAME на корень). Всё.
Правила, нарушение которых даёт странные симптомы:
CNAMEне может стоять рядом с другими записями того же имени. Классика —CNAMEна корне домена: там уже естьNSиSOA, поэтому по стандарту так нельзя. Часть провайдеров предлагает свои обходные механизмы; если ваш не предлагает — на корне ставитсяA.AAAAбез работающего IPv6 хуже, чем отсутствиеAAAA. Клиент с IPv6 попробует его первым и будет ждать таймаута. Симптом — «у некоторых сайт открывается медленно или через раз».- Запись
Aна туннель бессмысленна: у туннеля нет вашего адреса, там нуженCNAMEна выданное имя — и это одно из ограничений, разобранных в статье про туннели вместо белого IP.
#Шаг 3. Разобраться с задержкой, а не бороться с ней
Изменение записи не распространяется мгновенно, и это не «капризы DNS», а прямое следствие кэширования по времени жизни записи (TTL).
Механика простая: вы указали для записи время жизни, скажем, 3600 секунд. Резолвер, который уже спросил старое значение, будет отдавать его из кэша ещё до часа. Уменьшение времени жизни сейчас на этот кэш не влияет — новое значение узнают только те, кто спросит после его протухания.
Отсюда единственный рабочий приём: уменьшать время жизни заранее. За сутки до планируемой смены адреса поставьте 300 секунд, дождитесь, пока старое значение протухнет у всех, меняйте запись, а после подтверждения — верните обратно 3600.
Верхняя оценка ожидания без такой подготовки — прежнее время жизни записи плюс запас. Разговоры про «до 48 часов» относятся к смене делегирования, а не к смене обычной записи.
#Шаг 4. Проверять правильно
Здесь и прячется вторая типовая ошибка: проверять браузером.
# 1. что отдаёт АВТОРИТЕТНЫЙ сервер (мимо всех кэшей)
dig @$(dig NS example.com +short | head -1) example.com A +short
# 2. что отдаёт публичный резолвер
dig @1.1.1.1 example.com A +short
# 3. что отдаёт ваш провайдер
dig example.com A +short
# 4. сколько ещё жить кэшу
dig example.com A | grep -A1 'ANSWER SECTION'
Читать это надо так: пункт 1 — истина, пункты 2 и 3 — состояние распространения. Если в первом уже новый адрес, а в третьем старый, — вы всё сделали правильно и ждёте, ничего больше менять не надо. Именно на этом месте люди начинают «чинить» рабочую конфигурацию.
Windows-вариант:
Resolve-DnsName example.com -Type A -Server 1.1.1.1
Clear-DnsClientCache # локальный кэш ОС
Третья типовая ошибка — забыть, что кэш есть и у браузера, причём отдельный от системного. Проверяйте dig, а не адресной строкой.
#Чек-лист проверки после изменения
dig NS— делегирование указывает на ту панель, где вы правили.dig @<авторитетный>— новое значение видно у источника.dig @1.1.1.1— публичный резолвер уже подхватил.- Локальный кэш очищен,
digс вашего провайдера отдаёт новое. curl -I http://example.com/— приходит ответ вашего сервера, а не заглушка регистратора.curl -I https://example.com/— сертификат соответствует имени. Если ещё нет — это следующий шаг, HTTPS и автопродление.- Проверка с мобильного интернета — другой резолвер, другой кэш, честная вторая точка зрения.
Критерий приёмки — пункты 1, 2 и 5. Пункты 3 и 4 могут быть красными ещё какое-то время, и это нормальное состояние, а не поломка.
#Что может пойти не так
Открывается страница-заглушка регистратора. Записи правятся не там, где делегирование, — см. шаг 1. Либо запись A осталась указывать на парковку.
Домен открывается у вас и не открывается у знакомого. Распространение ещё идёт. Проверьте у авторитетного сервера: если там новое значение — просто ждите.
Всё правильно, но соединение не устанавливается. DNS свою работу сделал: имя превратилось в адрес. Дальше вопросы к межсетевому экрану, к тому, слушает ли приложение внешний интерфейс, и к прокси — про его настройку в гайде про обратный прокси перед ИИ-сервисом.
Поддомен работает, корень — нет (или наоборот). Это две разные записи. www и корень настраиваются отдельно, и перенаправление между ними делает веб-сервер, а не DNS.
После смены адреса часть пользователей идёт на старый сервер. Прежнее время жизни ещё не истекло. Не гасите старый сервер сразу — пусть отвечает перенаправлением, пока кэши не обновятся.
Почта перестала ходить после правки записей. Задели MX или TXT. Записи веб-сервиса и почты живут в одной зоне, и «почистить лишнее» — верный способ отключить почту на домене.
#Частые вопросы
#Сколько на самом деле ждать после изменения записи?
Столько, сколько было указано в её времени жизни до изменения, плюс небольшой запас. Если было 3600 — до часа. Уменьшать время жизни имеет смысл до изменения, после — уже поздно.
#Нужен ли отдельный DNS-провайдер или хватит панели регистратора?
Для личного сервиса хватит регистратора. Отдельный провайдер даёт больше типов записей, API для автоматического подтверждения сертификатов и обычно быстрее применяет изменения. Второй пункт становится существенным, если вы используете DNS-подтверждение при выпуске сертификата.
#Можно ли указать домен на домашний компьютер?
Можно, если у вас статический публичный адрес. При динамическом адресе нужен клиент динамического DNS, который обновляет запись при смене адреса; за NAT без публичного адреса домен сам по себе не поможет — нужен туннель.
#Что писать в записи, если сервис за туннелем?
Псевдоним (CNAME) на имя, которое выдал провайдер туннеля. Собственный адрес сервера при этом наружу не публикуется — что одновременно и плюс, и ограничение: сроком жизни сертификата и стабильностью имени управляет провайдер.
#Обязательно ли заводить www?
Не обязательно, но привычка пользователей сильнее ваших предпочтений. Заведите обе записи и настройте перенаправление на выбранный вариант — какой именно, значения не имеет, важна согласованность.
#На каком этапе всё это делается?
Домен — четвёртый этап маршрута о том, как поднять свой ИИ-сервис, вместе с сертификатом. Раньше делать его смысла нет: домен на сервисе, который не переживает перезагрузку, — это красивая ссылка на страницу с ошибкой соединения.