mas a tentativa de obter os servidores de nomes autorizados para o subdomínio a partir dos servidores de nomes autorizados para seu domínio pai falha

Isso parece mais uma falha do PowerShell do que uma falha de DNS. O Wireshark me disse que o servidor deu uma resposta bem-sucedida – mas é uma referência que possui os registros NS na seção ‘Autoridade’, não na seção ‘Resposta’ (a “cópia pai” dos registros NS não produz respostas – ela é usado apenas para referências) e o PowerShell aparentemente não espera isso.

Tente fazer a mesma consulta usando outras ferramentas:

• Windows nslookup -d -q=NS operations.dynamics.com. ns1-205.azure-dns.com.
  (ignore a consulta PTR que aparece, o nslookup sempre faz uma)

• Linux/WSLdig operations.dynamics.com. NS @ns1-205.azure-dns.com.

Eu recomendaria ter uma versão muito recente do dig, pois ela suporta DNS EDE – Extended Error Data, que permite que um resolvedor como o 1.1.1.1 forneça informações muito mais detalhadas sobre por que está fornecendo um SERVFAIL. (Isso não está realmente relacionado aos seus erros do PowerShell, pois você estava consultando diretamente um servidor autoritativo sem qualquer intermediário; é mais uma recomendação geral.)

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?

As duas listas deveriam corresponder, mas as coisas continuariam funcionando enquanto os registros NS no domínio pai apontassem para um conjunto de servidores de nomes válidos. Conjuntos incompatíveis de registros NS não são estritamente corretos, mas podem passar despercebidos por muito tempo.

A lista NS nos servidores de nomes de subdomínios é o que você obtém de uma -Type NSconsulta manual em resolvedores públicos, mas apenas a lista NS nos servidores de nomes pais é o que será usado para referências de pai para filho (porque, é claro, o conteúdo dos servidores de nomes filhos não pode possivelmente ser conhecido nesse ponto ainda).

Portanto, se o subdomínio realmente tiver mais servidores de nomes ausentes na cópia pai da lista NS, isso não deverá causar falhas - os servidores de nomes extras permanecerão sem uso (mesmo que apareçam em uma -Type NSconsulta manual em resolvedores públicos).

Então, para resumir:

• Se a lista pai estiver incompleta, então os servidores ausentes simplesmente não serão usados, mesmo que a zona filha os liste (e igualmente, se o filho tiver entradas falsas, eles não serão usados).

  Este é o único problema relatado pelo DNSViz para o seu domínio.

• Se a lista pai tiver servidores de nomes estranhos que não foram configurados para hospedar o domínio filho (ou seja, eles retornam REFUSED ou uma referência lateral), isso é um grande problema e fará com que você veja SERVFAILs.

• Se a lista da criança estiver incompleta, você só notará isso nas -Type NSconsultas, mas caso contrário, nada acontecerá.

• Se a própria lista da criança tiver servidores de nomes estranhos, você também notará isso apenas em consultas manuais, mas, caso contrário, nada acontecerá – eles não serão contatados pelos resolvedores.

Por exemplo, se a zona pai (example.com) tiver:

sub.example.com. NS ns1.example.com.
sub.example.com. NS ns2.example.com.

e a zona filha (sub.example.com) tem:

sub.example.com. NS ns2.example.com.
sub.example.com. NS ns3.example.com.
sub.example.com. NS ns4.example.com.

então espera-se que ambos ns1/ns2 sejam os servidores autorizados, enquanto ns3/ns4 não será usado para nada, mesmo que fazer uma -Type NSconsulta explícita retorne "NS ns2, ns3, ns4"

Se, no entanto, você tiver essa configuração, mas o ns1/ns2 não estiver configurado para hospedar a zona filha, eles responderão com um REFUSED ao resolvedor e isso se propagará como um SERVFAIL para você. Além disso, ns1/ns2 não tem permissão para responder com uma "referência lateral" para ns3/ns4 – você receberá um SERVFAIL se isso ocorrer.