Estamos utilizando servidores DNS do Windows 2016+. Contamos com LocalNetPriority em nossos servidores DNS. Temos vários servidores DNS do Active Directory em vários sites. O comportamento esperado é que quando uma consulta específica é feita ao servidor DNS, ela retornará um endereço IP que está na mesma sub-rede que a consulta originada, se existirem vários registros A para o mesmo host. Isso funciona bem na maioria dos casos.
No entanto, para solicitações originadas do próprio servidor DNS, ele não funciona. Primeiro, o servidor DNS (ou Active Directory), por padrão, configura sua interface de rede para usar a si mesmo como o servidor DNS de sua escolha via localhost (127.0.0.1 e ::1). Isso faz com que a seleção LocalNetPriority falhe, pois o endereço IP de origem não está em uma de nossas sub-redes.
Em segundo lugar, o servidor está preferindo IPv6 em vez de IPv4. Não usamos IPv6, mas também não queremos desativá-lo, pois claramente causou problemas no passado em diferentes cenários, e a Microsoft afirma que é obrigatório e não oferece suporte ou recomenda desativá-lo. Usar IPv6 está fora de questão.
Finalmente, isso deve funcionar quando houver interrupções na rede. Esse requisito específico exige que o localnetpriority funcione corretamente quando a localização do satélite for separada do restante da rede. Portanto, o uso de resolvedores de DNS de mesmo nível como servidor principal não atende a esse requisito sozinho.
Parece que configurar o IPv4 para ser a prioridade sobre o IPv6 e configurar o endereço IP real do servidor como o servidor DNS de escolha pode ser a única solução. No entanto, aprendi há muito tempo que usar 127.0.0.1 é a melhor escolha porque durante uma reinicialização ou se um cabo de rede for desconectado, o diretório ativo pode desmoronar completamente.
o que estou perdendo? Existe uma maneira mais direta de resolver esse problema? Talvez eu deva apenas adicionar uma entrada de arquivo HOSTS para o host específico com o qual estamos tendo problemas.
Para o resolvedor de um servidor DNS, configure primeiro o endereço IP de um servidor DNS diferente , o endereço IP deste servidor DNS em segundo lugar e o IP do host local em terceiro.
Mesmo quando o serviço DNS está reiniciando, ele ainda pode ser resolvido a partir do servidor remoto. Além disso, ao usar o AD DS, um host diferente primeiro tem menos probabilidade de causar problemas de replicação.
Sim, preferir o IPv6 é um comportamento padrão e a Microsoft não testa a desabilitação do IPv6. Se você não usar IPv6, não atribua endereços IPv6 aos hosts. Inclusive, certifique-se de que os roteadores não enviem RAs IPv6. Se houver apenas registros A para um nome e não AAAA, os hosts resolverão e usarão IPv4, sem necessidade de configuração adicional.
Para resolver esse problema, tive que considerar várias coisas:
Depois de tudo isso, descobri que a melhor solução é alterar as configurações do servidor DNS na interface de rede e não fazer outras alterações em nada no Windows. Para resolver todas as preocupações acima, eu:
<Peer DNS Server IP><IPv4 address of this DNS server>127.0.0.1(Localhost)Quaisquer reclamações relacionadas da BPA foram resolvidas. Localnetpriority funciona quando a rede está totalmente funcional e quando o site é cortado devido a uma falha de rede. E o AD ainda funcionará normalmente, mesmo se o cabo de rede local estiver desconectado ou ocorrer algum outro problema de interface de rede.
O resultado final responde à pergunta: " Como fazer o localnetpriority funcionar quando o servidor DNS consulta a si mesmo? " Com um requisito secundário de não quebrar mais nada.