Entender sistemas de nomes de domínio no Azure NetApp Files

  • Artigo

O serviço DNS (Domain Name Systems) é um componente crítico do acesso a dados no Azure NetApp Files 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 quando 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 de 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 do Azure NetApp Files é recuperado. Se não houver nenhuma entrada DNS presente (ou 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 poderá ser desabilitado se o método de autenticação de fallback (como New Technology LAN Manager) estiver desabilitado.

O NFSv4.1 Kerberos opera de maneira semelhante para recuperação de SPN, em que as pesquisas de DNS são parte integrante do processo de autenticação e também podem ser usadas para a descoberta de realm do Kerberos.

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 servidores Azure NetApp Files e DNS pode causar interrupções de acesso do cliente ou tempos limite do cliente. Registros DNS incompletos ou incorretos para o AD DS ou o Azure NetApp Files podem causar interrupções de acesso 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 para um volume do Azure NetApp Files, uma solicitação Kerberos funcionará de maneira diferente, dependendo do protocolo em uso.

PME

Ao usar o SMB, uma solicitação para um UNC usando \x.x.x.x.x por padrão tenta usar o NTLM para autenticação. Em ambientes em que 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 do Azure NetApp Files é 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 dar suporte a nomes de host IPv4 e IPv6 em SPNs para comunicação SMB.

NFSv4.1

Ao usar o NFSv4.1, uma solicitação de montagem para um endereço IP usando uma das opções sec=[krb5/krb5i/krb5p] usa pesquisas de DNS reverso por meio de um PTR (registro de ponteiro) para resolver um endereço IP para um nome de host, que é usado para formular o SPN para recuperação de tíquete. Se você usar NFSv4.1 com Kerberos, deverá ter um A/AAAA e PTR para o volume do Azure NetApp Files para cobrir o nome do host e o acesso de endereço IP às montagens.

Entradas DNS no Azure NetApp Files

Os volumes do Azure NetApp Files dão suporte a atualizações DNS dinâmicas se o servidor DNS dá 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 registro 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.

Os 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 uma funcionalidade adequada:

  • Volumes SMB
  • NFSv4.1 Kerberos
  • Volumes de protocolo duplo

Um endereço IP é usado quando um volume de Arquivo do Azure NetApp 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 dentro de 24 horas por uma nova atualização DNS dinâmica do Azure NetApp Files.

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 esse 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.
  • A "TTL (vida útil)" do registro DNS está definida 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 de quando um registro DNS foi criado no DNS do Windows Active Directory, navegue até o menu Exibir do Gerenciador DNS e selecione Avançado.

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 ser passado para usuários finais ou 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.

Melhores práticas de DNS do Azure NetApp Files

Verifique se você atende aos seguintes requisitos sobre as configurações de DNS:

  • Se você estiver usando servidores DNS autônomos:
    • Verifique se os servidores DNS têm conectividade de rede para 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 NSGs.
  • Verifique se os registros SRV registrados pelo serviço de Logon do AD DS Net foram criados nos servidores DNS.
  • 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.
  • Se as atualizações dinâmicas de DNS não forem usadas, será necessário 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 AD do Azure NetApp Files) para oferecer suporte à assinatura LDAP do Azure NetApp Files, LDAP sobre TLS, SMB, protocolo duplo ou volumes Kerberos NFSv4.1.
  • Para topologias complexas ou grandes do AD DS, as políticas de DNS ou a priorização da 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.

Próximas etapas