dig lookup não retornando namservers

4

Depois de adicionar alguns nameservers ao meu domínio para subdelegação eu vejo que se eu executar um rastreio e / ou consultar os servidores de nomes diretamente eu recebo os servidores de nomes corretos, no entanto se eu consultar os registros nameserver apenas através de uma escavação eu não obter uma resposta,

A busca recursiva no DNS não deve parar no momento em que ele recupera os registros NS (nsX.macmonster.co.uk) do dns2.stabletransit.com e passa isso de volta para o cliente?

Os registros recém-adicionados do servidor de nomes são:

subdomain.codecrab.org. 300     IN      NS      ns1.macmonster.co.uk.
subdomain.codecrab.org. 300     IN      NS      ns2.macmonster.co.uk.

TRACE

    ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> +trace subdomain.codecrab.org ns
;; global options:  printcmd
.                       94441   IN      NS      f.root-servers.net.
.                       94441   IN      NS      g.root-servers.net.
.                       94441   IN      NS      h.root-servers.net.
.                       94441   IN      NS      i.root-servers.net.
.                       94441   IN      NS      j.root-servers.net.
.                       94441   IN      NS      k.root-servers.net.
.                       94441   IN      NS      l.root-servers.net.
.                       94441   IN      NS      m.root-servers.net.
.                       94441   IN      NS      a.root-servers.net.
.                       94441   IN      NS      b.root-servers.net.
.                       94441   IN      NS      c.root-servers.net.
.                       94441   IN      NS      d.root-servers.net.
.                       94441   IN      NS      e.root-servers.net.
;; Received 228 bytes from 83.138.151.80#53(83.138.151.80) in 0 ms

org.                    172800  IN      NS      a0.org.afilias-nst.info.
org.                    172800  IN      NS      b2.org.afilias-nst.org.
org.                    172800  IN      NS      c0.org.afilias-nst.info.
org.                    172800  IN      NS      a2.org.afilias-nst.info.
org.                    172800  IN      NS      d0.org.afilias-nst.org.
org.                    172800  IN      NS      b0.org.afilias-nst.org.
;; Received 442 bytes from 192.5.5.241#53(f.root-servers.net) in 96 ms

codecrab.org.           86400   IN      NS      dns2.stabletransit.com.
codecrab.org.           86400   IN      NS      dns1.stabletransit.com.
;; Received 95 bytes from 199.19.56.1#53(a0.org.afilias-nst.info) in 108 ms

subdomain.codecrab.org. 300     IN      NS      ns1.macmonster.co.uk.
subdomain.codecrab.org. 300     IN      NS      ns2.macmonster.co.uk.
;; Received 92 bytes from 65.61.188.4#53(dns2.stabletransit.com) in 0 ms

;; connection timed out; no servers could be reached

QUESTÃO PADRÃO

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.6 <<>> subdomain.codecrab.org NS
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 50516
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;subdomain.codecrab.org.                IN      NS

;; Query time: 1 msec
;; SERVER: 83.138.151.80#53(83.138.151.80)
;; WHEN: Thu Sep 26 16:32:34 2013
;; MSG SIZE  rcvd: 40

Adicional

[root@monty webtools]# dig ns1.macmonster.co.uk +short
1.1.1.1

Alguma idéia?

    
por rick3d 26.09.2013 / 18:33

3 respostas

6

Um resolvedor de DNS recursivo requer que as informações que ele adquire recursivamente sejam autoritativas para retorná-lo como uma resposta a uma consulta; não faz inferências.

A autoridade é estabelecida no DNS usando registros SOA e NS. O primeiro é usado para estabelecer autoridade entre servidores autoritativos e é servido de dentro da zona. Por exemplo, o registro SOA indica qual cópia dos dados da zona é mais recente quando os servidores DNS autoritativos de alguma zona estão fazendo uma transferência de zona. Este último é usado para estabelecer autoridade ao consultar.

Quando um registro NS de um subdomínio está em um domínio e o servidor que o possui não é um servidor autoritativo para o nome que está sendo consultado, esse registro NS é um registro de delegação. Portanto, o resolvedor recursivo consultará os registros de delegação começando com a raiz . . No seu caso, ele sobe a cadeia em direção a essa resposta de dns2.stabletransit.com. :

subdomain.codecrab.org. 300     IN      NS      ns1.macmonster.co.uk.

Este é um registro de delegação, porque esses dados não existem:

subdomain.codecrab.org. 300     IN      NS      dns2.stabletransit.com

O que realmente existiu foi isto:

codecrab.org.           86400   IN      NS      dns2.stabletransit.com.

Portanto, o servidor em dns2.stabletransit.com. pode fornecer respostas autoritativas para codecrab.org. , porque o resolvedor anterior delegou essa zona a ele. Mas não é autoritativo para subdomain.codecrab.org. , portanto, não pode responder à consulta; só pode delegar.

Os resolvedores de DNS podem, é claro, ser configurados como autorizados para qualquer nome que o administrador desejar. No entanto, se eles estiverem configurados para serem autoritativos para as zonas que estão tentando delegar, eles fornecerão respostas (sem os dados), portanto, isso obviamente não é feito.

A maneira como a recursão funciona é simples, se não inicialmente intuitiva. O resolvedor recursivo envia a consulta completa para os servidores de nomes para . (que tem em seu arquivo de dicas para a zona raiz). O servidor de nomes . envia uma resposta, mas uma resposta tem dois componentes que nos interessam para essa finalidade: a seção de autoridade e a seção de resposta (há também a seção adicional e a seção de perguntas). A resposta conterá registros como:

org.                    172800  IN      NS      b0.org.afilias-nst.org.

Isso diz ao resolvedor recursivo para repetir sua consulta por lá, porque a zona é delegada. Ele também inclui "cola" na seção adicional, fornecendo os endereços IP dos servidores de nomes na seção de autoridade, porque sabe que você não conseguirá encontrar o servidor de nomes para consultá-lo de outra forma. Esta é uma decisão administrativa no gerenciamento do DNS; se os registros de cola não estiverem presentes, o resolvedor recursivo consultará os registros AAAA ou A de um dos servidores autoritativos antes de prosseguir.

Então, você pode perceber que quando você envia sua consulta IN NS subdomain.codecrab.org. para a última delegação, dns2.stabletransit.com. , a resposta é assim:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35461
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;subdomain.codecrab.org.                IN      NS

;; AUTHORITY SECTION:
subdomain.codecrab.org. 300     IN      NS      ns2.macmonster.co.uk.
subdomain.codecrab.org. 300     IN      NS      ns1.macmonster.co.uk.

;; Query time: 104 msec
;; SERVER: 65.61.188.4#53(65.61.188.4)
;; WHEN: Sat Sep 28 14:50:45 MDT 2013

Observe como você não obtém nem uma seção adicional nem uma seção de resposta (mas também NOERROR para o status de retorno). Isso ocorre porque o registro é uma delegação para ns2.macmonster.co.uk. para subdomain.codecrab.org. , para o qual dns2.stabletransit.com. sabe que não é autoritativo. Não há seção adicional porque os namesevers estão em co.uk. e administrativamente não foi necessário incluir cola porque eles são resolvíveis por lá (embora, certamente, a cola possa ter sido incluída). Então, para responder sua consulta, porque a resposta tem que vir de uma seção de resposta (significando que ela é identificada pelo servidor respondente como resposta, vindo da autoridade), seu resolvedor recursivo tentará encontrar ns1.macmonster.co.uk. , e encontrá-lo em 1.1.1.1 , enviará sua consulta para lá.

Claro que (como este endereço está em um prefixo de debogon) não há nenhum servidor de nomes lá (ainda). Quanto a ns2.macmonster.co.uk. at 2.2.2.2 , se alguém da Wanadoo France decidisse que deveria haver um servidor de nomes com registros de autoridade para subdomain.codecrab.org. e, em particular:

subdomain.codecrab.org 99999999 IN NS now.go.away.or.i.will.taunt.you.a.second.time.

metade do tempo (sempre que esse servidor de nomes for escolhido), a consulta retornará now.go.away.or.i.will.taunt.you.a.second.time. como o servidor de nomes da sua zona, embora o senso comum sugira que seja ns2.macmonster.co.uk. (e mesmo que tenha sido esse último servidor de nomes que autoritativamente deu essa resposta).

    
por 28.09.2013 / 23:01
3

@ Zoredache respondeu à pergunta em um comentário. O rastreamento de escavação mostra a resposta, os servidores de nomes no nível do domínio não resolvem:

subdomain.codecrab.org. 300     IN      NS      ns1.macmonster.co.uk.
subdomain.codecrab.org. 300     IN      NS      ns2.macmonster.co.uk.
;; Received 92 bytes from 65.61.188.4#53(dns2.stabletransit.com) in 0 ms

dig: couldn't get address for 'ns1.macmonster.co.uk': not found

... assim, ambas as consultas de digitação falharam, mas a saída do + trace mostrou onde ela falhou. Quando você executa o dig + trace, está seguindo o caminho que um servidor DNS seguiria para resolver a consulta, iniciando nos servidores de nomes "raiz". Sua segunda consulta perguntou ao seu servidor DNS (83.138.151.80), que fez a mesma coisa (efetivamente), mas quando não conseguiu resolver o ns1 / ns2.macmonster.co.uk, então ele falhou e não deu uma resposta . Para obter uma resposta, esses servidores de nomes precisarão resolver para endereços IP que estejam executando o DNS para esse subdomínio, e os resultados da consulta NS para esses servidores serão a resposta que será retornada.

~ tommy

    
por 26.09.2013 / 19:43
1

Problema: Seus registros de delegação estão corretos, mas os servidores de nomes usados (ns1.macmonster.co.uk e ns2.macmonster.co.uk) não possuem endereços IP corretos. No meu caso, ns1.macmonster.co.uk tem IP 1.1.1.1 e n2.macmonster.co.uk tem IP 2.2.2.2. Esses endereços IP são reais e válidos, mas não acredito que esses endereços IP estejam apontando para servidores DNS.

Como corrigir: Suponho que você tenha usado esses servidores de nome por algum motivo. Esclareça com macmonster.co.uk porque esses servidores de nomes não podem ser conectados pela Internet (talvez eles sejam apenas para fins locais ou de Intranet) ou use servidores de nomes diferentes para sua delegação.

Por que isso não funciona: Hmm, se a minha memória me serve bem, havia uma história de Asterix e Obelix tentando obter um passe / distintivo A38 e eles devem correr de sala em sala para chegar isto. No entanto, o DNS é mais amigável do que isso. Se você pedir host1.subdominio.codecrab.org. seu DNS tenta resolver isso para um endereço IP. Ele pede org. para codecrab.org., codecrab.org. para subdomain.codecrab.org. e subdomain.codecrab.org. para host1.subdomínio.codecrab.org. Se esta cadeia não funcionar - a resolução de DNS falha.

    
por 28.09.2013 / 21:52