Compreender os sistemas de nomes de domínio nos ficheiros NetApp do Azure
Os Arquivos NetApp do Azure dão suporte ao uso de DNS integrado do Ative Directory ou servidores DNS autônomos e exigem acesso confiável a serviços DNS (Sistema de Nomes de Domínio) e registros DNS atualizados. A má conectividade de rede entre os Arquivos NetApp do Azure e os servidores DNS pode causar interrupções de acesso do cliente ou tempos limite do cliente. Registros DNS incompletos ou incorretos para os Serviços de Domínio Ative Directory (AD DS) ou Arquivos NetApp do Azure podem causar interrupções de acesso do cliente ou tempos limite do cliente.
O serviço DNS é um componente crítico do acesso a dados nos Arquivos NetApp do Azure. O acesso ao protocolo de arquivo por SMB, Kerberos NFSV4.1, LDAP e Descoberta de Site do Ative Directory fazem uso significativo do DNS para suas operações. Usar um nome de host localizado centralmente no DNS simplifica o acesso a um volume e protege contra cenários quando um endereço IP muda. Em vez de um administrador precisar informar os usuários sobre um novo endereço IP, os usuários podem continuar usando o nome de host amigável.
Os servidores DNS são configurados em conexões do Ative Directory. Um servidor primário e secundário podem ser adicionados, bem como o nome DNS do Ative Directory.
Nota
Como prática recomendada, configure mais de um servidor DNS para redundância.
Sobre servidores DNS
Os Arquivos NetApp do Azure exigem uma conexão do Ative Directory para a funcionalidade Kerberos SMB e NFSv4.1. O Ative Directory requer DNS para a funcionalidade adequada. Na maioria dos casos, as implantações do Ative Directory são instaladas com servidores DNS integrados aos controladores de domínio. Essa configuração é uma prática recomendada da Microsoft para facilitar o uso e garantir que todos os registros DNS necessários sejam criados para serviços de domínio.
Em alguns casos, servidores DNS externos (como o BIND) podem ser usados em vez de (ou além de) serviços DNS hospedados no Ative Directory. Isso é chamado de namespace separado.
Os Arquivos NetApp do Azure dão suporte ao uso de servidores DNS integrados e externos, mas ao usar servidores DNS externos sem integração com o Ative Directory, é importante garantir que os registros de serviço (SRV) necessários sejam adicionados ao DNS para funcionalidade adequada e redundância de serviços. A má conectividade de rede entre os Arquivos NetApp do Azure e os servidores DNS pode causar interrupções de acesso do cliente ou tempos limite do cliente. Registros DNS incompletos ou incorretos para AD DS ou Arquivos NetApp do Azure podem causar interrupções de acesso do cliente ou tempos limite do cliente.
Consulte Registros DNS nos Arquivos NetApp do Azure para obter uma lista de registros SRV usados pelo serviço. Analise também as diretrizes para DNS com Ative Directory e Integração do AD DS em uma infraestrutura DNS existente.
Integração do DNS do Azure com os Arquivos NetApp do Azure
O DNS do Azure é um serviço de gerenciamento de DNS hospedado e resolução de nomes no Microsoft Azure. Você pode usá-lo para criar nomes DNS públicos ou privados para outros aplicativos e serviços implantados no Azure, incluindo Arquivos NetApp do Azure. A implantação do DNS no Azure evita a necessidade de enviar solicitações DNS (pela porta 53) diretamente entre os Arquivos NetApp do Azure e o DNS local e/ou um domínio do Ative Directory. Além disso, o DNS do Azure pode ser usado para criar encaminhadores condicionais (usando o resolvedor de DNS Privado do Azure) que podem ser usados para enviar solicitações DNS dos Arquivos NetApp do Azure para servidores DNS específicos por meio dos servidores DNS privados hospedados no Azure, que podem ser especificados para uso na conexão do Ative Directory.
Para obter informações sobre como usar o DNS do Azure:
- Como o DNS do Azure funciona com outros serviços do Azure
- Guia de início rápido: criar uma zona e um registro DNS do Azure usando o portal do Azure
- Guia de início rápido: criar uma zona DNS privada do Azure usando o portal do Azure
- Guia de início rápido: criar um resolvedor privado de DNS do Azure usando o portal do Azure
Usando endereços IP do balanceador de carga com DNS nos Arquivos NetApp do Azure
Um dispositivo de balanceador de carga é uma maneira de um único endereço IP ser usado para atender a vários endereços IP no back-end. Isso fornece segurança por meio de ofuscação, bem como benefícios de desempenho e redundância para ambientes corporativos.
Um balanceador de carga DNS pode atender solicitações e enviá-las para vários servidores DNS designados em um pool. O Microsoft Azure fornece serviços nativos de balanceamento de carga para vários casos de uso.
Os Arquivos NetApp do Azure dão suporte ao uso de balanceadores de carga DNS, desde que eles forneçam um endereço IP como ponto de extremidade e que o endereço IP possa se comunicar pela porta 53 para as redes do Azure NetApp Files. Por exemplo, o Azure Traffic Manager fornece balanceamento de carga DNS na camada 7, mas fornece apenas um nome de host front-end para uso. As conexões do Ative Directory dos Arquivos NetApp do Azure só permitem que endereços IP sejam especificados para servidores DNS.
Tipos de registros DNS nos Arquivos NetApp do Azure
Os Arquivos NetApp do Azure usam diferentes tipos de registros DNS para acessar serviços de arquivo.
| Tipo de registo DNS | Definição |
|---|---|
| A/AAAA | Os registros DNS A são registros de endereço que indicam o endereço IPv4 de um nome de host. Os registros AAAA indicam o endereço IPv6 de um nome de host. Os Arquivos NetApp do Azure usam registros A/AAAA das seguintes maneiras:
|
| Registros de ponteiro (PTR) | Um registro PTR mapeia um endereço IP para um nome de host por meio de uma zona de pesquisa inversa. Os registros PTR são usados principalmente quando um endereço IP é especificado para uma montagem/compartilhamento nos Arquivos NetApp do Azure. O uso de um endereço IP em solicitações de montagem/compartilhamento pode afetar o método de autenticação usado. Para obter mais informações, consulte Endereços IP para acesso com Kerberos. |
| Registros de serviço (SRV) |
Os registros SRV são usados para especificar quais hosts e portas são usados para um serviço específico, como LDAP, NFS, CIFS, Kerberos, etc. Os registros SRV nos Arquivos NetApp do Azure são muito utilizados para segurança de serviço de arquivo (como Kerberos), descoberta de site no Ative Directory, consultas de servidor LDAP e muito mais. É importante verificar a existência desses registros para a funcionalidade adequada dos serviços do Azure NetApp Files. Os registros SRV podem ser consultados usando nslookup comandos or dig . Para obter exemplos, consulte Usando nslookup e dig para consultas DNS. |
| Nomes canônicos (CNAME) | Um registro CNAME é uma maneira de fornecer aliases DNS para registros A/AAAA. Os registros CNAME são opcionais, mas podem ser úteis para reduzir a complexidade dos registros de nome de host fornecidos pelos Arquivos NetApp do Azure. Para obter mais informações, consulte Aliases DNS e Registros de nome canônico. |
| URI (Uniform Resource Identifier, identificador uniforme de recursos) | Um registro de URI é uma maneira de mapear nomes de host/endereços IP de serviços para URIs. Os URIs são apresentados em um formato como tal: service://fqdn.contoso.com. Os Arquivos NetApp do Azure usam consultas para registros URI somente ao executar pesquisas KDC Kerberos para solicitações Kerberos NFS. Os registros de URI não são criados em implantações de DNS do Ative Directory por padrão. Como tal, as solicitações de pesquisa de URI geralmente falham e retornam às pesquisas de registro SRV. |
Registros de serviço (SRV) usados com Arquivos NetApp do Azure
Os Arquivos NetApp do Azure usam os seguintes registros SRV:
-
NFS Kerberos*
- _kerberos-master._tcp. CONTOSO.COM (porta 88)*
- _kerberos-master._tcp. CONTOSO.COM (porta 88)*
-
Descoberta de site SMB/Ative Directory**
- _kerberos.CONTOSO.COM (porta 88)
- _kerberos._tcp. CONTOSO.COM (porta 88)
- _kerberos._tcp.dc_msdcs. CONTOSO.COM (porta 88)
- _kpasswd._tcp.dc._msdcs. CONTOSO.COM (porta 464)
- _kpasswd._tcp. CONTOSO.COM (porta 464)
- _kerberos._tcp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (porta 88)
- _kerberos._tcp. {outros nomes de sites}._sites.dc._msdcs. CONTOSO.COM (porta 88)
- _kerberos.udp.CONTOSO.COM (porta 88)
- _kerberos._udp.dc_msdcs. CONTOSO.COM (porta 88)
- _kpasswd._udp.dc._msdcs. CONTOSO.COM (porta 464)
- _kpasswd._udp. CONTOSO.COM (porta 464)
- _kerberos._udp. Default-First-Site-Name._sites.dc._msdcs. CONTOSO.COM (porta 88)
- _kerberos._udp. {outros nomes de sites}._sites.dc._msdcs. CONTOSO.COM (porta 88)
-
LDAP**
- _ldap.CONTOSO.COM (porta 389)
- _ldap._tcp. CONTOSO.COM (porta 389)
- _ldap._udp. CONTOSO.COM (porta 389)
* O DNS do Ative Directory não cria esses registros SRV por padrão. É altamente recomendável criá-los se estiver usando o NFS Kerberos.
** O DNS do Ative Directory cria esses registros SRV por padrão.
Para obter mais informações sobre como o Azure NetApp Files usa registros SRV, consulte:
Nota
Para a deteção e redundância adequadas do Centro de Distribuição de Chaves no Kerberos NFS, os registros URI e/ou os registros SRV kerberos-master devem ser criados.
DNS dinâmico
Os volumes de Arquivos NetApp do Azure fornecem um único endereço IP para um volume, que é adicionado ao DNS automaticamente por meio de DNS dinâmico (DDNS) (se o DNS dinâmico for suportado no servidor DNS). Nomes de host (em vez de endereços IP) são usados para caminhos de montagem de volume em configurações específicas. O uso de nomes de host em caminhos de montagem requer DNS para a funcionalidade adequada:
- Volumes SMB
- NFSv4.1 Kerberos
- Volumes de protocolo duplo
Kerberos NFSv4.1:
SMB
Protocolo duplo
Um endereço IP é usado para o caminho de montagem quando um volume de Arquivo NetApp do Azure não requer DNS, como NFSv3 ou NFSv4.1 sem Kerberos.
NFSv3
Considerações
Nos Arquivos NetApp do Azure, as atualizações dinâmicas de DNS enviam duas solicitações diferentes para o servidor DNS configurado: uma para um PTR e outra para uma criação/atualização de registro A/AAAA.
Os volumes dos Arquivos NetApp do Azure criados com nomes de host notificam automaticamente o servidor DNS para criar um registro A/AAAA. Isso acontece imediatamente após a conclusão da criação do volume.
Se um registro DNS A/AAAA já estiver presente para a combinação endereço IP/nome de host, nenhum novo registro será criado.
Se um registro DNS A/AAAA estiver presente para o mesmo nome de host com um endereço IP diferente , um segundo registro A/AAAA com o mesmo nome será criado.
Para volumes de Arquivos NetApp do Azure criados sem nomes de host (como volumes NFSv3), o DNS dinâmico não cria os registros DNS, pois não há nenhum nome de host atribuído no serviço. Os registos devem ser criados manualmente.
Se existir uma zona de pesquisa inversa para a sub-rede IP da interface, o servidor DNS também criará um registo PTR. Se a zona de pesquisa inversa necessária não existir, um registro PTR não poderá ser criado automaticamente. Você deve criar o registro PTR manualmente.
Se uma entrada DNS criada pelo DNS dinâmico for excluída no servidor DNS, ela será recriada em 24 horas por uma nova atualização de DNS dinâmico dos Arquivos NetApp do Azure.
O DDNS seguro é ativado quando volumes SMB ou de protocolo duplo são criados. Os volumes NFS não habilitam DDNS seguros, mas habilitam DDNS. Se o DDNS seguro estiver desativado no servidor DNS ou a autenticação Kerberos falhar, as atualizações DDNS não funcionarão.
Tipo de DNS dinâmico Porta DNS padrão PDU 53 DNS seguro TCP 53 Os Arquivos NetApp do Azure dão suporte a DDNS seguros somente com servidores DNS do Microsoft Ative Directory.
Detalhes de entrada de DNS dinâmico
Quando os Arquivos NetApp do Azure criam um registro DNS A/AAAA via DNS dinâmico, as seguintes configurações são usadas:
- Uma caixa de registro PTR associada está marcada: Se existirem zonas de pesquisa inversa para a sub-rede, os registros A/AAAA criarão automaticamente registros PTR sem intervenção do administrador.
- A caixa "Excluir este registro quando ele se tornar obsoleto" está marcada: Quando o registro DNS se torna "obsoleto", o DNS exclui o registro, desde que a eliminação de DNS tenha sido habilitada.
- O "tempo de vida (TTL)" do registro DNS é definido como um dia (24 horas): A configuração TTL pode ser modificada pelo administrador do DNS conforme necessário. O TTL em um registro DNS determina o período de tempo em que uma entrada DNS existe no cache DNS de um cliente.
Nota
Para exibir carimbos de data/hora e o tempo de vida (TTL) quando um registro DNS foi criado no DNS do Windows Ative Directory, navegue até o menu Exibir do Gerenciador DNS e selecione Avançado. A partir daí, selecione a entrada de registro A/AAAA e visualize as propriedades.
Como funciona o DNS dinâmico padrão nos Arquivos NetApp do Azure
Os Arquivos NetApp do Azure seguem quatro etapas básicas para criar atualizações de DNS dinâmicas para os servidores DNS configurados. As atualizações de DNS dinâmico padrão (DDNS) atravessam a porta UDP 53.
- Uma consulta DNS SOA para o endereço IP da interface de volume do Azure NetApp Files é executada.
- Uma atualização DDNS para o PTR é executada. Se o PTR não existir, ele é criado.
- Uma consulta DNS start of authority (SOA) é feita para o FQDN (nome de domínio totalmente qualificado) do volume Azure NetApp Files.
- Uma atualização DDNS para o registro A/AAAA é executada. Se o registro não existir, ele será criado.
DNS dinâmico via captura de pacotes
As capturas de pacotes podem ser úteis na solução de problemas de serviço que podem não ter registro disponível para análise. Expanda esta exibição para obter uma visão detalhada das capturas de pacotes.
Uma consulta DNS SOA para o endereço IP da interface de volume do Azure NetApp Files é executada.
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:1111Uma atualização DDNS para o PTR é executada. Se o PTR não existir, ele é criado.
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.localUma consulta DNS start of authority (SOA) é feita para o FQDN (nome de domínio totalmente qualificado) do volume Azure NetApp Files.
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:1111Uma atualização DDNS para o registro A/AAAA é executada. Se o registro não existir, ele será criado.
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
Como o DDNS seguro funciona nos Arquivos NetApp do Azure
Quando o DNS seguro está habilitado, os Arquivos NetApp do Azure negociam com o servidor DNS para autenticação via GSS usando a Autenticação de Transação de Chave Secreta para DNS, garantindo que as atualizações solicitadas sejam provenientes de uma fonte legítima. A seguir mostra as etapas usadas durante esse processo. As atualizações DDNS seguras atravessam a porta TCP 53.
- Uma consulta DNS SOA para o endereço IP da interface de volume do Azure NetApp Files é executada.
- Um tíquete de serviço Kerberos é trocado pelo serviço DNS no servidor DNS.
- O tíquete é usado em uma consulta DNS para uma chave de transação (TKEY) dos Arquivos NetApp do Azure para o servidor DNS, que é passada usando GSS-TSIG (assinatura de transação) para autenticar.
- Uma vez autenticada com sucesso, uma atualização de DNS dinâmico seguro é enviada usando o TKEY para criar o PTR é enviada usando GSS-TSIG. Se o registro ainda não existir, ele será criado.
- Uma consulta SOA DNS é enviada para o FQDN (nome de domínio totalmente qualificado) do volume Arquivos NetApp do Azure e respondida.
- Uma nova ID TKEY é trocada entre o servidor DNS e os Arquivos NetApp do Azure.
- Uma atualização de DNS dinâmico seguro é enviada usando o TKEY para criar o registro A/AAAA para o FQDN. Se o registro já existir com o mesmo endereço IP, nenhuma alteração será feita.
DNS dinâmico via captura de pacotes
As capturas de pacotes podem ser úteis na solução de problemas de serviço que podem não ter registro disponível para análise. Expanda esta exibição para obter uma visão detalhada das capturas de pacotes.
Uma consulta DNS SOA para o endereço IP da interface de volume do Azure NetApp Files é executada.
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:1111Um tíquete de serviço Kerberos é trocado pelo serviço DNS no servidor 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-REPO tíquete é usado em uma consulta DNS para uma chave de transação (TKEY) dos Arquivos NetApp do Azure para o servidor DNS, que é passada usando GSS-TSIG (assinatura de transação) para autenticar.
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 TSIGUma vez autenticada com sucesso, uma atualização de DNS dinâmico seguro é enviada usando o TKEY para criar o PTR é enviada usando GSS-TSIG. Se o registro ainda não existir, ele será criado.
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)Uma consulta SOA DNS é enviada para o FQDN (nome de domínio totalmente qualificado) do volume Arquivos NetApp do Azure e respondida.
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:1111Uma nova ID TKEY é trocada entre o servidor DNS e os Arquivos NetApp do Azure.
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 TSIGUma atualização de DNS dinâmico seguro é enviada usando o TKEY para criar o registro A/AAAA para o FQDN. Se o registro já existir com o mesmo endereço IP, nenhuma alteração será feita.
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)
Cache de DNS
Para reduzir a carga nos servidores DNS, os clientes DNS usam conceitos de cache para armazenar consultas anteriores na memória, de modo que solicitações repetidas para um nome de host, IP ou serviço sejam mantidas localmente pelo período de tempo definido pelo TTL do registro DNS.
Os Arquivos NetApp do Azure usam caches DNS como qualquer outro cliente DNS padrão. Quando o serviço solicita um registro DNS, esse registro tem um TTL definido. Por padrão, as entradas DNS do Ative Directory têm um TTL de 600 segundos (10 minutos), a menos que especificado de outra forma. Se um registro DNS for atualizado e permanecer no cache dos Arquivos NetApp do Azure e o TTL for de 10 minutos, o novo registro não será atualizado nos Arquivos NetApp do Azure até que o cache seja limpo após o valor de tempo limite. Atualmente, não há como limpar manualmente esse cache. Se desejar um TTL mais baixo, faça a alteração a partir do servidor DNS.
Ao usar servidores DNS externos (como BIND), os valores de tempo limite padrão podem ser diferentes. Se indefinido, o TTL de um registro DNS BIND é de 604.800 segundos (sete dias), muito longo para cache DNS eficaz. Como tal, ao criar registros DNS manualmente, é importante definir manualmente o TTL para o registro para um valor razoável. O uso do padrão da Microsoft de 10 minutos é recomendado para uma combinação de desempenho e confiabilidade para pesquisas de DNS.
Você pode consultar manualmente o TTL de um registro DNS usando nslookup comandos or dig . Para obter exemplos, consulte Usando nslookup e dig para consultas DNS.
Remoção / remoção de registros DNS
A maioria dos servidores DNS fornece métodos para eliminar e eliminar registos expirados. A remoção ajuda a evitar que registros obsoletos sobrecarreguem os servidores DNS e criem cenários onde existam registros A/AAAA e/ou PTR duplicados, o que pode criar resultados imprevisíveis para os volumes dos Arquivos NetApp do Azure.
Se vários registros PTR para o mesmo endereço IP apontarem para nomes de host diferentes, as solicitações Kerberos poderão falhar porque o SPN incorreto está sendo recuperado durante pesquisas de DNS. O DNS não discerne qual registro PTR pertence a qual nome de host; em vez disso, as pesquisas inversas realizam uma pesquisa round-robin através de cada registro A/AAAA para cada nova pesquisa.
Por exemplo:
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
Aliases DNS e registos CNAME (Canonical Name)
Os Arquivos NetApp do Azure criam um nome de host DNS para um volume que foi configurado para um protocolo que requer DNS para funcionalidade adequada, como SMB, protocolo duplo ou NFSv4.1 com Kerberos. O nome criado usa o formato do servidor SMB (conta de computador) como um prefixo ao criar a conexão do Ative Directory para a conta NetApp; caracteres alfanuméricos extras são adicionados para que várias entradas de volume na mesma conta NetApp tenham nomes exclusivos. Na maioria dos casos, vários volumes que exigem nomes de host e existem na mesma conta NetApp tentam usar os mesmos nomes de host/endereços IP. Por exemplo, se o nome do servidor SMB for SMB-West.contoso.com, as entradas de nome de host seguirão o formato de SMB-West-XXXX.contoso.com.
Em alguns casos, o nome usado pelos Arquivos NetApp do Azure pode não ser amigável o suficiente para ser transmitido aos usuários finais, ou os administradores podem querer manter nomes DNS mais familiares usados quando os dados migraram do armazenamento local para os Arquivos NetApp do Azure (ou seja, se o nome DNS original foi datalake.contoso.com, os usuários finais podem querer continuar usando esse nome).
Os Arquivos NetApp do Azure não permitem nativamente a especificação de nomes de host DNS usados. Se você precisar de um nome DNS alternativo com a mesma funcionalidade, deverá usar um alias DNS/nome canônico (CNAME).
Usar um registro CNAME (em vez de um registro A/AAAA adicional) que aponta para o registro A/AAAA do volume Azure NetApp Files aproveita o mesmo SPN que o servidor SMB para habilitar o acesso Kerberos para o registro A/AAAA e CNAME. Considere o exemplo de um registro A/AAAA de SMB-West-XXXX.contoso.com. O registro CNAME de datalake.contoso.com é configurado para apontar de volta para o registro A/AAAA de SMB-West-XXXX.contoso.com. As solicitações Kerberos SMB ou NFS feitas para datalake.contoso.com usam o SPN Kerberos para SMB-West-XXXX para fornecer acesso ao volume.
Usando nslookup e dig para consultas DNS
Os servidores DNS podem ser consultados manualmente usando ferramentas de DNS, como nslookup (clientes Windows e Linux) e dig (clientes Linux). O uso dessas ferramentas é útil em cenários que incluem a tentativa de verificar a funcionalidade dos serviços, o teste de resolução de nome de host/IP, a pesquisa de registros DNS existentes/obsoletos, a verificação da configuração do servidor, a verificação do TTL. Você também pode usar a solução de problemas de conexão do Azure para solução de problemas adicionais.
Os nslookup comandos e dig podem ser executados a partir de uma conexão remota com a VM (como do Bastion) ou diretamente com a VM por meio da opção de comando run na própria VM.
nslookup com Windows
Você pode executar nslookup para coletar informações básicas de endereço IP sem opções:
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
Para consultar apenas informações TTL para o registro, use a -query=hinfo opção de comando.
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)
A -debug opção também pode ser usada para reunir informações mais detalhadas sobre o registro 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)
dig com 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
Práticas recomendadas de DNS nos Arquivos NetApp do Azure
Certifique-se de atender aos seguintes requisitos de configuração de DNS:
- Especifique mais de um servidor DNS na configuração DNS para redundância.
- Para obter melhores resultados, use o DNS integrado e/ou instalado com o Ative Directory.
- Se estiver a utilizar servidores DNS autónomos:
- Verifique se os servidores DNS têm conectividade de rede com a sub-rede delegada dos Arquivos NetApp do Azure que hospeda os volumes dos Arquivos NetApp do Azure.
- Verifique se as portas de rede UDP 53 e TCP 53 não estão bloqueadas por firewalls ou grupos de segurança de rede.
- Verifique se os registros SRV registrados pelo serviço Logon de Rede do AD DS foram criados nos servidores DNS, bem como os registros de serviço listados em Tipos de registros DNS nos Arquivos NetApp do Azure.
- Verifique se os registros PTR para os controladores de domínio AD DS usados pelos Arquivos NetApp do Azure foram criados nos servidores DNS no mesmo domínio que sua configuração de Arquivos NetApp do Azure.
- Os Arquivos NetApp do Azure dão suporte a atualizações de DNS dinâmicas padrão e seguras. Se você precisar de atualizações de DNS dinâmicas seguras, certifique-se de que as atualizações seguras estejam configuradas nos servidores DNS.
- Verifique se uma zona de pesquisa inversa foi criada para a sub-rede Arquivos NetApp do Azure para permitir que o DNS dinâmico crie registros PTR além do registro A/AAAA.
- Se um alias DNS for necessário, use um registro CNAME. Aponte o registro CNAME para os registros A/AAAA dos Arquivos NetApp do Azure.
- Se você não estiver usando atualizações dinâmicas de DNS, deverá criar manualmente um registro A e um registro PTR para as contas de computador do AD DS criadas na Unidade Organizacional do AD DS (especificada na conexão do AD dos Arquivos NetApp do Azure) para dar suporte à Assinatura LDAP dos Arquivos NetApp do Azure, LDAP sobre TLS, SMB, protocolo duplo ou volumes Kerberos NFSv4.1.
- Para topologias do AD DS complexas ou grandes, as Políticas de DNS ou a priorização de sub-redes DNS podem ser necessárias para dar suporte a volumes NFS habilitados para LDAP.
- Se a eliminação de DNS estiver habilitada (onde as entradas DNS obsoletas são automaticamente removidas com base no carimbo de data/hora/idade) e o DNS dinâmico tiver sido usado para criar os registros DNS para o volume de Arquivos NetApp do Azure, o processo de eliminação poderá remover inadvertidamente os registros do volume. Essa remoção pode levar a uma interrupção do serviço para consultas baseadas em nome. Até que esse problema seja resolvido, crie manualmente entradas DNS A/AAAA e PTR para o volume Arquivos NetApp do Azure se a eliminação de DNS estiver habilitada.