DNS Inbound Endpoint: разрешение доменных имён облачных ресурсов с Yandex BareMetal

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

DNS Inbound Endpoint — это управляемая точка доступа к облачному DNS. Новая настройка приватной подсети Yandex BareMetal передаёт серверам адрес эндопинта или собственного DNS-резолвера через DHCP.

В статье рассмотрим два варианта на примере приложения, которое использует Yandex Managed Service for PostgreSQL, API на виртуальной машине и корпоративную CRM.

Исходная архитектура: BareMetal, VPC и корпоративная сеть

Ниже — наш пример, в котором компоненты размещены следующим образом:

• Основное приложение работает на сервере Yandex BareMetal.
• База данных размещена в Yandex Managed Service for PostgreSQL.
• Вспомогательный API запущен на виртуальной машине Yandex Compute Cloud.
• CRM и корпоративный DNS работают в корпоративной инфраструктуре.

Корпоративная инфраструктура может находиться на собственной площадке или в другом облаке. В нашем примере она подключена к Yandex Cloud через Yandex Cloud Interconnect. Сеть BareMetal, VPC и корпоративная сеть связаны приватной маршрутизацией через Yandex Cloud Interconnect и Yandex Cloud Router.

Почему сетевой связности недостаточно для DNS

Сервер Yandex BareMetal остаётся за пределами VPC даже после настройки Yandex Cloud Interconnect. Приватное соединение обеспечивает маршрутизацию, но не предоставляет ему тот же способ доступа к DNS, которым пользуются виртуальные машины (ВМ).

Штатный облачный DNS-резолвер доступен ВМ через специальный компонент виртуальной сети — VRouter-agent. Этот компонент недоступен извне ВМ. Поэтому просто указать адрес облачного DNS-резолвера в DNS-настройках сервера Yandex BareMetal недостаточно. Подробное описание этого механизма — в документации DNS-резолвера.

Корпоративный DNS тоже не разрешает приватные облачные имена после подключения сетей. Для таких запросов ему нужна доступная точка входа в облачный DNS.

Как решали задачу до DNS Inbound Endpoint

IP-адрес ресурса можно записать в конфигурацию приложения, а соответствие имени и адреса — в файл hosts. Но тогда адресные данные приходится поддерживать у потребителей: при изменении адреса базы или API нужно находить и обновлять все такие записи.

Для доступа к облачному DNS использовали отдельную виртуальную машину с DNS-форвардером внутри VPC. Сервер Yandex BareMetal отправлял запросы на её приватный адрес, а DNS-форвардер пересылал их штатному облачному DNS-резолверу.

DNS-форвардер работал внутри ВМ, поэтому мог пользоваться облачным DNS-резолвером. Обращаться к нему мог как сам сервер Yandex BareMetal, так и корпоративный DNS, пересылающий облачные запросы от своих клиентов.

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

Что дают DNS Inbound Endpoint и настройка DNS в Yandex BareMetal

DNS Inbound Endpoint предоставляет доступ к облачному DNS-резолверу из подключённых приватных сетей. Эндпоинт создаётся в выбранной VPC и использует зарезервированный внутренний IP-адрес из одной из её подсетей. Через него доступны приватные и сервисные DNS-зоны этой VPC.

Это позволяет заменить ВМ, которая использовалась только для входа в облачный DNS, управляемым подключением. В одной VPC можно создать один DNS Inbound Endpoint. Подключение других сетей само по себе не меняет доступность DNS-зон. Подробнее о входящих DNS-подключениях — в документации.

Новая настройка приватной подсети BareMetal централизованно задаёт, какой DNS будут использовать серверы в подсети.

Настройки DNS задаются отдельно для каждой приватной подсети BareMetal. Для использования DNS Inbound Endpoint VRF этой подсети должна быть связана с нужной VPC через Yandex Cloud Interconnect и Yandex Cloud Router, а само входящее DNS-подключение — создано в этой VPC с внутренним IP-адресом из одной из её подсетей. DNS-сервер можно задать двумя способами:

• INBOUND_ENDPOINT — выбрать существующее входящее DNS-подключение от Yandex Cloud DNS;
• MANUAL — указать IP-адрес пользовательского DNS-резолвера.

Таким образом, DNS Inbound Endpoint предоставляет точку доступа к облачному DNS, а настройка подсети передаёт серверам адрес выбранного DNS-сервера.

Параметры поступают при обновлении приватного интерфейса, используя DHCP option 6. Для автоматического применения интерфейс должен использовать DHCP, а ОС — принимать переданные через него DNS-настройки. Серверы со статической конфигурацией или отключённым получением DNS по DHCP нужно настроить отдельно.

Сначала рассмотрим доступ к облачным зависимостям приложения, затем добавим разрешение имени CRM через корпоративный DNS.

Два сценария подключения

BareMetal + облако: INBOUND_ENDPOINT

Приложение обращается к API на виртуальной машине и базе Yandex Managed Service for PostgreSQL. Для API в приватной зоне cloud.example, доступной выбранной VPC, создана A-запись api.cloud.example с внутренним адресом ВМ. Для Yandex Managed Service for PostgreSQL приложение использует FQDN — полное доменное имя хоста в зоне mdb.yandexcloud.net, предоставленное сервисом.

Оба имени разрешаются через облачный DNS. В настройках приватной подсети BareMetal выбираем INBOUND_ENDPOINT и указываем подключение в нужной VPC. После применения DNS-настроек сервер обращается к эндпоинту напрямую.

На примере API последовательность выглядит так:

FQDN Yandex Managed Service for PostgreSQL разрешается через тот же эндпоинт. После получения адреса приложение устанавливает соединение с базой по приватной сети.

Подробнее о том, как настроить DNS в приватной подсети — в документации.

BareMetal + облако + on-premises DNS: MANUAL

Теперь рассмотрим ту же инфраструктуру с корпоративной CRM.

В данном примере её имя crm.corp.example находится в зоне corp.example, которую обслуживает собственный DNS-сервер компании.

Прямого обращения к DNS Inbound Endpoint для этого имени недостаточно: Yandex Cloud DNS не поддерживает управляемую пересылку запросов к корпоративной зоне на on-premises DNS. Чтобы приложение на хосте Yandex BareMetal получало адреса всех трёх зависимостей, нужен пользовательский DNS-резолвер, который обрабатывает корпоративные запросы и пересылает облачные на эндпоинт.

В нашем примере эту роль выполняет существующий корпоративный DNS. В настройках приватной подсети BareMetal выбираем MANUAL и указываем его приватный IP-адрес. На самом DNS-резолвере настраиваем обработку зон:

Пересылка запросов по доменному суффиксу называется conditional forwarding. Запросы к остальным именам обрабатываются по действующей корпоративной DNS-политике.

Получив адрес, приложение подключается к API и Yandex Managed Service for PostgreSQL по маршруту в VPC, а к CRM — по маршруту в корпоративную сеть.

Если корпоративный DNS не поддерживает нужные правила, можно развернуть отдельный DNS-резолвер, например Unbound или CoreDNS. Он будет пересылать корпоративные запросы на корпоративный DNS, а облачные — на эндпоинт. В MANUAL в таком случае указывается адрес этого DNS-резолвера.

Примеры настройки пользовательского форвардера — в руководстве по интеграции корпоративного DNS с Yandex Cloud DNS.

Расположение самого сервиса не определяет выбор. Например, запись с приватным IP сервера on-premises можно хранить в Yandex Cloud DNS и получать через DNS Inbound Endpoint. В нашем примере MANUAL позволяет использовать существующую корпоративную зону без копирования её записей.

Как выбрать вариант:

Что меняется в эксплуатации

• Сокращается число компонентов для доступа к облачному DNS

  Эндпоинт позволяет убрать отдельную ВМ, которая только принимала внешние DNS-запросы и передавала их облачному DNS-резолверу. Вместе с ней уходят задачи по обновлению ОС и DNS-сервиса, мониторингу и резервированию этого посредника.

• Изменения DNS применяются на уровне подсети

  При смене DNS-сервера достаточно один раз обновить настройку в консоли Yandex Cloud приватной подсети для всех серверов BareMetal, использующих переданные по DHCP параметры.

• Имена зависимостей сохраняются при смене адресов

  Если команда заменит ВМ с API, она сможет обновить запись api.cloud.example, сохранив имя в конфигурации приложения.

  Для Yandex Managed Service for PostgreSQL можно использовать имена, которые предоставляет сам сервис. Например, FQDN у текущего мастера такой вид:

  c-<идентификатор_кластера>.rw.mdb.yandexcloud.net
  

  Он позволяет обращаться к мастеру без фиксации IP отдельного хоста.