Pergunta
É válido que um subdomínio use servidores de nomes diferentes para o domínio pai sem que os servidores DNS do domínio pai forneçam registros NS para o subdomínio?
Por exemplo:
Resolve-DnsName -Name example.com -Type NS -Server 1.1.1.1
Retornos em execuçãons1.example.com
; o mesmons1.example.com
acontece com o servidor de nomes oficial paraexample.com
.Resolve-DnsName -Name subdomain.example.com -Type NS -Server 1.1.1.1
Retornos em execuçãons2.example.com
; o mesmons2.example.com
acontece com o servidor de nomes oficial parasubdomain.example.com
.
Eu esperaria que isso ns1.example.com
contivesse o conjunto de registros NS para subdomain.example.com
informar ao cliente "Eu não gerencio os registros NS deste subdomínio, para eles, converse com seus servidores de nomes". Ou seja, eu esperaria Resolve-DnsName -Name subdomain.example.com -Type NS -Server ns1.example.com
voltar ns2.example.com
.
Nota: Se o subdomínio usasse os mesmos servidores NS que seu pai, eu não esperaria uma resposta ao acima.
( Resolve-DnsName é apenas um nslookup
comando, onde o Name
argumento é o FQDN a ser buscado, Server
é o servidor de nomes a ser consultado e Type
nos permite especificar o tipo de registro DNS que procuramos).
Meu entendimento está correto ou um subdomínio pode ter servidores de nomes diferentes de seu pai sem que seu domínio pai hospede registros NS para o subdomínio?
Contexto
Temos um problema intermitente com o MS Dynamics 365 for Finance and Operations onde, ocasionalmente, os usuários que navegam para uma instância verão o erro abaixo:
The site can’t be reached
Check if there is a typo in EXAMPLE.operations.dynamics.com
If spellling is correct, try running Windows Networkk Diagnostics.
DNS_PROBE_FINISHED_NXDOMAIN
Os usuários estão usando o URI/nome de host correto.
Normalmente, esse problema se resolverá após cerca de 30 minutos. Vemos isso tanto para produção ( EXAMPLE.operations.dynamics.com
quanto para teste ( EXAMPLE.sandbox.operations.dynamics.com
).
Na investigação, se eu tentar resolver o FQDN usando nosso serviço DNS corporativo, ele não será resolvido; confirmando o erro do navegador; mas quando resolvemos um serviço DNS público (por exemplo, o do CloudFlare 1.1.1.1
), as coisas geralmente resolvem corretamente. Observação: também vimos esse problema em que usuários que trabalham remotamente (que não usam nosso serviço DNS corporativo) têm o mesmo problema. Aqui, o serviço DNS do ISP mostra que não está conseguindo resolver o FQDN.
Acredito que o problema esteja relacionado ao DNS, e que o DNS do CloudFlare geralmente tem sido mais confiável, pois armazena em cache as entradas DNS por mais tempo (ou como seus servidores são atingidos com mais frequência, é mais provável que tenham entradas em cache).
Especificamente, quando há um problema ao resolver o FQDN para nosso ambiente, geralmente posso resolvê-lo no DNS do CloudFlare e nos servidores de nomes autorizados da MS para esse subdomínio (como seria de esperar)... mas tentando obter os servidores de nomes autorizados para o o subdomínio dos servidores de nomes autorizados para seu domínio pai falha; por exemplo, veja os 2 erros destacados abaixo:
Este é um problema com a minha compreensão do DNS (o que significa que a causa raiz dos nossos problemas requer mais investigação da nossa parte) ou é um problema de configuração com a implementação da MS?
Observação: entrei em contato com o suporte da MS para saber o que foi dito acima, mas a equipe que dá suporte ao Dynamics é uma equipe de suporte a aplicativos, portanto, não foi possível ajudar com problemas relacionados ao DNS/infraestrutura ou encaminhar meu ticket para uma equipe que pudesse ajudar.