Общие сведения о системах доменных имен в Azure NetApp Files

Статья
02/04/2025

Azure NetApp Files поддерживает использование интегрированных DNS-серверов Active Directory или автономных DNS-серверов и требует надежного доступа к службам системы доменных имен (DNS) и актуальным записям DNS. Плохое сетевое подключение между Azure NetApp Files и DNS-серверами может привести к прерыванию доступа клиента или истечению времени ожидания клиента. Неполные или неправильные записи DNS для служб домен Active Directory (AD DS) или Azure NetApp Files могут привести к прерыванию доступа клиента или истечению времени ожидания клиента.

Служба DNS является важным компонентом доступа к данным в Azure NetApp Files. Доступ к протоколу файлов через SMB, NFSV4.1 Kerberos, LDAP и Обнаружение сайтов Active Directory все используют DNS для своих операций. Использование имени узла, расположенного в DNS, упрощает доступ к тому и защищает от сценариев при изменении IP-адреса. Вместо того чтобы администратор должен информировать пользователей о новом IP-адресе, пользователи могут продолжать использовать понятное имя узла.

DNS-серверы настраиваются в подключениях Active Directory. Можно добавить основной и вторичный сервер, а также DNS-имя Active Directory.

Примечание.

Рекомендуется настроить несколько DNS-серверов для избыточности.

Сведения о DNS-серверах

Для Azure NetApp Files требуется подключение Active Directory для функций SMB и NFSv4.1 Kerberos. Active Directory требует DNS для правильной функциональности. В большинстве случаев развертывания Active Directory устанавливаются с DNS-серверами, интегрированными с контроллерами домена. Эта конфигурация является рекомендуемой корпорацией Майкрософт для удобства использования и обеспечения создания всех необходимых записей DNS для доменных служб.

В некоторых случаях внешние DNS-серверы (например, BIND) могут использоваться вместо служб Active Directory, размещенных в Active Directory. Это называется несвязанным пространством имен.

Azure NetApp Files поддерживает использование интегрированных и внешних DNS-серверов, но при использовании внешних DNS-серверов без интеграции Active Directory важно убедиться, что необходимые записи службы (SRV) добавляются в DNS для правильной функциональности и избыточности служб. Плохое сетевое подключение между Azure NetApp Files и DNS-серверами может привести к прерыванию доступа клиента или истечению времени ожидания клиента. Неполные или неправильные записи DNS для AD DS или Azure NetApp Files могут привести к прерыванию доступа клиента или истечению времени ожидания клиента.

Записи DNS в Azure NetApp Files см. в списке записей SRV, которые использует служба. Кроме того, ознакомьтесь с рекомендациями по DNS с Active Directory и интеграцией AD DS в существующую инфраструктуру DNS.

Интеграция Azure DNS с Azure NetApp Files

Azure DNS — это размещенная служба управления DNS и разрешения имен в Microsoft Azure. Его можно использовать для создания общедоступных или частных DNS-имен для других приложений и служб, развернутых в Azure, включая Azure NetApp Files. Развертывание DNS в Azure предотвращает отправку DNS-запросов (через порт 53) непосредственно между Azure NetApp Files и локальным DNS и (или) доменом Active Directory. Кроме того, Azure DNS можно использовать для создания условных серверов пересылки (с помощью сопоставителя azure Частная зона DNS), которые можно использовать для отправки DNS-запросов из Azure NetApp Files на определенные DNS-серверы с помощью частных DNS-серверов, размещенных в Azure, которые можно указать для использования в подключении Active Directory.

Сведения об использовании Azure DNS:

Использование IP-адресов подсистемы балансировки нагрузки с DNS в Azure NetApp Files

Устройство подсистемы балансировки нагрузки — это способ использования одного IP-адреса для обслуживания нескольких IP-адресов на серверной части. Это обеспечивает безопасность с помощью обфускации, а также преимущества производительности и избыточности для корпоративных сред.

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

Azure NetApp Files поддерживает использование подсистем балансировки нагрузки DNS, если они предоставляют IP-адрес в качестве конечной точки, а IP-адрес может обмениваться данными через порт 53 в сети Azure NetApp Files. Например, Диспетчер трафика Azure обеспечивает балансировку нагрузки DNS на уровне 7, но используется только имя внешнего узла. Подключения Azure NetApp Files Active Directory позволяют указывать только IP-адреса для DNS-серверов.

Типы записей DNS в Azure NetApp Files

Azure NetApp Files использует различные типы записей DNS для доступа к файловыми службам.

Типы записей DNS	Определение
A/AAAA	Записи DNS A — это записи адресов, указывающие IPv4-адрес для имени узла. Записи AAAA указывают IPv6-адрес для имени узла. Azure NetApp Files использует записи A/AAAA следующим образом: Маскирование IP-адресов за именами узлов, понятными для пользователей Запросы субъекта-службы Kerberos Запросы корневого домена
Записи указателя (PTR)	Запись PTR сопоставляет IP-адрес с именем узла путем зоны обратного поиска. Записи PTR в основном используются при указании IP-адреса для подключения или общего доступа в Azure NetApp Files. Использование IP-адреса в запросах на подключение или общий доступ может повлиять на используемый метод проверки подлинности. Дополнительные сведения см. в разделе IP-адресов для доступа с помощью Kerberos.
Записи службы (SRV)	Записи SRV используются для указания узлов и портов, используемых для определенной службы, таких как LDAP, NFS, CIFS, Kerberos и т. д. Записи SRV в Azure NetApp Files часто используются для безопасности файловой службы (например, Kerberos), обнаружения сайтов в Active Directory, запросов сервера LDAP и т. д. Важно проверить наличие этих записей для надлежащей функциональности служб Azure NetApp Files. Записи SRV можно запрашивать с помощью `nslookup` или `dig` команд. Примеры см. в разделе "Использование `nslookup` и `dig` запросы DNS".
Канонические имена (CNAME)	Запись CNAME — это способ предоставления псевдонимов DNS для записей A/AAAA. Записи CNAME являются необязательными, но могут быть полезны для уменьшения сложности записей имен узлов, предоставляемых Azure NetApp Files. Дополнительные сведения см. в разделе "Псевдонимы DNS" и "Каноническое имя".
Универсальный идентификатор ресурса (URI)	Запись URI — это способ сопоставления имен узлов или IP-адресов для служб с URI. URI представлены в таком формате: service://fqdn.contoso.com. Azure NetApp Files использует запросы для записей URI только при выполнении подстановок KDC Kerberos для запросов Kerberos NFS. Записи URI не создаются в развертываниях DNS Active Directory по умолчанию. Таким образом, запросы поиска URI обычно завершаются ошибкой и возвращаются к поиску записей SRV.

Записи служб (SRV), используемые с Azure NetApp Files

Azure NetApp Files использует следующие записи SRV:

NFS Kerberos*
- _kerberos-master._tcp. CONTOSO.COM (порт 88)*
- _kerberos-master._tcp. CONTOSO.COM (порт 88)*
Обнаружение сайтов SMB/Active Directory**
- _kerberos.CONTOSO.COM (порт 88)
- _kerberos._tcp. CONTOSO.COM (порт 88)
- _kerberos._tcp.dc_msdcs. CONTOSO.COM (порт 88)
- _kpasswd._tcp.dc._msdcs. CONTOSO.COM (порт 464)
- _kpasswd._tcp. CONTOSO.COM (порт 464)
- _kerberos._tcp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (порт 88)
- _kerberos._tcp. {другие имена сайтов}._sites.dc._msdcs. CONTOSO.COM (порт 88)
- _kerberos.udp.CONTOSO.COM (порт 88)
- _kerberos._udp.dc_msdcs. CONTOSO.COM (порт 88)
- _kpasswd._udp.dc._msdcs. CONTOSO.COM (порт 464)
- _kpasswd._udp. CONTOSO.COM (порт 464)
- _kerberos._udp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (порт 88)
- _kerberos._udp. {другие имена сайтов}._sites.dc._msdcs. CONTOSO.COM (порт 88)
LDAP**
- _ldap.CONTOSO.COM (порт 389)
- _ldap._tcp. CONTOSO.COM (порт 389)
- _ldap._udp. CONTOSO.COM (порт 389)

* DNS Active Directory не создает эти записи SRV по умолчанию. Настоятельно рекомендуется создать их при использовании NFS Kerberos.

** DNS Active Directory создает эти записи SRV по умолчанию.

Дополнительные сведения о том, как Azure NetApp Files использует записи SRV, см. в следующем разделе:

Примечание.

Для правильного обнаружения и избыточности центра распространения ключей в NFS Kerberos необходимо создать записи URI и /или записи SRV master kerberos-master.

Динамическая DNS

Тома Azure NetApp Files предоставляют один IP-адрес тома, который затем добавляется в DNS автоматически с помощью динамического DNS (DDNS) (если динамический DNS поддерживается на DNS-сервере). Имена узлов (а не IP-адреса) используются для путей подключения томов в определенных конфигурациях. Использование имен узлов в путях подключения требует DNS для правильной функциональности:

Тома SMB
Kerberos NFS версии 4.1
Тома с двумя протоколами

NFSv4.1 Kerberos:

SMB

Двойной протокол

IP-адрес используется для пути подключения, если том Файла Azure NetApp не требует DNS, например NFSv3 или NFSv4.1 без Kerberos.

NFS версии 3

Динамический тип DNS	Порт
Стандартный DNS	UDP 53
Безопасная СЛУЖБА DNS	TCP 53

Сведения о динамической записи DNS

Когда Azure NetApp Files создает запись DNS A/AAAA с помощью динамической DNS, используются следующие конфигурации:

Установлен соответствующий флажок записи PTR: если для подсети существуют зоны обратного поиска, то записи A/AAAA автоматически создают записи PTR без вмешательства администратора.
Флажок "Удалить эту запись, когда она становится устаревшей" установлен: когда запись DNS становится "устаревшей", DNS удаляет запись, если включена очистка DNS.
Запись DNS " время жизни (TTL)" имеет значение один день (24 часа): параметр TTL можно изменить администратором DNS по мере необходимости. TTL в записи DNS определяет время существования записи DNS в кэше DNS клиента.

Примечание.

Чтобы просмотреть метки времени и время жизни (TTL) при создании записи DNS в Windows Active Directory DNS, перейдите в меню "Вид" диспетчера DNS и нажмите кнопку "Дополнительно". Выберите запись записи A/AAAA и просмотрите свойства.

Как работает стандартная динамическая СЛУЖБА DNS в Azure NetApp Files

Azure NetApp Files выполняет четыре основных шага для создания динамических обновлений DNS на настроенных DNS-серверах. Обновления DDNS (Standard dynamic DNS) проходят через порт UDP 53.

Выполняется запрос DNS SOA для IP-адреса интерфейса тома Azure NetApp Files.
Выполняется обновление DDNS для PTR. Если PTR не существует, он создается.
Для полного доменного имени (FQDN) тома Azure NetApp Files выполняется запрос на dns-запуск центра (SOA).
Выполняется обновление DDNS для записи A/AAAA. Если запись не существует, она создается.

Динамическая служба DNS с помощью записи пакетов

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

Выполняется запрос DNS SOA для IP-адреса интерфейса тома Azure NetApp Files.

143 x.x.x.y	x.x.x.x	DNS	86	Standard query 0x77c8 SOA y.x.x.x.in-addr.arpa

144 x.x.x.x	x.x.x.y	DNS	229	Standard query response 0x77c8 No such name SOA y.x.x.x.in-addr.arpa SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111 AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

Выполняется обновление DDNS для PTR. Если PTR не существует, он создается.

145 x.x.x.y	x.x.x.x	DNS	121	Dynamic update 0x1a43 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local

146 x.x.x.x	x.x.x.y	DNS	121	Dynamic update response 0x1a43 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local

Для полного доменного имени (FQDN) тома Azure NetApp Files выполняется запрос на dns-запуск центра (SOA).

147 x.x.x.y	x.x.x.x	DNS	81	Standard query 0xcfab SOA ANF1234.anf.local

148 x.x.x.x	x.x.x.y	DNS	214	Standard query response 0xcfab No such name SOA ANF1234.anf.local SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

Выполняется обновление DDNS для записи A/AAAA. Если запись не существует, она создается.

149 x.x.x.y	x.x.x.x	DNS	97	Dynamic update 0x83b2 SOA anf.local A x.x.x.y

150 x.x.x.x	x.x.x.y	DNS	97	Dynamic update response 0x83b2 SOA anf.local A x.x.x.y

Как работает защита DDNS в Azure NetApp Files

Если включена безопасная служба DNS, Azure NetApp Files ведет переговоры с DNS-сервером для проверки подлинности с помощью GSS с помощью проверки подлинности секретного ключа для DNS, гарантируя, что запрошенные обновления приходят из законного источника. Ниже показаны шаги, используемые во время этого процесса. Защищенные обновления DDNS проходят через TCP-порт 53.

Выполняется запрос DNS SOA для IP-адреса интерфейса тома Azure NetApp Files.
Билет службы Kerberos обменивается на службу DNS на DNS-сервере.
Затем запрос используется в DNS-запросе для ключа транзакции (TKEY) из Azure NetApp Files на DNS-сервер, который передается с помощью GSS-TSIG (подпись транзакции) для проверки подлинности.
После успешной проверки подлинности безопасное динамическое обновление DNS отправляется с помощью TKEY для создания PTR с помощью GSS-TSIG. Если запись еще не существует, она создается.
Запрос DNS SOA отправляется для полного доменного имени (FQDN) тома Azure NetApp Files и отвечает на него.
Новый идентификатор TKEY обменивается dns-сервером и Azure NetApp Files.
Безопасное динамическое обновление DNS отправляется с помощью TKEY для создания записи A/AAAA для полного доменного имени. Если запись уже существует с тем же IP-адресом, изменения не вносятся.

Динамическая служба DNS с помощью записи пакетов

Выполняется запрос DNS SOA для IP-адреса интерфейса тома Azure NetApp Files.

1135 x.x.x.y 	x.x.x.x	DNS	86	Standard query 0xd29a SOA y.x.x.x.in-addr.arpa

1136 x.x.x.x	x.x.x.y	DNS	229	Standard query response 0xd29a No such name SOA y.x.x.x.in-addr.arpa SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

Билет службы Kerberos обменивается на службу DNS на DNS-сервере.

1141 x.x.x.y	x.x.x.x	KRB5	406	TGS-REQ
•	SNameString: DNS
•	SNameString: dc1.anf.local

1143 x.x.x.x	x.x.x.y	KRB5	1824	TGS-REP

Затем запрос используется в DNS-запросе для ключа транзакции (TKEY) из Azure NetApp Files на DNS-сервер, который передается с помощью GSS-TSIG (подпись транзакции) для проверки подлинности.

    1152 x.x.x.y	x.x.x.x	DNS	191	Standard query 0x147c TKEY 1492998148.sig-dc1.anf.local TKEY
•	Name: 1492998148.sig-dc1.anf.local
•	Type: TKEY (249) (Transaction Key)
•	Algorithm name: gss-tsig

1154 x.x.x.x	x.x.x.y	DNS	481	Standard query response 0x147c TKEY 1492998148.sig-dc1.anf.local TKEY TSIG

После успешной проверки подлинности безопасное динамическое обновление DNS отправляется с помощью TKEY для создания PTR с помощью GSS-TSIG. Если запись еще не существует, она создается.

1155 x.x.x.y	x.x.x.x	DNS	240	Dynamic update 0xf408 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local TSIG
•	Zone
o	x.x.x.in-addr.arpa: type SOA, class IN
o	y.x.x.x.in-addr.arpa: type PTR, class IN, ANF1234.anf.local
•	Type: PTR (12) (domain name PoinTeR)
o	Additional records
o	1492998148.sig-dc1.anf.local: type TSIG, class ANY

1156 x.x.x.x	x.x.x.y	DNS	240	Dynamic update response 0xf408 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local TSIG
•	Updates
o	y.x.x.x.in-addr.arpa: type PTR, class IN, ANF1234.anf.local
o	Type: PTR (12) (domain name PoinTeR)

Запрос DNS SOA отправляется для полного доменного имени (FQDN) тома Azure NetApp Files и отвечает на него.

1162 x.x.x.y	x.x.x.x	DNS	81	Standard query 0xe872 SOA ANF1234.anf.local

1163 x.x.x.x	x.x.x.y	DNS	214	Standard query response 0xe872 No such name SOA ANF1234.anf.local SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111 AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

Новый идентификатор TKEY обменивается dns-сервером и Azure NetApp Files.

1165 x.x.x.y	x.x.x.x	DNS	191	Standard query 0x020e TKEY 1260534462.sig-dc1.anf.local TKEY

1167 x.x.x.x	x.x.x.y	DNS	481	Standard query response 0x020e TKEY 1260534462.sig-dc1.anf.local TKEY TSIG

Безопасное динамическое обновление DNS отправляется с помощью TKEY для создания записи A/AAAA для полного доменного имени. Если запись уже существует с тем же IP-адресом, изменения не вносятся.

    1168 x.x.x.y	x.x.x.x	DNS	216	Dynamic update 0x014a SOA anf.local A x.x.x.y TSIG
•	Zone
o	anf.local: type SOA, class IN
•	Updates
o	ANF1234.anf.local: type A, class IN, addr x.x.x.y
o	Type: A (1) (Host Address)
o	Address: x.x.x.y
•	Additional records
o	1260534462.sig-dc1.anf.local: type TSIG, class ANY

1170 x.x.x.x	x.x.x.y	DNS	216	Dynamic update response 0x014a SOA anf.local A x.x.x.y TSIG
•	Updates
o	ANF1234.anf.local: type A, class IN, addr x.x.x.y
o	Type: A (1) (Host Address)

Кэширование DNS

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

Azure NetApp Files использует кэши DNS, такие как любой другой стандартный DNS-клиент. Когда служба запрашивает запись DNS, эта запись имеет определенный срок жизни. По умолчанию записи DNS Active Directory имеют TTL 600 секунд (10 минут), если не указано в противном случае. Если запись DNS обновляется и живет в кэше Azure NetApp Files и срок жизни составляет 10 минут, новая запись не обновляется в Azure NetApp Files, пока кэш не будет удален после истечения времени ожидания. В настоящее время нет способа вручную очистить этот кэш. Если необходимо меньшее значение TTL, внесите изменения с DNS-сервера.

При использовании внешних DNS-серверов (например, BIND) значения времени ожидания по умолчанию могут отличаться. Если не определено, срок жизни записи BIND DNS составляет 604 800 секунд (семь дней), слишком долго для эффективного кэширования DNS. Таким образом, при создании записей DNS вручную важно вручную задать TTL для записи разумное значение. Использование microsoft по умолчанию 10 минут рекомендуется для сочетания производительности и надежности для подстановок DNS.

Вы можете вручную запросить TTL записи DNS с помощью nslookup или dig команд. Примеры см. в разделе "Использование nslookup и dig запросы DNS".

Очистка и очистка записи DNS

Большинство DNS-серверов предоставляют методы для очистки и очистки просроченных записей. Запуск помогает предотвратить загромождение устаревших записей от загромождения DNS-серверов и создания сценариев, в которых существуют повторяющиеся записи A/AAAA и /или PTR, которые могут создавать непредсказуемые результаты для томов Azure NetApp Files.

Если несколько записей PTR для одной и той же точки IP-адреса в разных именах узлов, запросы Kerberos могут завершиться ошибкой, так как неправильный идентификатор субъекта-службы извлекается во время поиска DNS. DNS не распознает, какая запись PTR принадлежит к имени узла; Вместо этого обратные поиски выполняют поиск по циклическим переборам по каждой записи A/AAAA для каждой новой подстановки.

Пример.

C:\> nslookup x.x.x.x
Server:  contoso.com
Address:  x.x.x.x

Name:    ANF-1234.contoso.com
Address:  x.x.x.x

C:\> nslookup x.x.x.x
Server:  contoso.com
Address:  x.x.x.x

Name:    ANF-5678.contoso.com
Address:  x.x.x.x

Записи псевдонимов DNS и канонического имени (CNAME)

Azure NetApp Files создает dns-имя узла для тома, настроенного для протокола, который требует DNS для правильной функциональности, например SMB, двойного протокола или NFSv4.1 с Kerberos. Имя, созданное, использует формат сервера SMB (учетная запись компьютера) в качестве префикса при создании подключения Active Directory для учетной записи NetApp; Добавлены дополнительные буквенно-цифровые символы, чтобы несколько записей тома в одной учетной записи NetApp имели уникальные имена. В большинстве случаев несколько томов, требующих имен узлов и существующих в одной учетной записи NetApp, пытаются использовать те же имена узлов и IP-адреса. Например, если имя сервера SMB SMB-West.contoso.com, записи имени узла соответствуют формату SMB-West-XXXX.contoso.com.

В некоторых случаях имя, используемое Azure NetApp Files, может быть недостаточно понятным для передачи конечным пользователям или администраторам может потребоваться сохранить более знакомые DNS-имена, используемые при переносе данных из локального хранилища в Azure NetApp Files (т. е. если исходное DNS-имя было datalake.contoso.com, конечные пользователи могут продолжать использовать это имя).

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

Использование записи CNAME (а не дополнительной записи A/AAAA), указывающей на запись A/AAAA тома Azure NetApp Files, использует то же имя субъекта-службы, что и сервер SMB, чтобы включить доступ Kerberos для записи A/AAAA и CNAME. Рассмотрим пример записи A/AAAA SMB-West-XXXX.contoso.com. Запись CNAME datalake.contoso.com настроена для указания записи A/AAAA SMB-West-XXXX.contoso.com. Запросы SMB или NFS Kerberos, сделанные для datalake.contoso.com использовать имя участника-службы Kerberos для SMB-West-XXXX для предоставления доступа к тому.

Использование nslookup и dig for DNS-запросов

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

dig Команды nslookup можно запускать из удаленного подключения к виртуальной машине (например, из Бастиона) или непосредственно к виртуальной машине с помощью команды выполнения на самой виртуальной машине.

nslookup с Windows

Вы можете выполнить nslookup сбор основных сведений ОБ IP-адресе без каких-либо параметров:

C:\>nslookup anf.local
Server:  dns.anf.local
Address:  x.x.x.a

Name:    anf.local
Addresses:  x.x.x.x
            x.x.x.y

Чтобы запросить только сведения о TTL для записи, используйте -query=hinfo команду.

C:\>nslookup -query=hinfo anf.local
Server:  dns.anf.local
Address:  x.x.x.a

anf.local
        primary name server = dns.anf.local
        responsible mail addr = root.dns.anf.local
        serial  = 7
        refresh = 604800 (7 days)
        retry   = 86400 (1 day)
        expire  = 2419200 (28 days)
        default TTL = 604800 (7 days)

Этот -debug параметр также можно использовать для сбора более подробных сведений о записи DNS.

C:\>nslookup -debug anf.local
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        x.x.x.x.in-addr.arpa, type = PTR, class = IN
    ANSWERS:
    ->  x.x.x.x.in-addr.arpa
        name = dns.anf.local
        ttl = 604800 (7 days)

------------
Server:  dns.anf.local
Address:  x.x.x.a

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        anf.local.ANF.LOCAL, type = A, class = IN
    AUTHORITY RECORDS:
    ->  anf.local
        ttl = 604800 (7 days)
        primary name server = dns.anf.local
        responsible mail addr = root.dns.anf.local
        serial  = 7
        refresh = 604800 (7 days)
        retry   = 86400 (1 day)
        expire  = 2419200 (28 days)
        default TTL = 604800 (7 days)

копать с помощью Linux

# dig anf.local

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> anf.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12196
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;anf.local.                     IN      A

;; ANSWER SECTION:
anf.local.              604800  IN      A       x.x.x.x
anf.local.              604800  IN      A       x.x.x.y

;; Query time: 0 msec
;; SERVER: 10.193.67.250#53(10.193.67.250)
;; WHEN: Thu Aug 29 15:27:47 EDT 2024
;; MSG SIZE  rcvd: 70

Поделиться через

Общие сведения о системах доменных имен в Azure NetApp Files

Сведения о DNS-серверах

Интеграция Azure DNS с Azure NetApp Files

Использование IP-адресов подсистемы балансировки нагрузки с DNS в Azure NetApp Files

Типы записей DNS в Azure NetApp Files

Записи служб (SRV), используемые с Azure NetApp Files

Динамическая DNS

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

Сведения о динамической записи DNS

Как работает стандартная динамическая СЛУЖБА DNS в Azure NetApp Files

Динамическая служба DNS с помощью записи пакетов

Как работает защита DDNS в Azure NetApp Files

Динамическая служба DNS с помощью записи пакетов

Кэширование DNS

Очистка и очистка записи DNS

Записи псевдонимов DNS и канонического имени (CNAME)

Использование nslookup и dig for DNS-запросов

nslookup с Windows

копать с помощью Linux

Рекомендации по DNS в Azure NetApp Files

Следующие шаги

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

Дополнительные ресурсы