Comutados netblocks, novo DNS resolvendo PTR para o antigo DNS IP - por que?

Question

Um pouco de um problema estranho aqui e espero que alguém possa ajudar a descrever e / ou corrigir comigo. Estávamos em uma rede / 24 A.A.A.A e recentemente mudamos para B.B.B . Os servidores de nomes foram todos atualizados com o registrador, eles mostram no servidor de nomes raiz e tudo - até aí tudo bem, certo? Eu posso cavar os servidores raiz e obter os novos IPs, whois é bom e tudo o que "está ligado?" trabalho de base parece ótimo.

Estou executando o DNS na nova rede em B.B.B.254 e na antiga rede em A.A.A.254 conforme as alterações ainda se propagam pelo mundo. O servidor DNS A.A.A.254 está, na verdade, alimentando o mundo com os IPs B.B.B.B para detectar os que ainda não viram as mudanças do upstream, negócios normais. Cada servidor também executa DNS reverso para seu próprio intervalo de IP.

SO! No registro de consultas no servidor antigo A.A.A.254 estou vendo uma solicitação estranha para a zona PTR de B.B.B.254 para sua própria rede IP reversa B! E é sempre para dois IPs - meu firewall (.4) e servidor VPN (.6) - nenhum outro além desses dois.

04-Aug-2009 09: 56: 09.755 cliente B.B.B.254 # 37384: consulta: 4.B.B.B.in-addr.arpa EM PTR +

04-Aug-2009 10: 00: 05.380 cliente B.B.B.254 # 37385: consulta: 6.B.B.B.in-addr.arpa EM PTR +

Por que há uma consulta como esta, pedindo a zona IP que B.B.B.254 já hospeda, indo para o meu servidor A.A.A.254 ?! Eu não deveria estar vendo nenhuma pergunta de B.B.B.254 para A.A.A.254 , mas ainda estou recebendo esses trabalhos estranhos PTR que eu não consigo entender. Um 'dig-x' de B não faz com que ele vá para A, então não é nada simples. Eu vasculhei todos os arquivos de configuração em B (é uma caixa linux / bind9) para qualquer referência à rede A, não consigo encontrar nada.

Alguém tem a menor ideia do que está acontecendo aqui e como posso corrigi-lo? Por que o novo servidor B está pedindo A para este PTR, quando ele sabe que ele hospeda esse intervalo?

Eu segui várias trilhas, como:

dig + norecurse 4.B.B.in-addr.arpa PTR @ x.arin.net

... então ...

dig + norecurse 4.B.B.B.in-addr.arpa PTR @a. [nome do servidor de autoridade]

... e tudo parece certo. Qualquer idéia é bem-vinda, onde mais adiante procurar o que está causando esse loop de solicitação, estou perdendo um pouco o que ver a seguir.

    

Answer 1

Esses trechos de log são literalmente separados dos endereços IP?

Se assim for, parece surpreendente que, ao longo de um intervalo de 4 minutos, não houve aparentemente nenhum outro tráfego IP, conforme indicado pela porta de origem dessas consultas, que subiu apenas um.

Eu sugiro que você tente confirmar que realmente é B.B.B.254 enviando essas consultas (execute tcpdump no host remetente).

Se puder, tente descobrir qual processo está causando isso. Se for named no novo servidor, ative mais registros para descobrir por que ( rndc trace e rndc querylog ).

Observe que, se você estiver renumerando sua rede e reconfigurando suas máquinas sem removê-las, todos os daemons de longa execução ainda poderão ter o antigo /etc/resolv.conf armazenado em cache neles.

Se dispersando para a área de programação, isso ocorre porque o /etc/resolv.conf é lido apenas pela função res_init() da biblioteca de resolução na primeira vez em que qualquer programa chama gethostbyname() ou gethostbyaddr() . A biblioteca do resolvedor não detecta mudanças no arquivo de configuração na hora.

    

Answer 2

O resolv.conf está com B.B.B.254 configurado para enviar solicitações ao servidor DNS antigo? (Não deveria ser, porque recursivo e autoritário não deveria se misturar). Além disso, o B.B.B.254 talvez esteja configurado como o gateway padrão para um intervalo RFC1918 com o NAT? Nesse caso, algo por trás dessa máquina pode ser configurado incorretamente em uma resolução recursiva.

Além disso, ter intervalos de IP reais pode ser útil, para que as pessoas possam realmente examinar suas delegações.

    

Answer 3

Estou feliz (em êxtase!) por informar que foi resolvido - a criança problemática era, na verdade, syslogd em b.b.b.254 ! Alnitak me mandou para o caminho certo, depois de executar uma captura do tcpdump na máquina bbb254 várias vezes e colocar o named no debug level 5 eu me deparei com o fato de que a consulta DNS estava sendo feita, ainda não estava vindo do processo nomeado. / p>

Não sou especialista em syslogd, mas tem algo a ver com o fato de esse syslogd ser executado no modo de log remoto e aceitar os logs dos dispositivos em questão (.4, .6). Mesmo que estivesse funcionando corretamente na nova rede, algo em seu pequeno daemon brain ainda armazenava informações da rede antiga (eu não entendo como, embora) e foi esse processo fazendo a requisição PTR para o antigo servidor DNS o novo intervalo de IP reverso. Um simples '/etc/init.d/syslogd restart' limpou as solicitações erradas e agora tudo está bem.

São sempre as coisas simples no final, são necessárias apenas 8 horas de depuração para chegar lá. :)

    

Answer 4

Filmado no escuro: tem certeza de que todos os caches de DNS estão limpos? Eu vi coisas estranhas como essa, porque algo tinha uma visão desatualizada do DNS em algum cache que não estava sendo liberado por algum motivo ...