Compreender os sistemas de nomes de domínio nos ficheiros NetApp do Azure
O serviço DNS (Sistemas de Nomes de Domínio) é um componente crítico do acesso a dados nos Arquivos NetApp do Azure ao usar protocolos de arquivo que dependem do Kerberos para autenticação (incluindo SMB e NFSv4.1). Um nome de host simplifica o acesso a um volume e protege contra cenários em que um endereço IP é alterado; em vez de informar os usuários de um novo endereço IP, eles podem continuar usando o nome do host.
Por padrão, a autenticação Kerberos aproveita a resolução de nome para endereço IP para formular o SPN (Nome da Entidade de Serviço) usado para recuperar o tíquete Kerberos. Por exemplo, quando um compartilhamento SMB é acessado com um caminho UNC (Convenção de Nomenclatura Universal), como \SMB.CONTOSO.COM, uma solicitação DNS é emitida para SMB.CONTOSO.COM e o endereço IP do volume Arquivos NetApp do Azure é recuperado. Se não houver nenhuma entrada DNS presente (ou se a entrada atual for diferente da solicitada, como com aliases/CNAMEs), um SPN adequado não poderá ser recuperado e a solicitação Kerberos falhará. Como resultado, o acesso ao volume pode ser desautorizado se o método de autenticação de fallback (como o New Technology LAN Manager) estiver desativado.
O Kerberos NFSv4.1 opera de maneira semelhante para recuperação de SPN, onde as pesquisas de DNS são parte integrante do processo de autenticação e também podem ser usadas para a descoberta de realm Kerberos.
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 AD DS ou Arquivos NetApp do Azure podem causar interrupções de acesso do cliente ou tempos limite do cliente.
Endereços IP para acesso com Kerberos
Se um endereço IP for usado em uma solicitação de acesso a um volume de Arquivos NetApp do Azure, uma solicitação Kerberos funcionará de forma diferente, dependendo do protocolo em uso.
SMB
Ao usar o SMB, uma solicitação para um UNC usando \x.x.x.x por padrão tenta usar NTLM para autenticação. Em ambientes onde o NTLM não é permitido por motivos de segurança, uma solicitação SMB usando um endereço IP não pode usar Kerberos ou NTLM para autenticação por padrão. Como resultado, o acesso ao volume de Arquivos NetApp do Azure é negado. Em versões posteriores do Windows (começando com o Windows 10 versão 1507 e Windows Server 2016), os clientes Kerberos podem ser configurados para suportar nomes de host IPv4 e IPv6 em SPNs para comunicação SMB.
NFSv4.1
Ao usar NFSv4.1, uma solicitação de montagem para um endereço IP usando uma das opções usa pesquisas de DNS reverso por meio de um registro de ponteiro (PTR) para resolver um endereço IP para um nome de host, que é usado para formular o SPN para recuperação de sec=[krb5/krb5i/krb5p] tíquetes. Se você usar NFSv4.1 com Kerberos, deverá ter um A/AAAA e PTR para o volume Arquivos NetApp do Azure para cobrir o acesso de nome de host e endereço IP às montagens.
Entradas DNS nos Arquivos NetApp do Azure
Os volumes do Azure NetApp Files dão suporte a atualizações de DNS dinâmicas se o servidor DNS der suporte a DNS dinâmico. Com o DNS dinâmico, os volumes criados com nomes de host notificam automaticamente o servidor DNS para criar um registro A/AAAA. Se existir uma zona de pesquisa inversa, o DNS também criará um registo PTR. Se a zona de pesquisa inversa não existir, um registro PTR não será criado automaticamente, o que significa que você precisará criá-lo manualmente.
Nomes de host (em vez de endereços IP) são usados para caminhos de montagem de volume em configurações específicas, que exigem DNS para funcionalidade adequada:
- Volumes SMB
- NFSv4.1 Kerberos
- Volumes de protocolo duplo
Um endereço IP é usado quando um volume de Arquivo NetApp do Azure não requer DNS, como NFSv3 ou NFSv4.1 sem Kerberos. Nesses casos, você pode criar manualmente uma entrada DNS, se desejar.
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.
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 registo DNS está definido para um dia (24 horas). A configuração TTL pode ser modificada pelo administrador de 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 de quando um registro DNS foi criado no DNS do Windows Ative Directory, navegue até o menu Exibir do Gerenciador DNS e selecione Avançado.
Remoção / remoção de registros DNS
A maioria dos servidores DNS fornece métodos para remover/remover registros 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.
Práticas recomendadas de DNS nos Arquivos NetApp do Azure
Certifique-se de atender aos seguintes requisitos sobre as configurações de DNS:
- 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.
- Certifique-se de que as portas de rede UDP 53 e TCP 53 não estão bloqueadas por firewalls ou NSGs.
- Verifique se os registros SRV registrados pelo serviço Logon de Rede do AD DS foram criados nos servidores DNS.
- 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.
- Se você não estiver usando atualizações dinâmicas de DNS, precisará criar manualmente um registro A e um registro PTR para a(s) conta(s) de computador do AD DS criada(s) 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 suportar 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.