Entender sistemas de nomes de domínio no Azure NetApp Files
O Azure NetApp Files dá suporte ao uso de servidores DNS integrados do Active Directory ou DNS autônomos e requer acesso confiável aos serviços DNS (Sistema de Nomes de Domínio) e registros DNS atualizados. A conectividade de rede ruim entre o Azure NetApp Files e os servidores DNS pode causar interrupções de acesso do cliente ou tempos limite do cliente. Registros DNS incompletos ou incorretos do AD DS (Serviços Domínio do Active Directory) ou do Azure NetApp Files 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 no Azure NetApp Files. O acesso ao protocolo de arquivo por SMB, NFSV4.1 Kerberos, LDAP e Active Directory Site Discovery fazem uso significativo do DNS para suas operações. O uso de um nome de host localizado centralmente no DNS simplifica o acesso a um volume e protege contra cenários quando um endereço IP é alterado. 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 Active Directory. Um servidor primário e secundário pode ser adicionado, bem como o nome DNS do Active Directory.
Observação
Como prática recomendada, configure mais de um servidor DNS para redundância.
Sobre servidores DNS
O Azure NetApp Files requer uma conexão do Active Directory para a funcionalidade SMB e NFSv4.1 Kerberos. O Active Directory requer DNS para a funcionalidade adequada. Na maioria dos casos, as implantações do Active 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 BIND) podem ser usados em vez de (ou além) de serviços DNS hospedados no Active Directory. Isso é chamado de um namespace desarticulado.
O Azure NetApp Files dá suporte ao uso de servidores DNS integrados e externos, mas ao usar servidores DNS externos sem integração com o Active Directory, é importante garantir que os registros SRV (serviço necessário) sejam adicionados ao DNS para a funcionalidade adequada e a redundância de serviços. A conectividade de rede ruim entre o Azure NetApp Files e os servidores DNS pode causar interrupções de acesso do cliente ou tempos limite do cliente. Registros DNS incompletos ou incorretos do AD DS ou do Azure NetApp Files podem causar interrupções de acesso do cliente ou tempos limite do cliente.
Consulte registros DNS no Azure NetApp Files para obter uma lista de registros SRV que o serviço usa. Examine também as diretrizes para DNS com o Active Directory e Integrando o AD DS a uma infraestrutura DNS existente.
Integração do DNS do Azure com o Azure NetApp Files
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 o Azure NetApp Files. A implantação do DNS no Azure impede a necessidade de enviar solicitações DNS (pela porta 53) diretamente entre o Azure NetApp Files e o DNS local e/ou um domínio do Active Directory. Além disso, o DNS do Azure pode ser usado para criar encaminhadores condicionais (usando o resolvedor DNS privado do Azure) que podem ser usados para enviar solicitações DNS do Azure NetApp Files para servidores DNS específicos por meio dos servidores DNS privados hospedados no Azure, que podem ser especificados para uso na conexão do Active Directory.
Para obter informações sobre como usar o DNS do Azure:
- Como o Azure DNS funciona com outros serviços do Azure
- Início Rápido - Criar uma zona DNS do Azure e registrar usando o portal do Azure
- 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 no Azure NetApp Files
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 empresariais.
Um balanceador de carga DNS pode atender solicitações e enviá-las para vários servidores DNS designados em um pool. Microsoft Azure fornece serviços de balanceamento de carga nativos para vários casos de uso.
O Azure NetApp Files dá suporte ao uso de balanceadores de carga DNS, desde que eles forneçam um endereço IP como um 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 Gerenciador de Tráfego do Azure fornece balanceamento de carga DNS na camada 7, mas fornece apenas um nome de host front-end para uso. As conexões do Active Directory do Azure NetApp Files só permitem que endereços IP sejam especificados para servidores DNS.
Tipos de registros DNS no Azure NetApp Files
O Azure NetApp Files usa diferentes tipos de registros DNS para acesso aos serviços de arquivos.
| Tipos de registro DNS | Definição |
|---|---|
| A/AAAA | DNS Registros A são registros de endereço que indicam o endereço IPv4 para um nome de host. Os registros AAAA indicam o endereço IPv6 para um nome de host. O Azure NetApp Files usa 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 no Azure NetApp Files. 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 Configurando Kerberos para endereços IP. |
| SRV (Registros de serviço) |
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 no Azure NetApp Files são muito utilizados para segurança do serviço de arquivo (como Kerberos), descoberta de site no Active Directory, consultas de servidor LDAP e muito mais. É importante verificar a existência desses registros quanto à funcionalidade adequada dos serviços do Azure NetApp Files. Registros SRV podem ser consultados usando comandos nslookup ou dig. Para obter exemplos, consulte Usando nslookup e dig para consultas DNS. |
| Nomes Canonical (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 pelo Azure NetApp Files. Para obter mais informações, consulte aliases DNS e registros de nome Canonical. |
| URI (Uniform Resource Identifier) | Um registro de URI é uma maneira de mapear nomes de host/endereços IP para serviços para URIs. AS URIs são apresentadas em um formato como esse: service://fqdn.contoso.com. Azure NetApp Files usa consultas para registros de URI somente ao executar pesquisas de KDC Kerberos para solicitações Kerberos NFS. Os registros de URI não são criados em implantações DNS do Active Directory por padrão. Dessa forma, as solicitações de pesquisa de URI geralmente falham e retornam para pesquisas de registro SRV. |
Registros de serviço (SRV) usados com o Azure NetApp Files
O Azure NetApp Files usa os seguintes registros SRV:
-
NFS Kerberos*
- _kerberos-master._tcp.CONTOSO.COM (porta 88)*
- _kerberos-master._tcp.CONTOSO.COM (porta 88)*
-
Descoberta de site do SMB/Active 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.{other site names}._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.{other site names}._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 Active Directory não cria esses registros SRV por padrão. É altamente recomendável criá-los se estiver usando o NFS Kerberos.
** O DNS do Active Directory não cria esses registros SRV por padrão.
Para obter mais informações sobre como o Azure NetApp Files usa registros SRV, consulte:
Observação
Para a descoberta e redundância adequadas do Centro de Distribuição de Chaves no NFS Kerberos, os registros de URI e/ou registros SRV kerberos-master devem ser criados.
DNS dinâmico
Os volumes do Azure NetApp Files fornecem um único endereço IP para um volume, que é adicionado ao DNS automaticamente por meio de DNS dinâmico (DDNS) (se houver suporte para DNS dinâmico no servidor DNS). Os 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 exige DNS para a funcionalidade adequada:
- Volumes SMB
- NFSv4.1 Kerberos
- Volumes de protocolo duplo
NFSv4.1 Kerberos:
SMB
Protocolo duplo
Um endereço IP é usado para o caminho de montagem quando um volume de Arquivo do Azure NetApp não requer DNS, como NFSv3 ou NFSv4.1 sem Kerberos.
NFSv3
Considerações
No Azure NetApp Files, as atualizações DNS dinâmicas 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 do Azure NetApp Files 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 de endereço IP/nome do 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 do Azure NetApp Files 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 registros 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 registro 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 dentro de 24 horas por uma nova atualização DNS dinâmica do Azure NetApp Files.
O DDNS seguro é habilitado quando os volumes de protocolo duplo ou SMB são criados. Os volumes NFS não habilitam o DDNS seguro, mas habilitam o DDNS. Se o DDNS seguro estiver desabilitado no servidor DNS ou a autenticação Kerberos falhar, as atualizações DDNS não funcionarão.
Tipo DNS dinâmico Porta DNS Standard UDP 53 DNS seguro TCP 53 O Azure NetApp Files dá suporte a DDNS seguro somente com servidores DNS do Microsoft Active Directory.
Detalhes da entrada DNS dinâmica
Quando o Azure NetApp Files cria um registro DNS A/AAAA por meio de DNS dinâmico, as seguintes configurações são usadas:
- Uma caixa de registro PTR associada é marcada: se houver zonas de pesquisa inversas 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 ficar obsoleto” é marcada: quando o registro DNS se torna " obsoleto", O DNS exclui o registro, desde que a limpeza para DNS tenha sido habilitada.
- O TTL (tempo de vida útil)” do “registro DNS é definido como um dia (24 horas): a configuração de TTL pode ser modificada pelo administrador DNS, conforme necessário. O TTL em um registro DNS determina o tempo que uma entrada DNS existe no cache DNS de um cliente.
Observação
Para exibir carimbos de data/hora e o TTL (Time to Live) quando um registro DNS foi criado no DNS do Windows Active Directory, navegue até o menu Exibir do Gerenciador DNS e selecione Avançado. A partir daí, selecione a entrada de registro A/AAAA e exiba as propriedades.
Como o DNS dinâmico padrão funciona no Azure NetApp Files
O Azure NetApp Files segue quatro etapas básicas para criar atualizações DNS dinâmicas para os servidores DNS configurados. As atualizações DNS dinâmicas padrão (DDNS) atravessam UDP porta 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 será criado.
- Uma consulta SOA (início de autoridade) DNS é feita para o FQDN (nome de domínio totalmente qualificado) do volume do 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 por meio da captura de pacotes
Capturas de pacotes podem ser úteis para solucionar problemas de serviço que podem não ter log disponível para analisar. Expanda essa exibição para uma análise 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 será 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 SOA (início de autoridade) DNS é feita para o FQDN (nome de domínio totalmente qualificado) do volume do 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 no Azure NetApp Files
Quando o DNS seguro está habilitado, o Azure NetApp Files negocia com o servidor DNS para autenticar via GSS usando Autenticação de Transação de Chave Secreta para DNS, garantindo que as atualizações solicitadas sejam provenientes de uma fonte legítima. O exemplo a seguir mostra as etapas usadas durante esse processo. Atualizações DDNS seguras atravessam a porta 53 do TCP.
- 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.
- Em seguida, o tíquete é usado em uma consulta DNS para uma TKEY (chave de transação) do Azure NetApp Files para o servidor DNS, que é passado usando GSS-TSIG (assinatura de transação) para autenticar.
- Depois de autenticada com êxito, uma atualização DNS dinâmica segura é 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 do Azure NetApp Files e respondida.
- Uma nova ID TKEY é trocada entre o servidor DNS e o Azure NetApp Files.
- Uma atualização DNS dinâmica segura é 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 por meio da captura de pacotes
Capturas de pacotes podem ser úteis para solucionar problemas de serviço que podem não ter log disponível para analisar. Expanda essa exibição para uma análise 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-REPEm seguida, o tíquete é usado em uma consulta DNS para uma TKEY (chave de transação) do Azure NetApp Files para o servidor DNS, que é passado 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 TSIGDepois de autenticada com êxito, uma atualização DNS dinâmica segura é 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 do Azure NetApp Files 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 o 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 TSIGUma atualização DNS dinâmica segura é 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 DNS
Para reduzir a carga em servidores DNS, os clientes DNS usam conceitos de cache para armazenar consultas anteriores na memória para que as solicitações de repetição de um nome de host, IP ou serviço sejam mantidas localmente durante o período de tempo definido pelo TTL do registro DNS.
O Azure NetApp Files usa 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 Active Directory têm um TTL de 600 segundos (10 minutos), a menos que especificado de outra forma. Se um registro DNS for atualizado e estiver no cache do Azure NetApp Files e o TTL for de 10 minutos, o novo registro não será atualizado no Azure NetApp Files até que o cache seja limpo após o valor do tempo limite. No momento, não há como limpar manualmente esse cache. Se um TTL inferior for desejado, faça a alteração 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 será de 604.800 segundos (sete dias), muito longo para o cache DNS efetivo. Dessa forma, ao criar registros DNS manualmente, é importante definir manualmente o TTL para o registro como 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 a TTL de um registro DNS usando comandos nslookup ou dig. Para obter exemplos, consulte Usando nslookup e dig para consultas DNS.
Remoção/limpeza de registro DNS
A maioria dos servidores DNS fornece métodos para remover/limpar registros expirados. A remoção ajuda a impedir que registros obsoletos desorganizem servidores DNS e criem cenários em que existem registros A/AAAA e/ou PTR duplicados, o que pode criar resultados imprevisíveis para volumes do Azure NetApp Files.
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, pesquisas inversas realizam uma pesquisa round robin por meio 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 registros CNAME (Nome Canônico)
O Azure NetApp Files cria um nome de host DNS para um volume que foi configurado para um protocolo que requer DNS para a 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 Active Directory para a conta do NetApp; caracteres alfanuméricos extras são adicionados para que várias entradas de volume na mesma conta do NetApp tenham nomes exclusivos. Na maioria dos casos, vários volumes que exigem nomes de host e existem na mesma conta do 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 SMB-West-XXXX.contoso.com.
Em alguns casos, o nome usado pelo Azure NetApp Files pode não ser amigável o suficiente para passar para os usuários finais, ou seja, os administradores podem querer manter nomes DNS mais familiares usados quando os dados migraram do armazenamento local para o Azure NetApp Files (ou seja, se o nome DNS original foi datalake.contoso.com, os usuários finais podem querer continuar usando esse nome).
O Azure NetApp Files não permite 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/CNAME (nome canônico).
Usar um registro CNAME (em vez de um registro A/AAAA adicional) que aponta para o registro A/AAAA do volume A/AAAA do Azure NetApp Files aproveita o mesmo SPN que o servidor SMB para habilitar o acesso Kerberos para o registro A/AAAA e o CNAME. Considere o exemplo de um registro A/AAAA de SMB-West-XXXX.contoso.com. O registro CNAME de datalake.contoso.com está configurado para apontar de volta para o registro A/AAAA de SMB-West-XXXX.contoso.com. Solicitações Kerberos SMB ou NFS feitas para datalake.contoso.com usar 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 DNS, como nslookup (clientes Windows e Linux) e dig (clientes Linux). Usar essas ferramentas é útil em cenários, incluindo a tentativa de verificar a funcionalidade de serviços, testar o nome do host/resolução de IP, pesquisar registros DNS existentes/obsoletos, verificar a configuração do servidor, verificar a TTL. Você também pode usar a solução de problemas de conexão do Azure para solucionar problemas adicionais.
Os comandos nslookup e dig podem ser executados de uma conexão remota com a VM (como do Bastion) ou diretamente para a VM por meio da opção de comando executar na própria VM.
nslookup com Windows
Você pode executar nslookup para coletar informações básicas de endereço IP sem nenhuma opção:
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 opção de comando -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)
A opção -debug também pode ser usada para coletar 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
Melhores práticas de DNS do Azure NetApp Files
Verifique se você atende 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 Active Directory.
- Se você estiver usando servidores DNS autônomos:
- Verifique se os servidores DNS têm conectividade de rede com a sub-rede delegada do Azure NetApp Files que hospeda os volumes do Azure NetApp Files.
- 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 de Logon do AD DS Net foram criados nos servidores DNS, bem como os registros de serviço listados em tipos de registros DNS no Azure NetApp Files.
- Verifique os registros PTR para os controladores de domínio do AD DS usados pelo Azure NetApp Files tenham sido criados nos servidores DNS no mesmo domínio da configuração do Azure NetApp Files.
- O Azure NetApp Files dá suporte a atualizações DNS dinâmicas seguras e padrão. Se você precisar de atualizações DNS dinâmicas seguras, verifique se as atualizações seguras estão configuradas nos servidores DNS.
- Verifique se uma zona de pesquisa inversa foi criada para a sub-rede do Azure NetApp Files 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 do Azure NetApp Files.
- Se você não estiver usando atualizações DNS dinâmicas, 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 Azure NetApp Files AD) para dar suporte aos volumes LDAP De Assinatura do Azure NetApp Files, LDAP via TLS, SMB, protocolo duplo ou volumes Kerberos NFSv4.1.
- Para topologias complexas ou grandes do AD DS, políticas DNS ou priorização de sub-rede DNS podem ser necessárias para dar suporte a volumes NFS habilitados para LDAP.
- Se a limpeza de DNS estiver habilitada (em que as entradas DNS obsoletas são automaticamente removidas com base no carimbo de data/hora) e o DNS dinâmico foi usado para criar os registros DNS para o volume do Azure NetApp Files, o processo de catador pode inadvertidamente podar os registros do volume. Essa remoção poda pode levar a uma interrupção de serviço para consultas baseadas em nome. Até que esse problema seja resolvido, crie manualmente entradas DNS A/AAAA e PTR para o volume do Azure NetApp Files se a limpeza de DNS estiver habilitada.