Início / computer / Perguntas / 1867050
Accepted
WoJ
Asked: 2024-12-22 19:45:14 +0800 CST

O que significa "Nenhuma autoridade alcançável na delegação"? (também conhecido como registro NS não retornado pelo DNS)

  • 772

Eu possuo um domínio (doravante chamado de example.com), ele está registrado na OVH. Ele tem alguns registros Ae MX, todos são servidos corretamente pelos servidores DNS da OVH.

Agora, quero delegar home.example.compara um servidor doméstico (PiHole) em 192.168.10.2. Este servidor DNS está ativo e servindo muitos registros corretamente.

Para delegar o subdomínio, adicionei o seguinte à example.comzona DNS:

home           IN NS    ns-home.example.com.
ns-home        IN A     192.168.10.2

O OVH incrementa automaticamente o serial da zona. Para ter certeza de que está correto, eu o verifiquei:

root@srv ~# dig @1.1.1.1 example.com SOA

example.com. 3600 IN SOA dns102.ovh.net. tech.ovh.net. 2024122001 86400 3600 3600000 60

2024122001é o que também vejo na zona DNS na OVH. Então a nova versão da zona foi implantada.

O problema : o Aregistro é retornado corretamente, mas NSnão:

root@srv ~# dig @1.1.1.1 ns-home.example.com A
ns-home.example.com. 3600 IN A 192.168.10.2

dig @1.1.1.1 home.example.com NS
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 22 (No Reachable Authority): (at delegation home.example.com.)
;; QUESTION SECTION:
;home.example.com.               IN      NS

O que essa resposta significa? O que mais deve ser feito para delegar o subdomínio?

Eventualmente, moverei o NSregistro para o servidor de nomes local com um registro de colagem, por enquanto gostaria que ele funcionasse neste cenário mais simples

networking

1 respostas

  1. Best Answer

    A consulta que você fez NSera recursiva 1 ; o que significa que a resposta não viria dos registros de delegação na OVH – na verdade, ela seguiria a delegação até o fim e retornaria os registros NS na zona do seu PiHole.

    Mas os registros NS da delegação apontam para um endereço IP privado, 192.168.10.2, que o resolvedor 1.1.1.1 do CloudFlare não consegue alcançar – então ele nunca conseguirá resolver nada por trás dessa delegação, nem qualquer outro resolvedor público. É isso que a segunda resposta significa; significa "1.1.1.1 não conseguiu contatar 'ns-home.example.com' em 192.168.10.2" (ns-home sendo a "autoridade").

    Tenha em mente: o servidor que você especifica usando @não é apenas o "ponto de partida" para dig; é o servidor que faz toda a busca de delegação para você, enquanto o dig em si não faz nada além de esperar por uma resposta - que é exatamente como seu sistema operacional também lida com consultas DNS.

    Portanto, não basta que as delegações tenham registros A/AAAA que sejam acessíveis da perspectiva do cliente; eles também precisam ser acessíveis da perspectiva do resolvedor .

    Então, se você tiver certeza absoluta de que o resolvedor será interno à sua própria rede (como, por exemplo, se todos os seus PCs consultarem seu PiHole local, e o PiHole executar o Unbound ou o BIND9 para perseguir delegações localmente sem depender de nenhum upstream) – então, claro, sua configuração atual funcionaria, mas você deve testá-la com dig @<pihole_ip>em vez de dig @<random_public_resolver>.

    No entanto, se você quiser que o subdomínio delegado (e seus sub-subdomínios) seja resolvível usando qualquer servidor público, então a delegação tem que ser feita para um endereço IP acessível publicamente. Você teria que verificar qual software DNS o PiHole está executando, se ele é adequado para ser exposto à Internet (ou seja, avaliação de segurança), configurar o "encaminhamento de porta" para TCP/53 e UDP/53 do seu gateway LAN principal para o PiHole (para IPv4) e, finalmente, alterar o ns-homeA/AAAA para apontar para seu endereço IPv4 público (e/ou o IPv6 público do PiHole).

    1 A consulta tinha a opção "Recursão desejada" definida, que é o padrão para dig e também é a única maneira de obter uma resposta do 1.1.1.1 ou de outro resolvedor.

    Desativar essa opção pode ser feito usando +norecurseou +nordflag, mas uma consulta não recursiva tem que ser feita diretamente contra os servidores autoritativos – ou seja, servidores que já possuem os dados DNS para seu domínio. E se você disser ao 'dig' para consultar em um servidor autoritativo... então especificar +norecursese torna meio redundante.

    Então, se você quisesse testar especificamente se a OVH publicou seu registro NS corretamente, você teria que fazer:

    dig [+norecurse] @nsXXX.ovh.net home.example.com NS

    Alternativamente, ferramentas que podem seguir o caminho da delegação:

    • dnstracer -s . home.example.com
    • delv [-i] +ns home.example.com
      ( -isuprime a validação DNSSEC para uma saída mais mínima)
    • dig +trace home.example.com
      (pode ser menos preciso)
    • DNSViz .
    • 1

relate perguntas