O cache de DNS retorna SERVFAIL para registro NS, mas dig + trace discorda?

Question

Esta questão é semelhante, mas não elabora sobre o caso confuso de um porque um NS de registro não pode ser obtido.

Um dos nossos ambientes DNS em cache (RHEL 5.8, BIND 9.3.6-20.P1.el5_8.4) deixou de retornar dados úteis para uma zona. Normalmente, esse tipo de problema acaba sendo um registro NS ou cola antigo, mas neste caso em particular, parece que nem consigo que o cache informe um registro NS da zona.

• dig @mycache somedomain NS retorna SERVFAIL . Não há registros de servidores de nomes armazenados em cache.
• dig +trace mostra um caminho de delegação saudável, com o servidor de nomes final retornando uma resposta. Executar manualmente a consulta dig no servidor de nomes final retorna um registro NS válido, o registro A correspondente existe e concorda com a cola, etc.

O que dá? Por que não há um registro NS para eu obter do cache do DNS, nem mesmo um mau?

    

Answer 1

Se não houver resposta autoritativa para um registro NS , não haverá nada para armazenar em cache além da falha na determinação da autoridade. Isso é o que foi armazenado em cache e as informações na memória de um servidor sobre servidores de nomes lame não podem ser obtidas por um cliente DNS. (ou melhor, isso é o mais próximo que você vai conseguir)

Normalmente, você pode identificar um problema com registros antigos do servidor de nomes comparando o registro NS no cache com o que você encontra na Internet, mas, nesse caso, não há nenhum registro autoritativo NS no cache. Os registros de cola não são autoritários em si mesmos; sem resposta autoritativa, simplesmente não há nenhum servidor de nomes com autoridade .

Uma das duas coisas geralmente está acontecendo aqui:

1. dig +trace está obtendo uma resposta obsoleta para um servidor de nomes intermediário do seu cache local, e realmente há um problema acontecendo no momento. Cobri esse comportamento em outra pergunta.
2. O servidor de cache encontrou NXDOMAIN ou SERVFAIL ao perseguir registros de cola para localizar um servidor de nomes autoritativo e esse evento foi armazenado em cache. Mesmo que o problema tenha sido corrigido, ou a cola tenha sido apontada para algum outro lugar, o servidor de nomes não tentará solicitá-lo novamente até que um temporizador interno expire. Solicitar uma limpeza de cache para a zona em questão geralmente a redefine.

O último caso é geralmente o culpado. Se você quiser ter absoluta certeza, pode ser possível despejar o cache de tempo de execução do seu servidor de nomes e ver a cola na memória. (por exemplo, rndc dumpdb do BIND) Esteja ciente de que esta é uma operação muito cara, a menos que você possa limitar o escopo do dump a uma única zona, e geralmente algo a ser evitado em cenários de alta carga.