Yandex Cloud: В облачной сети неправильно разрешаются внутренние DNS-имена

  • Обновлено
  • Чтение ≈ 3 минуты

Краткий ответ

Внутри Virtual Private Cloud виртуальные машины неправильно разрешают приватные DNS-имена: один узел видит старый IP, другой получает NXDOMAIN, при этом прямое обращение к IP работает. Зона DNS, резолвер гостевой ОС и кеширование требуют раздельной проверки.

В этой статье
  1. Признаки неисправности и область применимости
  2. Почему это происходит
  3. Пошаговая диагностика и устранение
  4. Как проверить, что проблема исправлена
  5. Если проблема осталась

#Признаки неисправности и область применимости

Внутри Virtual Private Cloud виртуальные машины неправильно разрешают приватные DNS-имена: один узел видит старый IP, другой получает NXDOMAIN, при этом прямое обращение к IP работает. Зона DNS, резолвер гостевой ОС и кеширование требуют раздельной проверки.

#Почему это происходит

Возможная причинаКак узнатьЧто делать
Не та приватная зонаЧастная DNS-зона может быть связана не с той облачной сетью.Имя открывается снаружи, но не в нужной сетиПроверьте сеть и зоны.
Гостевая ОС использует иной DNSDHCP, systemd-resolved или вручную заданные резолверы меняют цепочку разрешения.Различаются ответы команды resolvectl и заданного сервераСравните DNS в конфигурации сети и ОС.
Старые ответы в кешеДанные могут сохраняться до истечения TTL на стороне клиента или промежуточного резолвера.Через время проблема пропадает без измененийСравните текущий авторитетный ответ и кеш.

#Пошаговая диагностика и устранение

  1. Запишите проверяемое имя и ожидаемый адресВыберите одно внутреннее полное доменное имя, запишите ожидаемый IPv4, сеть и каталог обеих ВМ. Уточните, используется ли Cloud DNS, собственный DNS-сервер или файловое сопоставление hosts. От этого зависит, где искать причину.
  1. Проверьте имя на проблемной ВМВ SSH-терминале проблемной Linux-ВМ выполните системный поиск адреса. Если возвращается несколько адресов, фиксируйте все; NXDOMAIN — отсутствие записи в выбранном DNS, а тайм-аут означает, что резолвер недоступен.
  2. Замените имя внутренним FQDN
    Linux · Терминал (Bash)Команда
    Замените имя внутренним FQDN. В Linux обычно доступно без администратора; вывод должен содержать ожидаемый IPv4.
    getent ahostsv4 internal.example.test
  1. Сравните используемые резолверыПроверьте список DNS-серверов и домены поиска. На Linux с systemd-resolved используйте resolvectl status, на других системах найдите настройки NetworkManager или DHCP. Не редактируйте напрямую /etc/resolv.conf, если им управляет другой компонент.
    Linux · Терминал (Bash)Команда
    Linux с systemd-resolved. Если команда отсутствует, проверьте cat /etc/resolv.conf и настройки сетевого менеджера; вывод только для чтения.
    resolvectl status
  1. Посмотрите настройку приватной зоныВ консоли откройте Cloud DNS, найдите приватную зону с нужным суффиксом и проверьте привязанные сети VPC. Убедитесь, что A-запись относится именно к имени, которое запрашивает клиент, а не к похожему поддомену; проверьте правильность IP и TTL.
  1. Проверьте доступность собственного DNSЕсли используете собственный DNS-сервер, сравните маршруты и группы безопасности между ВМ и DNS-сервером. Для большинства обычных DNS-запросов нужен UDP 53, при больших ответах и передаче зоны может применяться TCP 53. Не открывайте эти порты в публичный интернет.
  1. Сравните ответы с другой ВМНа заведомо работающей ВМ в той же VPC выполните такой же getent и сравните настройки резолверов. Если результат различается в одной сети, вероятнее проблема в гостевой конфигурации, кеше или локальной hosts-записи, а не в глобальной записи Cloud DNS.
  1. Устраните только подтверждённое расхождениеЕсли зона привязана не к той сети — исправьте привязку через консоль с резервной записью старой настройки. Если неправильный адрес в зоне — скорректируйте одну A-запись. Если отличается DNS-сервер гостевой ОС — исправьте его штатным сетевым менеджером в тестовое окно.
  1. Дождитесь TTL и перепроверьтеПовторите поиск имени с обеих ВМ после истечения указанного TTL. Не сбрасывайте кеш DNS целого кластера без необходимости: это создаст лавину запросов. Проверьте реальное подключение к нужному внутреннему сервису по FQDN.

#Как проверить, что проблема исправлена

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

#Если проблема осталась

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

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.