Microsoft AZ-700: Azure DNS и разрешение имен — Руководство по подготовке

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Часть Microsoft Azure Network Engineer AZ-700 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Azure DNS: общедоступные зоны, частные зоны и компромиссы

Azure предоставляет как хостинг общедоступных DNS, так и разрешение частных DNS-имен, тесно интегрированное с уровнем виртуальных сетей, и выбор между ними зависит от области применения, контроля, стоимости и операционных накладных расходов. Общедоступные зоны Azure DNS (размещенные в Azure DNS) подходят для имен, доступных из интернета, и выигрывают за счет глобальных anycast-конечных точек, предсказуемого управления через API и масштабирования по запросам. Частные зоны DNS позволяют создавать имена зон, которые разрешаются только в частные IP-адреса внутри связанных виртуальных сетей (VNet); они устраняют необходимость в запуске и обслуживании виртуальных машин с DNS для разрешения имен внутри Azure и поддерживают автоматическое управление записями при интеграции с определенными частными конечными точками PaaS. Основной компромисс — это контроль: пользовательские DNS-серверы (Windows DNS, BIND) предоставляют абсолютную гибкость — условную пересылку, расширенные политики и поведение SRV/CNAME, интегрированное с AD, — ценой накладных расходов на ВМ/управление и ответственности за отказоустойчивость. Выбор в плане производительности сводится к компромиссу между задержкой и стоимостью: управляемые службы Azure DNS сокращают объем обслуживания и обеспечивают глобальную скорость разрешения для общедоступных запросов, в то время как DNS-пересыльщики или устройства-распознаватели в центральной сети (hub) могут улучшить производительность гибридной среды и применять политики, но добавляют затраты на вычисления и обеспечение доступности. Распространенные ошибки включают в себя: забыть связать частную зону DNS с каждой VNet, которой требуется разрешение имен, не перенести делегирование при перемещении имен из локальной среды в Azure и ожидать автоматического поведения split-horizon (разделения DNS-горизонтов) для общедоступных и частных имен без явных DNS-записей или пересылки.

Azure DNS (общедоступный): глобальный anycast, управляемый API, оплата за зону/запрос.
Частные зоны DNS: разрешение имен в пределах VNet, автоматическое создание частных записей для поддерживаемых PaaS.
App Gateway WAF_v2: рекомендуется для современных функций WAF и модели масштабирования v2.
Azure Firewall (Standard/Policy): вариант централизованного DNS-прокси; увеличивает стоимость, но централизует политики.
Пользовательский DNS (на базе ВМ): максимальный контроль, более высокие затраты на эксплуатацию и доступность.

Частные зоны DNS, записи частных конечных точек и стратегии именования

Когда вы преобразуете общедоступные службы в частные конечные точки или переносите серверы в Azure, DNS становится точкой координации. Частные конечные точки регистрируют A-записи на уровне сетевого интерфейса (NIC) в частных зонах DNS, которые должны соответствовать общедоступному FQDN, который должны использовать клиенты; правильный подход — создавать частные зоны, которые зеркально отражают общедоступное пространство имен (например, contoso.com), или использовать специфичные для служб зоны privatelink (для платформенных сервисов), а затем либо включить автоматическую регистрацию, либо вручную создать записи A/CNAME, сопоставляющие FQDN с частным IP-адресом конечной точки. Область видимости имеет значение: связывание частной зоны с одной VNet ограничивает разрешение имен этой виртуальной сетью; архитектуры типа «звезда» (hub-and-spoke) требуют связывания зоны со всеми периферийными сетями (spokes) или использования DNS-пересылки из периферийных сетей на распознаватель в центральной сети. Типичная ошибка при миграции — оставить общедоступный DNS указывающим на старый локальный IP-адрес, в то время как клиенты Azure разрешают имя в частный IP-адрес; чтобы избежать путаницы (split-brain), планируйте четкие шаги переключения — обновляйте общедоступные записи только после проверки частного DNS и пересылки, или используйте именование split-horizon с явной частной зоной для того же имени. Сертификаты и заголовки хоста (host headers) должны совпадать: если вы ожидаете, что Application Gateway будет выполнять сквозное шифрование TLS с частным бэкендом, убедитесь, что CN/SAN сертификата бэкенда совпадает с именем хоста, которое шлюз отправляет в заголовке Host; в противном случае TLS-соединение с бэкендом не будет установлено.

Azure Private Resolver и шаблоны гибридного разрешения имен

Azure Private Resolver обеспечивает управляемую, масштабируемую пересылку DNS-запросов между виртуальными сетями Azure и локальными сетями без необходимости владеть виртуальными машинами с DNS. Шаблоны проектирования обычно предполагают размещение конечных точек распознавателя в центральной VNet (hub): входящие конечные точки получают запросы из локальной сети (через VPN/ExpressRoute) для частных зон Azure, а исходящие конечные точки пересылают запросы из Azure на локальные DNS-серверы для имен, используемых только внутри компании. Наборы правил распознавателя определяют условную пересылку для конкретных пространств имен (например, contoso.internal → IP-адреса локальных DNS) и могут быть связаны с VNet; для глобальных корпоративных развертываний управление правилами централизуется в центральной сети, а трафик из периферийных сетей направляется на центральный распознаватель через пиринг или маршрутизацию. Компромиссы между производительностью и стоимостью включают развертывание нескольких входящих конечных точек в разных регионах для отказоустойчивости и низкой задержки (что увеличивает стоимость) или использование конечных точек распознавателя в одном регионе с пирингом, но с более высокой межрегиональной задержкой. Распространенные ошибки: не обновить условные пересыльщики в локальной сети, чтобы они указывали на IP-адреса входящих конечных точек распознавателя, неправильно настроить правила групп безопасности сети (NSG), блокирующие DNS по портам TCP/UDP 53 к конечным точкам распознавателя, и предполагать, что предоставляемый Azure DNS (168.63.129.16) будет пересылать запросы в локальную сеть — для условной пересылки требуется явная настройка распознавателя.

DNS-порты: порты 53 UDP и 53 TCP должны быть разрешены для обычного разрешения имен и передачи зон.
Конечные точки распознавателя: развертывайте в центральных VNet; убедитесь, что NSG и брандмауэр разрешают входящий DNS-трафик.

Пользовательские DNS-серверы, DNS-прокси и операционные ловушки

Пользовательские DNS-серверы (контроллеры домена Windows DNS или Linux BIND) по-прежнему актуальны, когда требуется интеграция с Active Directory, сложная условная переадресация или расширенные политики DNS; однако они влекут за собой операционные обязанности: установку исправлений, кластеризацию для обеспечения высокой доступности, резервное копирование и масштабирование. Альтернативы, снижающие операционную нагрузку, — это зоны Azure Private DNS для разрешения имен внутри Azure и Azure Private Resolver или DNS-прокси Azure Firewall для централизации политик переадресации. DNS-прокси (функция DNS-прокси в Azure Firewall или сторонние NVA) могут перехватывать и перенаправлять DNS-запросы на выбранные сопоставители, что упрощает управление политиками и ведение журналов, но может создавать единые точки отказа и вносить дополнительную задержку. Ключевые проектные решения включают выбор между использованием переадресаторов на базе ВМ в концентраторе (ниже стоимость, выше затраты на обслуживание) и Azure Private Resolver (управляемый сервис, лучше масштабируется), сколько конечных точек сопоставителя развертывать в разных регионах для обеспечения низкой задержки и отказоустойчивости, а также стоит ли включать автоматическую регистрацию DNS для частных конечных точек. Частые ошибки инженеров — это расчет на один лишь пиринг виртуальных сетей для разрешения DNS (пиринг не обеспечивает автоматический доступ к зонам Private DNS), отсутствие разрешений у Private Endpoint на автоматическую регистрацию DNS-записей и пренебрежение проверкой цепочек сертификатов при реализации сквозного TLS через шлюз — все это приводит к сбоям в разрешении имен или нарушению безопасных соединений в рабочей среде.

Практическая задача: пример использования

Сценарий: компания Fabrikam Inc. использует многорегиональную сетевую архитектуру «звезда» в Azure. Концентратор в регионе East US содержит Azure Firewall (Standard), а профиль Traffic Manager направляет интернет-пользователей на экземпляры Application Gateway WAF_v2 в двух регионах. Два экземпляра App Service, на которых размещен сайт www.fabrikam.com, перенесены из локальной среды и имеют частные конечные точки в своих региональных периферийных сетях.

Задача: после миграции локальные клиенты и периферийные сети Azure должны разрешать имя www.fabrikam.com в IP-адреса частных конечных точек App Service, Application Gateway должен сохранять заголовки узла для обеспечения сквозного шифрования TLS, а разрешение DNS должно быть отказоустойчивым между регионами.

Рекомендуемый подход:

Разверните в концентраторе зону Azure Private DNS с именем fabrikam.com и свяжите ее с обеими региональными периферийными виртуальными сетями и виртуальной сетью концентратора; добавьте A-записи для www.fabrikam.com, указывающие на IP-адреса частных конечных точек (или включите автоматическую регистрацию для частных конечных точек App Service).
Разверните в концентраторе входящие конечные точки Azure Private Resolver (по одной на регион для отказоустойчивости, если необходимо) и настройте локальные серверы условной пересылки на отправку запросов для fabrikam.com на IP-адреса входящих конечных точек сопоставителя.
Настройте параметры HTTP в Application Gateway WAF_v2 для использования HTTPS по порту 443, установите заголовок узла для серверной части на www.fabrikam.com и убедитесь, что пробы работоспособности серверной части используют HTTPS с заголовком узла, соответствующим CN/SAN сертификата.
Для проверки выполните DNS-запросы из локальной среды и из периферийных сетей, чтобы убедиться, что они возвращают частные IP-адреса, и проверьте сквозное шифрование TLS в Application Gateway, проанализировав CN/SAN сертификата и успешность проб работоспособности.

Обоснование: централизация функциональности частного DNS и сопоставителя в концентраторе обеспечивает единый источник достоверных данных и упрощает гибридную условную пересылку; связывание частной зоны со всеми виртуальными сетями и обеспечение использования шлюзом правильного заголовка узла сохраняет проверку сертификата для сквозного шифрования TLS, обеспечивая баланс между управляемостью, производительностью и отказоустойчивостью.

← Гибридные сети · Все домены · Сетевая безопасность →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →