Настройка разрешения DNS-имен для виртуальных сетей Azure

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

Если для ресурсов, развернутых в виртуальных сетях, требуется разрешение доменных имен во внутренние IP-адреса, это можно сделать с помощью одного из четырех методов:

• Частные зоны DNS Azure
• разрешение имен, предоставляемое Azure
• Разрешение имен, использующее собственный DNS-сервер (который может перенаправлять запросы на DNS-серверы, предоставляемые Azure).
• Частный резолвер DNS Azure

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

Частные зоны DNS Azure являются предпочтительным решением и позволяют гибко управлять вашими зонами и записями DNS. Дополнительные сведения см. в статье Использование Azure DNS для частных доменов.

разрешение имен, предоставляемое Azure

Разрешение имен, предоставленное Azure, предоставляет только базовые базовые возможности DNS. Azure управляет именами и записями зон DNS, если используется DNS, предоставляемый Azure. Вы не можете управлять именами зон DNS или жизненным циклом записей DNS. Если вам требуется полнофункциональное решение DNS для ваших виртуальных сетей, вы можете использовать зоны Azure Частная зона DNS с DNS-серверами под управлением клиента или Azure DNS Private Resolver.

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

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

Features

Разрешение имен, предоставляемое Azure, включает следующие функции.

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

Considerations

При использовании разрешения имен, предоставленных Azure, рассмотрите следующие моменты:

• Суффикс DNS, созданный в Azure, нельзя изменить.
• Поиск по DNS ограничивается виртуальной сетью. DNS-имена, созданные для одной виртуальной сети, не могут быть разрешены из других виртуальных сетей.
• Регистрация собственных записей вручную запрещена.
• WinS и NetBIOS не поддерживаются. Виртуальные машины не отображаются в проводнике Windows.
• Имена узлов должны быть совместимыми с DNS. Имена должны использовать только цифры от 0 до 9, буквы a до z и дефис (-). Имена не могут начинаться или заканчиваться дефисом.
• Трафик запросов DNS ограничивается для каждой виртуальной машины. Регулирование не должно влиять на большинство приложений. Если вы наблюдаете ограничение запросов, убедитесь, что кэширование на стороне клиента включено. Для получения дополнительных сведений ознакомьтесь с разделом Настройка клиента DNS.
• Для каждой виртуальной машины в виртуальной сети необходимо использовать другое имя, чтобы избежать проблем с разрешением DNS.
• Для каждой виртуальной сети в классической модели развертывания регистрируются только виртуальные машины в первых 180 облачных службах. Это ограничение не применяется к виртуальным сетям в Resource Manager.
• Сервер Azure DNS использует IP-адрес 168.63.129.16. Этот адрес является статическим IP-адресом и не изменяется.

Вопросы, касающиеся обратного DNS

Обратный DNS для виртуальных машин поддерживается во всех виртуальных сетях на основе Resource Manager. Обратная DNS, управляемая Azure, также известная как указатель (PTR), записи формата \[vmname\].internal.cloudapp.net автоматически добавляются в DNS при запуске виртуальной машины. Они удаляются при остановке виртуальной машины (деассоциирования). См. следующий пример.

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.cloudapp.net

Обратная internal.cloudapp.net зона DNS управляется Azure и не может быть непосредственно просмотрена или изменена. Прямой поиск полного доменного имени в формате \[vmname\].internal.cloudapp.net разрешает IP-адрес, назначенный виртуальной машине.

Если зона частного DNS Azure связана с виртуальной сетью с помощью ссылки виртуальной сети и в этой ссылке включена авторегистрация, то обратные запросы DNS возвращают две записи. Одна запись является формой \[vmname\].[privatednszonename] , а другая — формой \[vmname\].internal.cloudapp.net. См. следующий пример.

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

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

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

Обратные записи DNS (PTR) не хранятся в частной прямой зоне DNS. Обратные записи DNS хранятся в обратной зоне DNS (in-addr.arpa). Обратная зона DNS по умолчанию, связанная с виртуальной сетью, недоступна для просмотра или редактирования.

Вы можете отключить обратную функцию DNS в виртуальной сети. Создайте собственную зону обратного поиска с помощью зон Azure Частная зона DNS. Затем свяжите эту зону с виртуальной сетью. Например, если ip-адрес виртуальной сети равен 10.20.0.0/16, можно создать пустую частную зону 20.10.in-addr.arpa DNS и связать ее с виртуальной сетью. Эта зона переопределяет зоны обратного поиска по умолчанию для виртуальной сети. Эта зона пуста. Обратный DNS выводит NXDOMAIN, если вы не создадите эти записи вручную.

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

Настройка клиента DNS

В этом разделе рассматривается кэширование на стороне клиента и повторение операций на стороне клиента.

Кэширование на стороне клиента

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

По умолчанию dns-клиент Windows имеет встроенный кэш DNS. Некоторые дистрибутивы Linux по умолчанию не включают кэширование. Если локальный кэш отсутствует, включите кэш DNS на каждой виртуальной машине Linux.

Доступны множество различных пакетов кэширования DNS (например dnsmasq, ). Вот как установить dnsmasq в наиболее распространенных дистрибутивах:

sudo apt-get install dnsmasq

Повторные попытки на стороне клиента

DNS в основном является протоколом пользовательской диаграммы данных (UDP). Так как протокол UDP не гарантирует доставку сообщений, логика повторных попыток обрабатывается в самом протоколе DNS. Каждый DNS-клиент (ОС) может реализовывать разную логику повторных попыток в зависимости от предпочтений создателя.

• Операционные системы Windows выполняют повторную попытку через одну секунду, затем через две и четыре, а затем еще через четыре секунды.
• Повторные попытки в ОС Linux по умолчанию выполняются через пять секунд. Мы рекомендуем изменить настройки повторных попыток на пять раз с интервалом в одну секунду.

Проверьте текущие параметры на виртуальной машине Linux в файле cat /etc/resolv.conf. Посмотрите на options строку, например:

options timeout:1 attempts:5

Файл resolv.conf создается автоматически и не должен быть изменен. Конкретные шаги по добавлению options строки зависят от распределения.

Разрешение имен с помощью собственного DNS-сервера

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

Виртуальные машины и экземпляры ролей

Ваши требования к разрешению имен могут выйти за рамки возможностей Azure. Например, может потребоваться использовать домены Windows Server Active Directory для разрешения DNS-имен между виртуальными сетями. Для покрытия этих сценариев можно использовать собственные DNS-серверы.

DNS-серверы в виртуальной сети могут перенаправлять запросы DNS на рекурсивные сопоставители в Azure. С помощью этой процедуры можно разрешить имена узлов в этой виртуальной сети. Например, контроллер домена (DC), запущенный в Azure, может отвечать на запросы DNS для своих доменов и перенаправлять все остальные запросы в Azure. Перенаправление запросов позволяет виртуальным машинам просматривать локальные ресурсы (через контроллер домена) и имена узлов, предоставляемые Azure (через сервер пересылки). Доступ к рекурсивным сопоставителям Azure предоставляется через виртуальный IP-адрес 168.63.129.16.

Перенаправление DNS также обеспечивает разрешение DNS между виртуальными сетями и позволяет локальным компьютерам разрешать имена узлов, предоставляемые Azure. Чтобы определить имя хоста виртуальной машины, DNS-сервер должен находиться в той же виртуальной сети и быть настроен на перенаправление запросов имен в Azure. Так как DNS-суффиксы в разных виртуальных сетях различаются, можно использовать правила условного перенаправления для отправки запросов DNS в правильную виртуальную сеть для разрешения.

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

! [Схема, показывающая DNS между виртуальными сетями](./media/virtual-networks-name-resolution-for-virtual machines-and-role-instances/inter-vnet-dns.png).

При использовании разрешения имен, предоставленного Azure, протокол конфигурации динамических узлов Azure (DHCP) предоставляет внутренний DNS-суффикс (.internal.cloudapp.net) для каждой виртуальной машины. Этот суффикс обеспечивает разрешение имен хоста, так как записи имен хоста находятся в зоне internal.cloudapp.net. При использовании собственного решения разрешения имен этот суффикс не предоставляется виртуальным машинам, так как он вмешивается в другие архитектуры DNS (например, присоединенные к домену сценарии). Вместо этого Azure предоставляет неработающий заполнитель (reddog.microsoft.com).

При необходимости можно определить внутренний DNS-суффикс с помощью PowerShell или API.

Для виртуальных сетей в моделях развертывания Resource Manager, этот суффикс доступен через REST API сетевого интерфейса, командлет Get-AzNetworkInterface PowerShell и команду az network nic show Azure CLI.

Если переадресация запросов в Azure не соответствует вашим потребностям, предоставьте собственное решение DNS или разверните Azure DNS Private Resolver.

Если вы предоставляете собственное решение DNS, необходимо выполнить следующие действия.

• Например, укажите соответствующее разрешение имен узлов с помощью динамического DNS (DDNS). При использовании DDNS может потребоваться отключить очистку записей DNS. Срок аренды DHCP в Azure длителен, и удаление данных может преждевременно убрать записи DNS.
• Предоставлять корректное рекурсивное разрешение для обработки внешних доменных имен.
• Быть доступным (по протоколам TCP и UDP через порт 53) для клиентов, которых оно обслуживает, и иметь доступ к Интернету.
• Защита от доступа из Интернета для устранения угроз, связанных с внешними агентами.

Для повышения производительности при использовании виртуальных машин Azure в качестве DNS-серверов IPv6 следует отключить.

Группы безопасности сети (NSG) выполняют роль брандмауэров для конечных точек сопоставителя DNS. Измените или переопределите правила безопасности NSG, чтобы разрешить доступ к порту UDP 53 (и при необходимости TCP-порт 53) к конечным точкам прослушивателя DNS. После установки пользовательских DNS-серверов в сети трафик через порт 53 обходит группы безопасности сети подсети и сетевой интерфейсной карты.

Веб-приложения

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

• Если вы еще не сделали этого, включите интеграцию виртуальной сети для веб-приложения, как описано в разделе "Интеграция приложения с виртуальной сетью".
• Чтобы выполнить разрешение имён из веб-приложения, связанного с виртуальной сетью (созданного с помощью App Service) на виртуальные машины в другой виртуальной сети, которая не связана с той же частной зоной, используйте пользовательские DNS-серверы или Azure DNS Private Resolvers в обеих виртуальных сетях.

Чтобы использовать пользовательские DNS-серверы, выполните приведенные действия.

• Настройте DNS-сервер в целевой виртуальной сети на виртуальной машине, которая также может пересылать запросы рекурсивному сопоставителям в Azure (виртуальный IP-адрес 168.63.129.16). Пример пересылки DNS доступен в галерее шаблонов быстрого запуска Azure и на сайте GitHub.
• Настройте DNS-сервер пересылки в исходной виртуальной сети на виртуальной машине. Настройте этот DNS-сервер пересылки для перенаправления запросов на DNS-сервер в целевой виртуальной сети.
• Настройте исходный DNS-сервер в параметрах исходной виртуальной сети.
• Включите интеграцию виртуальной сети для веб-приложения, чтобы связаться с исходной виртуальной сетью, следуя инструкциям в статье "Интеграция приложения с виртуальной сетью".

Для использования частного сопоставителя Azure DNS см. раздел «Ссылки на набор правил».

Указание DNS-серверов

При использовании собственных DNS-серверов можно указать несколько DNS-серверов на виртуальную сеть. Можно также указать несколько DNS-серверов на сетевой интерфейс (для Resource Manager) или на облачную службу (для классической модели развертывания). DNS-серверы, указанные для облачной службы или сетевого интерфейса, имеют более высокий приоритет по сравнению с DNS-серверами, указанными для виртуальной сети.

При использовании модели развертывания Resource Manager можно указать DNS-серверы для виртуальной сети и сетевого интерфейса. Дополнительные сведения см. в разделе "Управление виртуальной сетью " и "Управление сетевым интерфейсом".

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

Связанный контент

Модель развертывания с помощью Azure Resource Manager:

• Управление виртуальной сетью
• Управление сетевым интерфейсом