Разрешение имен ресурсов в виртуальных сетях Azure

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

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

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

Функции

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

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

Рекомендации

При использовании разрешения имен, предоставленных 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 Private 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. Перенаправление запросов позволяет виртуальным машинам видеть как ваши локальные ресурсы (через DC), так и имена узлов, предоставленные Azure (через сервер перенаправления). Доступ к рекурсивным сопоставителям Azure предоставляется через виртуальный IP-адрес 168.63.129.16.

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

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

.

При использовании разрешения имен, предоставленного 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), выполните следующие действия.

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

Чтобы использовать пользовательские 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:

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