TL;DR
O Azure NetApp Files (ANF) possui uma dependência crítica de DNS que não segue o padrão comum de serviços PaaS do Azure. Este artigo analisa a necessidade absoluta de configurar forwarders de DNS externos separados para tráfego cliente e tráfego de infraestrutura do ANF. A conclusão principal é que falhas de 'context deadline exceeded' ou erros de permissão NTFS frequentemente decorrem da ausência de regras de reverse lookup (PTR) no forwarder, exigindo configuração manual e precisa.
O que você precisa saber sobre o design de rede do ANF
O Azure NetApp Files (ANF) possui uma dependência rígida de DNS para volumes que integram com Active Directory (AD): SMB, dual-protocol (SMB + NFS) e NFSv4.1 com Kerberos. Diferente da maioria dos serviços PaaS do Azure, o ANF não utiliza Azure Private Link e não possui uma zona privatelink.*. Seus volumes são anexados diretamente a uma sub-rede delegada e os hostnames são registrados no DNS integrado ao AD via Secure Dynamic DNS (DDNS). Portanto, o design de DNS para o ANF é fundamentalmente diferente de um storage account ou SQL Database.
Este documento detalha o que o ANF exige para resolução de DNS, como configurar corretamente um external private DNS forwarder em topologias hub-spoke e Virtual WAN, além de requisitos não documentados que costumam causar falhas em deployments.
Nota: O ANF não herda as configurações de servidor DNS da VNET. Ele consulta exclusivamente os dois IPs de DNS configurados na AD connection da sua conta NetApp. As configurações de servidor DNS da VNET são irrelevantes para a criação de volumes e comportamento de join no AD.
Visão Geral da Arquitetura
O diagrama abaixo ilustra dois caminhos de DNS distintos que devem ser configurados em topologias com external private DNS forwarder. O caminho de resolução do cliente e o caminho interno de resolução do ANF são independentes e não devem ser misturados.
Nota: Os IPs de DNS da AD connection do ANF devem apontar diretamente para os IPs dos Domain Controllers (DCs) externos, e não para o forwarder. O forwarder cuida apenas da resolução do lado do cliente e deve possuir rulesets (regras) tanto Forward quanto Reverse para o domínio AD.
O que o DNS deve prover para o Azure NetApp Files
- Resolução de Saída (Outbound): O ANF deve conseguir resolver, a partir dos IPs do AD connection:
- Registros SRV de Domain Controller (ex:
_ldap._tcp.<site>._sites.dc._msdcs.<domain>). - Registros Kerberos KDC (ex:
_kerberos._tcp.<domain>). - Registros A (Forward lookup) para cada DC.
- Registros PTR (Reverse lookup) para cada DC.
- Registros SRV de Domain Controller (ex:
Por que o seu Forwarder não pode estar na AD Connection?
Os external private DNS forwarders (como Infoblox, BIND, etc.) não suportam GSS-TSIG, o protocolo que o ANF usa para registrar nomes de máquinas via DDNS. Se você apontar um forwarder na AD connection, as atualizações de DDNS serão descartadas silenciosamente, os hostnames não aparecerão no DNS e os mounts SMB falharão sem erro claro no portal.
Considerações de Roteamento em Virtual WAN
Em topologias de Virtual WAN com Routing Intent, o tráfego de retorno dos DCs para o ANF pode ser descartado se não houver um prefixo específico para a sub-rede delegada do ANF. Não basta ter o prefixo da VNET; adicione o /26 da sub-rede do ANF em Virtual WAN > Hub > Routing > Routing Intent > Private Traffic > Additional Prefixes.
Perguntas Frequentes
-
Por que o meu forwarder de DNS não funciona para o ANF?
O ANF utiliza o protocolo GSS-TSIG para registros Secure Dynamic DNS (DDNS) com o Active Directory, protocolo este que não é suportado por forwarders externos (como Infoblox ou BIND). Você deve apontar as configurações de DNS no AD connection do ANF diretamente para os IPs dos Domain Controllers (DCs) graváveis. -
O que causa o erro 'Cannot determine whether the computer named is joined to a domain' ao configurar permissões NTFS?
Este erro é tipicamente causado pela falta de uma regra de reverse lookup (PTR) no seu forwarder de DNS externo para a sub-rede dos seus Domain Controllers. O ANF realiza uma validação interna via 'secd' que exige a resolução reversa para completar a autenticação Kerberos. -
Devo usar o IP 168.63.129.16 no AD connection do ANF?
Não. O IP 168.63.129.16 é o resolvedor interno do Azure, mas não é 'AD-aware'. Ele não consegue responder consultas SRV do domínio nem aceitar atualizações de DDNS. Ele apenas deve atuar como um upstream forwarder no seu servidor DNS externo para resolver nomes de serviços do Azure.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
