Устранение проблем с Azure DNS

Сводка

Эта статья помогает администраторам DNS устранять распространенные Azure DNS проблемы с зонами, записями и разрешением имен, чтобы они могли восстановить службу DNS.

Руководство по проектированию

Прежде чем устранять неполадки с архитектурой DNS, ознакомьтесь со следующими рекомендациями по проектированию:

• Сведения о выборе между Azure предоставленными DNS, Частная зона DNS зонами, частным сопоставительом, настраиваемыми DNS-серверами и параметрами диспетчера трафика для гибридных и многорегиональных проектов см. в статье "Гибридная инфраструктура DNS" на Azure.
• Шаблоны интеграции DNS частной конечной точки, включая одну виртуальную сеть, концентратор и периферийную сеть, локальные и пользовательские сценарии DNS, см. в Azure сценариях интеграции с dns частной конечной точкой.

Вы также можете использовать Microsoft Copilot в Azure на портале Azure для устранения неполадок с разрешением DNS. Например, воспользуйтесь запросом, например "Вы можете помочь мне устранить проблемы с разрешением DNS в Azure?", Copilot можно использовать контекст ресурса и выполнить инструкции, описанные в этой статье. Дополнительные сведения см. в статье "Что такое Microsoft Copilot в Azure?", а также примеры запросов.

продукты Azure DNS

Приоритет разрешения внутри рекурсии Azure

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

На схеме ниже показано, что порядок оценки. Прочитайте его сверху вниз:

• Azure DNS Политика сопоставителя выступает в качестве фильтра для каждого запроса. Правило блокировки останавливает поиск перед ответами на любые зоны или наборы правил. Правила разрешений и оповещений передают запрос (с ведением журнала) в приведенные ниже действия.
• Далее проверяются связанные Частная зона DNS зоны (включая privatelink.* зоны, зарегистрированные частными конечными точками), поэтому частная конечная точка "выигрывает" по общедоступной записи для того же полного доменного имени.
• Затем наборы правил перенаправления DNS соответствуют суффиксу и отправляют запрос в предварительную или стороннюю сопоставитель через исходящую конечную точку.
• Все, что не соответствует падает на общедоступные Azure DNS / интернет рекурсии.

Используйте этот порядок при попытке объяснить, почему клиент получил неожиданный IP-адрес. Как правило, это означает, что источник с более высоким приоритетом (правило политики разрешения Azure DNS, связанная частная зона или правило пересылки) совпадает до того, как рекурсия когда-либо достигла общедоступного ответа.

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

Общие средства устранения неполадок DNS

Большинство Azure DNS проблем попадают в одну из двух категорий: содержимое, возвращающее разрешение (неправильная запись, недостающая запись, устаревший кэш) или сетевой путь к сопоставителям (NSG, таблица маршрутов, брандмауэр или NVA, блокирующие UDP/TCP 53). Эффективное устранение неполадок разделяет эти две проблемы, прежде чем подробно использовать любое поведение конкретного продукта.

Надежный подход:

1. Определите, что делает клиент сегодня. Определите, какой сопоставитель клиент фактически запрашивает (Get-DnsClientServerAddress, resolvectl status, ), ipconfig /allпрежде чем предположить, что он 168.63.129.16 или ваш пользовательский DNS.
2. Сравните неудачный запрос с известным хорошим источником. Выполните тот же запрос к подозреваемому сопоставителям и к ссылочному сопоставительу (168.63.129.16конечная точка 1.1.1.1входящего трафика приватного сопоставителя или Azure сервере имен напрямую). Если ответы отличаются, проблема связана с самой записью DNS (неправильное значение, устаревший кэш или делегирование неработаемой зоны). Если время ожидания истекает, проблема — это сетевой путь к сопоставительу.
3. Изоляция сетевого пути с помощью пробы, отличной от DNS. Test-NetConnection -Port 53 подтверждает, достигает ли UDP/TCP 53 разрешение на всех, разделяя проблему маршрутизации/NSG/брандмауэра от проблемы с содержимым DNS.
4. Исключите кэширование перед выводом выводов. Сброс локального кэша (Clear-DnsClientCache, ipconfig /flushdns, sudo resolvectl flush-caches) и при проверке общедоступных зон используйте внешний тестировщик, такой как digwebinterface корпоративные прокси-серверы и рекурсивные кэши, не маскируют динамический ответ.
5. Используйте последние сигналы Azure стороне, а не сначала. Журнал действий в зоне, сопоставитель или политика объясняет сбои уровня управления (создание или обновление ошибок, квоты, конфликтов); Наблюдатель за сетями устранение неполадок подключения объясняет сбои пути плоскости данных. Оба наиболее полезны после того, как описанные выше шаги сузили проблему.

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

Выберите соответствующее средство

Проверка разрешающей способности DNS

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

1. Определите, какой сопоставитель использует клиент.

   а. В Windows:

   Get-DnsClientServerAddress -AddressFamily IPv4
   ipconfig /all | Select-String "DNS Servers"
   

   б. В Linux:

   resolvectl status
   cat /etc/resolv.conf
   

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

2. Запрос сопоставителя по умолчанию.

   а. Виндоус:

   Resolve-DnsName www.contoso.com
   

   б. Линукс:

   nslookup www.contoso.com
   dig www.contoso.com +noall +answer
   

3. Обходить сопоставитель по умолчанию, чтобы изолировать проблему. Наведите указатель непосредственно на вышестоящем потоке, который требуется протестировать.

   а. Виндоус:

   # Query Azure-provided DNS directly
   Resolve-DnsName www.contoso.com -Server 168.63.129.16
   
   # Query a Private Resolver inbound endpoint
   Resolve-DnsName db.contoso.com -Server 10.10.0.4
   
   # Query a public resolver to compare what the internet sees
   Resolve-DnsName www.contoso.com -Server 1.1.1.1
   

   б. Линукс:

   dig @168.63.129.16 www.contoso.com
   dig @10.10.0.4 db.contoso.com
   dig @1.1.1.1 www.contoso.com
   

4. Подтвердите доступность UDP/TCP 53 на любом целевом сервере.

   Test-NetConnection 168.63.129.16 -Port 53
   Test-NetConnection 10.10.0.4 -Port 53
   

5. Очистка кэшей перед повторной проверкой, когда записи были недавно изменены.

   а. Виндоус:

   ipconfig /flushdns
   Clear-DnsClientCache
   

   б. Линукс:

   sudo resolvectl flush-caches
   

NSG, Брандмауэр Azure или NVA блокируют UDP/TCP 53

Симптом

Время ожидания запросов DNS (Resolve-DnsName : timed outdigотображаетсяconnection timed out; no servers could be reached). Эта проблема часто возникает сразу после введения правила NSG, изменения таблицы маршрутов, Брандмауэр Azure или NVA в пути исходящего трафика.

Steps

1. Определите конечный IP-адрес клиента, который запрашивает.

   • Распространенные целевые объекты: 168.63.129.16частная конечная точка разрешения, пользовательская DNS-виртуальная машина или общедоступный сопоставитель.
   • Используйте шаг 1 проверки разрешения DNS для подтверждения.

2. Проверьте доступность необработанных данных через порт 53.

   Test-NetConnection 168.63.129.16 -Port 53
   

3. Просмотрите действующие правила NSG для сетевого адаптера клиента.

   а. На портале откройте клиентную виртуальную машину → сети → сетевой адаптер → справку → действующие правила безопасности.

   б. Убедитесь, что правило исходящего трафика разрешает UDP 53иTCP 53 в целевой IP-адрес.

4. Просмотрите действующие маршруты на одном сетевом адаптере.

   • На Microsoft 168.63.129.16 не распространяется определяемые пользователем маршруты, поэтому определяемый пользователем адрес не применяется.
   • Однако правило NSG, которое запрещает AzurePlatformDNS тег службы, может блокировать трафик, предоставляемый Azure DNS.

5. Если Брандмауэр Azure находится в пути, убедитесь, что он разрешает трафик DNS.

   а. В большинстве случаев добавьте сетевое правило , позволяющее UDP/TCP 53 из подсети клиента в IP-адрес сопоставителя.

   б. Только если вы также хотите, чтобы брандмауэр обрабатывал DNS сам (например, использовать фильтрацию полного доменного имени в сетевых правилах), включите DNS-прокси в брандмауэре и наведите точку виртуальной сети dnsServers на частный IP-адрес брандмауэра.

6. Для NVAs (сетевых виртуальных устройств) убедитесь, что NVA перенаправит DNS неизмененные и что собственные правила исходящего трафика разрешают 53.

7. Повторно протестируйте после каждого изменения.

   Resolve-DnsName www.contoso.com -Server 168.63.129.16
   

Рекомендуемые статьи

• Что такое IP-адрес 168.63.129.16?
• Параметры DNS брандмауэра Azure
• Группы безопасности сети (NSG) — обзор

группы зон Частная зона DNS

При интеграции частной конечной точки с зоной Частная зона DNS Azure создается группа зон Частная зона DNS. Этот ресурс привязки подключает частную конечную точку к одной или нескольким зонам Частная зона DNS. Группа зон сохраняет privatelink.*A записи в зоне синхронизированы с частной конечной точкой при изменении (регионы добавлены или удалены, удалена конечная точка). Без группы зон необходимо вручную обновить зоны и A записи.

Имейте в виду следующие ограничения и поведение группы зон:

• Группа зон может содержать до 5 Частная зона DNS зон.
• Только одна зона Частная зона DNS на имя зоны для каждой группы зон. Например, нельзя привязать две privatelink.blob.core.windows.net зоны к одной группе.
• Частная конечная точка поддерживает только одну группу зон.
• Поставщик ресурсов Диспетчер трафика Azure и DNS выполняет операции удаления и обновления записей. Это обычное поведение платформы, а не связанная служба.

Справочник. Сценарии интеграции DNS с частной конечной точкой Azure — группа зон Частная зона DNS.

Проверка наличия частной конечной точки группы зон DNS

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

• Azure PowerShell — Get-AzPrivateDnsZoneGroup:

Get-AzPrivateDnsZoneGroup `
  -ResourceGroupName <rg> `
  -PrivateEndpointName <pe-name>

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

• Azure CLI — az network private-endpoint dns-zone-group list:

az network private-endpoint dns-zone-group list \
  --resource-group <rg> \
  --endpoint-name <pe-name>

Чтобы проверить, к каким зонам привязана определенная группа, используйте az network private-endpoint dns-zone-group show:

az network private-endpoint dns-zone-group show \
  --resource-group <rg> \
  --endpoint-name <pe-name> \
  --name <zone-group-name>

Рекомендуемые статьи

• Сценарии интеграции DNS частной конечной точки Azure
• Конфигурация DNS для частной конечной точки Azure

Не удается создать зону DNS

Чтобы устранить распространенные проблемы, попробуйте выполнить одно или несколько следующих действий.

1. Просмотрите журналы аудита Azure DNS, чтобы найти причину сбоя.
2. Каждое имя зоны DNS должно быть уникальным в пределах своей группы ресурсов. То есть две зоны DNS с одинаковым именем не могут совместно использовать группу ресурсов. Попробуйте использовать другое имя зоны или другую группу ресурсов.
3. Может появиться сообщение об ошибке "Достигнуто или превышено максимальное количество зон в подписке {идентификатор подписки}". Либо используйте другую подписку Azure, удалите некоторые зоны или обратитесь в службу поддержки Azure, чтобы увеличить ограничение подписки.
4. Может появиться сообщение об ошибке "Зона "{имя зоны}" недоступна". Эта ошибка означает, что Azure DNS не удалось выделить серверы имен для этой зоны DNS. Попробуйте использовать другое имя зоны. Кроме того, если вы являетесь владельцем доменного имени, вы можете обратиться к поддержка Azure, чтобы выделить серверы имен.

Рекомендуемые статьи

• Зоны и записи DNS
• Создание зоны DNS

Не удается создать запись DNS

Чтобы устранить распространенные проблемы, попробуйте выполнить одно или несколько следующих действий.

1. Просмотрите журналы аудита Azure DNS, чтобы найти причину сбоя.
2. Существует ли набор записей? Azure DNS управляет записями с помощью наборов записей, которые являются коллекцией записей с одинаковым именем и одинаковым типом. Если запись с тем же именем и типом уже существует, необходимо изменить существующий набор записей, чтобы добавить другую запись.
3. Вы пытаетесь создать запись на апексе зоны DNS (корне зоны)? В этом случае соглашение DNS — использовать символ @в качестве имени записи. Кроме того, обратите внимание, что стандарты DNS не разрешают записи CNAME в вершине зоны.
4. У вас есть конфликт CNAME? Стандарты DNS не разрешают запись CNAME с тем же именем, что и запись любого другого типа. Если у вас есть CNAME, создание записи другого типа с тем же именем завершается ошибкой. Аналогичным образом создание CNAME не удаётся, если его имя совпадает с именем существующей записи другого типа. Удалите конфликт, удалив другую запись или выбрав другое имя записи.
5. Вы достигли ограничения на количество наборов записей, разрешенных в зоне DNS? На портале Azure отображается текущее количество наборов записей и максимальное количество наборов записей в разделе "Свойства" для зоны. Если вы достигли этого ограничения, удалите некоторые наборы записей или обратитесь в службу поддержки Azure, чтобы увеличить ограничение набора записей для этой зоны, а затем повторите попытку.

Рекомендуемые статьи

• Зоны и записи DNS
• Создание зоны DNS

Я не могу разрешить запись DNS

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

1. Убедитесь, что записи DNS настроены правильно в Azure DNS. Просмотрите записи DNS на портале Azure, проверьте правильность имени зоны, имени записи и типа записи.

2. Убедитесь, что записи DNS разрешаются правильно на серверах имен Azure DNS.

   • Если вы выполняете запросы DNS с локального компьютера, вы можете увидеть кэшированные результаты, которые не отражают текущее состояние серверов имен. Кроме того, корпоративные сети часто используют dns-прокси-серверы, которые препятствуют перенаправлению запросов DNS на определенные серверы имен. Чтобы избежать этих проблем, используйте веб-службу разрешения имен, например digwebinterface.
   • Обязательно укажите правильные серверы имен для зоны DNS, как показано на портале Azure.
   • Убедитесь, что DNS-имя правильно (необходимо указать полное имя, включая имя зоны) и тип записи правильно.

3. Убедитесь, что dns-имя домена правильно делегировано на серверы имен Azure DNS. Существует множество веб-сайтов, отличных от Microsoft, которые предлагают проверку делегирования DNS. Этот тест является тестом делегирования зоны , поэтому необходимо ввести только имя зоны DNS, а не полное имя записи.

4. После выполнения предыдущих шагов запись DNS должна быть правильно разрешена. Чтобы проверить, вы можете снова использовать digwebinterface, на этот раз с помощью параметров сервера имен по умолчанию.

Рекомендуемые статьи

• Делегирование домена в Azure DNS

Как указать службу и протокол для записи SRV?

Azure DNS управляет записями DNS в виде наборов записей — коллекцию записей с тем же именем и тем же типом. Для набора записей SRV необходимо указать службу и протокол в составе имени набора записей. Вы указываете другие параметры SRV ("приоритет", "вес", "порт" и "target") отдельно для каждой записи в наборе записей.

Примеры имен записей SRV (имя службы sip, протокол TCP):

• _sip._tcp (создает набор записей на вершине зоны)
• _sip._tcp.sipservice (создает набор записей с именем sipservice)

Рекомендуемые статьи

• Зоны и записи DNS
• Создавайте наборы записей DNS и записи с помощью портала Azure
• Тип записи SRV (Википедия)

Дальнейшие действия

• Узнайте о зонах и записях Azure DNS.
• Чтобы начать использовать Azure DNS, узнайте, как создать зону DNS и создать записи DNS.
• Чтобы перенести имеющуюся зону DNS, узнайте, как импортировать и экспортировать файл зоны DNS.