Обзор

DNS Resolver отвечает на DNS‑запросы к вашему центру обработки данных on-premises и от него после того, как ваш центр обработки данных подключён к облаку через Direct Connect или VPN.

Как правило, центры обработки данных on-premises могут получать доступ к облачным ресурсам через соединение Direct Connect или VPN. Однако в целях безопасности серверам on-premises не разрешено напрямую обращаться к службе DNS в облаке. Если вашим серверам on-premises необходимо обращаться к частным доменным именам, используемым в VPC, или вашим облачным серверам требуется частный DNS для доступа к доменному имени on-premises, необходимо настроить DNS на облачных серверах для пересылки DNS‑запросов между облачным DNS и DNS on-premises. Это увеличивает затраты на управление и обслуживание и создает риски надёжности.

Как правило, поставщики облака используют IP‑адреса, начинающиеся с 100, для своих облачных сервисов, и IP‑адреса, начинающиеся с 10, 172 и 192, для вычислительных ресурсов. Когда сеть on-premises клиента подключается к нескольким сетям поставщиков облака, могут возникать конфликты IP‑адресов. Если ресурс on-premises или сторонний облачный сервис также использует IP‑адреса, начинающиеся с 100, необходимо добавить точный маршрут для каждого такого IP‑адреса в сети on-premises или в сети стороннего облака, чтобы предотвратить конфликты маршрутов. Это значительно увеличивает объём обслуживания. При наличии конфликтов IP‑адресов маршруты нельзя настроить.

DNS Resolver преобразует IP‑адреса, начинающиеся с 100, в частные IP‑адреса, используемые в VPC. Ресурсы on-premises могут напрямую обращаться к частным IP‑адресам VPC и им не требуется обращаться к IP‑адресам, начинающимся с 100, что значительно упрощает сетевую архитектуру. Если клиент использует Direct Connect или VPN для построения гибридного облака, ему достаточно создать входные и выходные эндпоинты и связать VPC с этими эндпоинтами для разрешения DNS‑запросов между сетью on-premises и VPC. Если DNS стороннего облака запрашивает доступ к доменному имени, размещённому в облаке, входные эндпоинты позволяют DNS‑запросам к VPC из этого стороннего облака. И наоборот, если виртуальная машина в облаке пытается получить доступ к доменному имени стороннего провайдера, настроенный выходной эндпоинт с правилами может пересылать DNS‑запросы в сеть on-premises или в то стороннее облако. Таким образом, сервисы on-premises и облака могут легко взаимодействовать друг с другом в сценариях гибридного облака.

• Входные и выходные эндпоинты не поддерживают DNSSEC.
• По умолчанию облачные серверы используют частный DNS для разрешения доменных имён. Не изменяйте адреса частного DNS. В противном случае правила пересылки не вступят в силу.

• Чтобы серверы on-premises могли получать доступ к доменному имени облачного сервиса, необходимо создать входной эндпоинт и настроить правила эндпоинта на DNS‑серверах on-premises для пересылки DNS‑запросов к доменному имени облачного сервиса на IP‑адреса, указанные во входном эндпоинте.

  Для получения подробной информации см. Managing Inbound Endpoints.

• Чтобы облачные серверы могли получать доступ к доменному имени on-premises, необходимо создать выходной эндпоинт и настроить правила эндпоинта, указывающие доменное имя on-premises, к которому требуется доступ, и IP‑адреса DNS‑серверов on-premises. Затем частный DNS пересылает DNS‑запросы к доменному имени on-premises на DNS‑серверы on-premises в соответствии с правилами эндпоинта.

  Для получения подробной информации см. Managing Outbound Endpoints.