Разработка гибридного решения системы доменных имен (DNS) с помощью Azure

Бастион Azure

Azure DNS

Azure ExpressRoute

Виртуальная сеть Azure

Правильное задание и проектирование ландшафта системы доменных имен (DNS) является критическим этапом реализации целевой зоны Azure. DNS должен работать во всей вашей инфраструктуре для поддержки потоков разрешения гибридных имен. Локальные системы должны иметь возможность разрешать домены, размещенные в Azure, а ресурсы Azure должны иметь доступ к доменам, локально размещенным. DNS также играет важную роль в Приватный канал Azure, который обеспечивает сетевую безопасность для платформы Azure как услуги (PaaS).

В этой архитектуре описывается проектирование гибридного решения DNS, разрешающего домены для рабочих нагрузок, размещенных в Microsoft Azure, локальной среде или в других облаках.

Архитектура

Скачайте файл Visio этого содержимого.

Рабочий процесс

В этом разделе объясняется, как работают потоки гибридного разрешения в двух основных случаях:

Рабочая нагрузка Azure пытается резолвить доменное имя для системы, размещенной на локальной площадке.
Локальная рабочая нагрузка пытается разрешить доменное имя для системы, размещенной в Azure.

Из Azure на локальный компьютер

Azure виртуальные машины могут потребоваться для доступа к локальным системам, таким как базы данных или приложения мониторинга. Они должны разрешать доменные имена, для которых авторитетные серверы являются локальными DNS-серверами. Этот поток имеет разные сценарии.

Рабочая нагрузка отправляет DNS-запрос на Брандмауэр Azure, так как IP-адрес Брандмауэр Azure (10.0.1.68) настроен как пользовательский DNS-сервер в виртуальной сети.
Брандмауэр Azure перенаправляет DNS-запрос в точку входящего соединения Azure DNS частного резольвера (10.1.0.68).
Если частный сопоставитель DNS находит совпадение в наборах правил, связанных с исходящими конечными точками, он перенаправит DNS-запрос на целевой объект, указанный в правиле, который должен быть локальными DNS-серверами.
Один из локальных DNS-серверов разрешает DNS-запрос.

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

Из локальной среды в Azure

Локальные системы могут потребовать разрешения имён для рабочих нагрузок, развернутых в Azure, или для частных конечных точек служб Azure PaaS. Это разрешение имен следует этому рабочему процессу.

Локальная рабочая нагрузка отправляет DNS-запрос на локальный DNS-сервер.
Локальный DNS-сервер перенаправит запрос на IP-адрес Брандмауэр Azure (10.0.1.68), основываясь на настроенных правилах условной пересылки.
Брандмауэр Azure перенаправит DNS-запрос на IP-адрес входящей конечной точки частного сопоставителя DNS (10.1.0.68).
Приватный резольвер DNS разрешает доменное имя, если оно соответствует одной из частных зон DNS Azure, которые связаны с его виртуальной сетью.

Компоненты

Локальная сеть представляет один центр обработки данных, который подключается к Azure через подключение Azure ExpressRoute или VPN. В этой архитектуре следующие компоненты составляют локальную сеть:
- DNS-серверы представляют один или несколько серверов, которые работают в качестве сопоставителя имен для локальных систем. Эти серверы необходимо настроить с помощью правил условной пересылки, которые отправляют DNS-запросы для систем Azure или частных конечных точек в входящую конечную точку для приватного DNS-резольвера. Наборы правил пересылки Azure DNS ссылаются на IP-адреса локальных DNS-серверов для доменов, размещенных локально.
- Локальный шлюз представляет либо устройство завершения VPN, либо маршрутизатор, который подключается к ExpressRoute и обеспечивает частное подключение к среде Azure.
Подписка на подключение представляет собой Azure подписку, используемую для ресурсов, которые обеспечивают сетевое подключение к рабочим нагрузкам, размещенным на Azure.
- Azure Virtual Network является основным строительным блоком для частных сетей в Azure. В этой архитектуре виртуальные сети подключаются к Azure ресурсам, таким как виртуальные машины, поддерживают взаимодействие с Интернетом и локальными сетями и используют подсети для упорядочивания ресурсов.
  - Виртуальная сеть концентратора — это центральная виртуальная сеть , в которую размещаются ресурсы подключения. В этой архитектуре она включает шлюзы виртуальной сети, Брандмауэр Azure, программно-определяемые WAN (SD-WAN) виртуальные сетевые устройства (NVA) и виртуальные устройства брандмауэра (NVA).
    - Подсеть шлюза — это выделенная подсеть, на которую размещаются шлюзы виртуальной сети. В этой архитектуре размещается VPN-шлюз Azure или ExpressRoute, который обеспечивает подключение к локальному центру обработки данных.
    - Подсеть Брандмауэр Azure — это выделенная подсеть с /26 сетевой маской, содержащая Брандмауэр Azure. В этой архитектуре брандмауэр Azure фильтрует трафик и предоставляет службы DNS-прокси. Дополнительные сведения см. в статье "Требования к размеру подсети брандмауэра Azure /26".
  - Виртуальная сеть общих служб — это виртуальная сеть, в которой размещаются ресурсы, предоставляющие службы нескольким рабочим нагрузкам. В этой архитектуре он размещает DNS-серверы и другие общие ресурсы. Если вы используете самоуправляемую архитектуру концентратора и периферийных узлов, вы можете переместить общие службы в виртуальную сеть концентратора, чтобы уменьшить количество прыжков пиринга между рабочими нагрузками и общими службами. При настройке маршрутизации не переопределите системный маршрут для адресного пространства концентратора в периферийных виртуальных сетях. Вместо этого примените определяемые пользователем маршруты только к определенным подсетям, которые должны достигать общих служб. Этот подход помогает предотвратить асимметричную маршрутизацию, особенно если брандмауэры находятся в пути. Дополнительные сведения см. в статье "Рабочая нагрузка виртуальной сети Концентратора".
  - Пиринг между двумя виртуальными сетями — это подключение между двумя виртуальными сетями, которое позволяет ресурсам обмениваться данными в частном порядке. В этой архитектуре пиринги подключают периферийные виртуальные сети к концентратору и предоставляют им подключение к остальной части среды. Настройте пиринг виртуальной сети для использования шлюза виртуальной сети (VPN или ExpressRoute) в концентраторе так, чтобы шлюз распространял префиксы IP-адресов виртуальной сети рабочих нагрузок и общих служб в локальную сеть.
- Частный сопоставитель DNS — это управляемая корпорацией Майкрософт служба, которая предоставляет разрешение DNS в Azure, включая условное перенаправление DNS-запросов на другие DNS-серверы. В этой архитектуре он обрабатывает разрешение DNS между Azure и локальными средами, не требуя управления базовой ОС. Частный резолвер DNS уже является высокодоступным, поэтому необходимо развернуть только одну инстанцию для каждого региона.
  - Наборы правил пересылки DNS — это коллекции правил, указывающие, какие домены имен перенаправляются на внешние DNS-серверы. В этой архитектуре наборы правил включают все локальные домены и IP-адреса локальных DNS-серверов в качестве целевых объектов пересылки. Вы связываете правила пересылки с виртуальными сетями для обеспечения внешнего разрешения DNS. На предыдущей схеме показана централизованная архитектура DNS для разрешения внешних имен с помощью частного сопоставителя DNS. Эта архитектура требует связывания набора правил пересылки с виртуальной сетью, в которой развертывается частный сопоставитель, в указанной архитектуре являющийся виртуальной сетью общих служб.
  - Подсеть входящей конечной точки: DNS-запросы к частному резолверу DNS должны направляться к IP-адресу его входящей конечной точки. Этот адрес настраивается в правилах пересылки на локальных DNS-серверах и в качестве DNS-сервера для брандмауэра Azure. Минимальный размер этой подсети /28. В этом примере используется /26 диапазон для масштабируемости в случае изменения минимального размера в будущем.
  - Подсеть исходящей конечной точки: Когда частный резолвер DNS должен пересылать DNS-запросы на внешние серверы на основе правил пересылки, эти запросы осуществляются из этой подсети. Минимальный размер для входящих и исходящих подсетей конечных точек составляет /28, но эта архитектура использует /26 для целей дополнительной гибкости в случае изменения ограничений. Дополнительные сведения см. в разделе "Ограничения подсети".
- VPN-шлюз — это шлюз виртуальной сети, который отправляет зашифрованный трафик между виртуальной сетью Azure и локальным расположением через общедоступный Интернет. Вы также можете использовать VPN-шлюз для отправки зашифрованного трафика между Azure виртуальными сетями через сеть Майкрософт. В этой архитектуре VPN-шлюз обеспечивает подключение между виртуальной сетью концентратора и локальным центром обработки данных.
- Шлюз ExpressRoute — это шлюз виртуальной сети, который подключает виртуальную сеть к каналу ExpressRoute, который является выделенным частным подключением с гарантированной пропускной способностью между корпорацией Майкрософт и локальной средой. В этой архитектуре он обеспечивает частное подключение между виртуальной сетью концентратора и локальной средой.
- Брандмауэр Azure — это облачная служба безопасности сети, которая проверяет сетевой трафик и фильтрует его на основе настроенных правил. В этой архитектуре он служит dns-прокси для поддержки полных правил сети доменных имен (FQDN) и ведения журнала DNS. Дополнительные сведения см. в статье "Dns-прокси брандмауэра Azure". Брандмауэр Azure не является доверенным сервером для dns-имени. Вместо этого он перенаправит все DNS-запросы к входящей конечной точке частного сопоставителя DNS, которая находится 10.1.0.68 в этом примере.
- Частные зоны DNS Azure — это контейнеры, в которых размещаются записи DNS для разрешения частных имен из связанных виртуальных сетей Azure. В этой архитектуре они предоставляют разрешение DNS для рабочих нагрузок Azure, поддерживают автоматическую регистрацию виртуальных машин и интегрируются автоматически с конечными точками приватного канала через каналы виртуальной сети DNS. Рекомендуется сегментировать зоны DNS в небольшие зоны, чтобы упростить администрирование и уменьшить область влияния.
Подписка на рабочую нагрузку с подключением представляет собой набор рабочих нагрузок, которые требуют виртуальной сети и подключения к локальной сети.
- Виртуальная сеть и подсеть для загрузок: Вы можете интегрировать рабочие нагрузки в моделях инфраструктуры как услуги (IaaS), такие как виртуальные машины или наборы для масштабирования виртуальных машин, а также ресурсы PaaS, такие как Azure SQL и Служба приложений Azure, в виртуальные сети.
- Рабочей нагрузки: В этом примере масштабируемый набор виртуальных машин или коллекция отдельных виртуальных машин размещает рабочую нагрузку в Azure, доступ к которым можно получить из локальной среды, Azure и общедоступного Интернета.

Альтернативы

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

Используйте виртуальную глобальную сеть Azure вместо автономного решения для концентратора и периферийной сети. В этой архитектуре виртуальный концентратор заменяет виртуальную сеть концентратора. Виртуальный концентратор — это управляемая корпорацией Майкрософт виртуальная сеть, которая поддерживает только определенные типы ресурсов. Она поддерживает брандмауэры (брандмауэры Azure и брандмауэры, отличные от Майкрософт), шлюзы виртуальной сети для VPN и ExpressRoute, а также SD-WAN NVAs. Для получения дополнительной информации см. интеграции сторонних производителей с виртуальным концентратором WAN.
Вам не нужно использовать Брандмауэр Azure в качестве DNS-прокси. Если вам не требуются сетевые правила Брандмауэр Azure на основе полного доменного имени (FQDN), или если вы используете не Microsoft сетевые виртуальные устройства (NVAs) в качестве брандмауэров, вы можете настроить виртуальные сети луча для использования частного сопоставителя DNS напрямую.
Консолидируйте общие ресурсы и виртуальные сети хаба. Вы можете развернуть частный сопоставитель DNS, DNS-серверы или другие общие ресурсы, такие как Бастион Azure или файловые ресурсы в узловой виртуальной сети. Этот подход работает только в том случае, если вы не используете виртуальную глобальную сеть. Если у вас есть брандмауэр Azure в виртуальной сети концентратора, будьте внимательны к маршрутизации из периферийных виртуальных сетей в подсеть общих служб. В UDR укажите только префикс подсети общих служб, а не весь диапазон виртуальной сети концентратора.
Используйте контроллеры домена Active Directory, которые работают на виртуальных машинах Azure в качестве DNS-серверов. В этом случае вы запускаете виртуальные машины контроллера домена в подписке идентификации, а контроллеры домена заменяют функциональные возможности частного резольвера DNS. Дополнительные сведения см. в статье "Развертывание служб домен Active Directory (AD DS) в виртуальной сети Azure.
Разверните пользовательское программное обеспечение DNS-сервера, например BIND, которое выполняется на виртуальных машинах вместо частного сопоставителя DNS. Этот параметр добавляет затраты на управление, но обеспечивает большую гибкость. Если ваша организация знакома с серверами с открытым исходным кодом, например BIND, вы можете использовать ту же технологию в Azure.
Используйте частный сопоставитель DNS для рабочих нагрузок, если у вас есть брандмауэр, отличный от Майкрософт, который не должен находиться в пути разрешения DNS для поддержки таких функций, как правила на основе FQDN. Настройте IP-адрес входящей конечной точки в качестве пользовательского DNS-сервера в виртуальной сети рабочей нагрузки или свяжите набор правил пересылки DNS с виртуальной сетью рабочей нагрузки. Затем настройте IP-адрес входящей конечной точки частного сопоставителя DNS в качестве целевой точки в локальных правилах условной пересылки DNS.
Группы безопасности сети (NSG) можно использовать в подсетях входящих и исходящих конечных точек для dns Private Resolver, но убедитесь, что они не блокируют DNS-запросы. Вы также можете применить UDR к этим подсетям для отправки трафика DNS через NVA, но убедитесь, что они не блокируют трафик DNS или проверки работоспособности Azure Load Balancer с внутреннего IP-адреса платформы Azure 168.63.129.16.
Вы можете использовать SD-WAN технологии вместо VPN или ExpressRoute, но базовая архитектура DNS не изменяется.

Многорегиональный дизайн

Рекомендуется распространять рабочие нагрузки по нескольким регионам, чтобы повысить их устойчивость к региональным катастрофическим событиям. Разрешение DNS следует тому же принципу. Если целевая зона платформы охватывает два или более регионов, разверните частный сопоставитель DNS в каждом регионе. В этой настройке локальные DNS-серверы должны использовать правила пересылки, которые включают брандмауэры (или частные точки входящего резолвера) обеих локаций, чтобы они могли продолжать разрешать имена Azure DNS во время регионального сбоя Azure.

Решите, следует ли использовать глобальные или региональные частные зоны DNS. Это решение напрямую соотносится с проектом Приватный канал.

Глобальные частные зоны DNS

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

Основным преимуществом этого дизайна является его простота и согласованность:

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

Этот подход также представляет некоторые компромиссы:

В катастрофическом Azure региональном сбое вы можете потерять административный доступ к некоторым частным зонам DNS. Приватные DNS-области являются глобальными ресурсами, но развертываются в ресурсной группе, ассоциированной с определённым регионом. Azure хранит метаданные для этой группы ресурсов в этом регионе. В маловероятном случае, когда Azure Resource Manager в этом регионе становится недоступным, возможно, вы не сможете получить доступ к частным зонам DNS для просмотра метрик или внесения административных изменений. Этот риск можно устранить с помощью модулей Runbook аварийного восстановления (DR), описывающих, как перестроить частные зоны DNS в другом регионе, если этот сценарий возникает.
Некоторые службы PaaS Azure, поддерживающие многорегиональный доступ, рекомендуют создавать несколько региональных частных конечных точек для одного домена. Это требование также означает, что вам потребуется одинаковое количество частных зон DNS. Ниже приведены примеры таких служб:
- Azure Cosmos DB:Соображения по переключению для учетных записей Azure Cosmos DB с частными конечными точками
- служба хранилища Azure (геоизбыточное):Переключение на резерв для учётных записей хранилища с частными конечными точками
Другие многорегиональные службы PaaS включают код региона в каждом домене региональной конечной точки, поэтому для них не требуется несколько зон DNS. Ниже приведены примеры таких служб:
- Хранилища служб восстановления в Azure Backup используют зону privatelink.{region}.backup.windowsazure.com.
- кластеры Azure Data Explorer используют зону privatelink.{region}.kusto.windows.net.

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

Региональные частные зоны DNS

В определенных ситуациях может потребоваться сохранить отдельные частные зоны DNS в каждом регионе.

Этот подход может показаться интуитивно понятным, но он представляет высокий уровень сложности:

Локальные серверы пересылки DNS запрашивают только один частный сопоставитель DNS для данного домена. В результате этот частный резолвер DNS должен разрешать все записи для зон, принадлежащих ему. Это требование означает, что все частные зоны DNS должны оставаться выровненными. Так как Azure частные зоны DNS не обеспечивают встроенную репликацию, необходимо самостоятельно реплицировать записи DNS. Эти записи можно реплицировать в конвейерах развертывания инфраструктуры с помощью инфраструктуры в качестве кода (IaC) или использовать сценарии после развертывания, поддерживающие согласованность зон DNS.
Если вам нужны разные зоны DNS для возврата разных записей, разрешение из локальной среды может быть не согласовано. Для более подробной информации, см. Соображения по переключению для учетных записей Azure Cosmos DB с частными конечными точками и Соображения по переключению для учетных записей хранилища с частными конечными точками. Не все DNS-серверы ведут себя одинаково при обработке правил пересылки, которые имеют более одного целевого DNS-сервера.
- Серверы BIND, использующие версию ранее 9.4, CoreDNS и Windows DNS-серверы осуществляют запросы к вышестоящим DNS-серверам по порядку. Они используют DNS-сервер, настроенный в правиле условной пересылки, только если все более ранние серверы в списке недоступны. В результате разрешение DNS для этих серверов предсказуемо в обычных условиях, так как они возвращают записи, настроенные в частной зоне DNS, ближе всего к локальному DNS-серверу.
  - В Windows Server 2012 была представлена функция динамического переупорядочивания пересылки, при которой сервер изменяет порядок пересылок на основе измеренных времен отклика. Это поведение можно отключить с помощью PowerShell (Set-DnsServerForwarder -EnableReordering $False) для обеспечения строгого последовательного использования указанного порядка.
  - CoreDNS по умолчанию использует распределение в циклически очередном порядке. Его можно настроить для использования детерминированного порядка, задав политику в подключаемом модуле пересылки sequential.
- Другие DNS-серверы, такие как современная BIND (версия 9.4 или более поздняя) и Infoblox, предпочитают серверы с наименьшей задержкой. Чтобы измерить время отклика, они отправляют часть DNS-запросов на все целевые серверы, настроенные в правилах пересылки. В результате некоторые локальные разрешения имен могут быть перенаправлены в другой регион Azure, который может вернуть другой IP-адрес и сделать локальное разрешение имен недетерминированным.
- Некоторые DNS-серверы, такие как dnsmasq, поддерживают параллельные запросы к нескольким серверам (с помощью --all-servers параметра) и используют ответ, поступающий первым. Это поведение также настраивается.

DNS-сервер перемещается на следующий сервер в списке целевых объектов пересылки, только если вышестоящий DNS-сервер недоступен. Он не перемещается, когда вышестоящий сервер возвращает NXDOMAIN (запрошенный домен не существует) или SERVFAIL (ошибка произошла во время процесса разрешения).

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

Обратная связь

Были ли сведения на этой странице полезными?