Forçar escavação para resolver sem usar cache

Gostaria de saber se existe uma maneira de consultar um servidor DNS e ignorar o cache (com dig). Frequentemente, mudo uma zona no servidor DNS e quero verificar se ele resolve corretamente da minha estação de trabalho. Mas como o servidor armazena em cache as solicitações resolvidas, geralmente recebo as antigas. Reiniciar ou carregar o servidor não é algo realmente agradável.

Você pode usar a @sintaxe para procurar o domínio de um servidor específico. Se o servidor DNS tiver autoridade para esse domínio, a resposta não será um resultado em cache.

dig @ns1.example.com example.com

Você pode encontrar os servidores autorizados solicitando os NSregistros de um domínio:

dig example.com NS

Não há mecanismo no protocolo DNS para forçar um servidor de nomes a responder sem usar seu cache. A escavação em si não é um servidor de nomes, é simplesmente uma ferramenta que transmite sua consulta aos servidores de nomes que você configurou, usando solicitações DNS padrão. DNS faz incluir uma maneira de dizer a um servidor não usar recursividade, mas isso não é o que você quer. Isso é útil apenas quando você deseja consultar diretamente um servidor de nomes autoritativo.

Se você quiser impedir que um servidor de nomes responda a partir de seu cache, você só poderá fazer isso alterando a configuração no servidor de nomes , mas se você não controlar o servidor de nomes, isso será impossível.

No entanto, você pode obter dig para ignorar os servidores de nomes configurados e executar sua própria solicitação recursiva, que volta aos servidores raiz. Para fazer isso, use a +traceopção

dig example.com +trace

Na prática, uma vez que isso consultará apenas os servidores autorizados em vez do resolvedor de armazenamento em cache local, o resultado não será obsoleto, mesmo que esses servidores utilizem armazenamento em cache interno. O benefício adicional de usar +traceé que você pode ver todos os pedidos separados feitos ao longo do caminho.

Algo importante a ser observado aqui, que noto que muitas pessoas nunca incluem quando se fala, +traceé que usar +tracesignifica que o cliente dig fará o rastreamento, não o servidor DNS especificado em sua configuração (/etc/resolv.conf). Portanto, em outras palavras, seu cliente Dig funcionará como um servidor DNS recursivo, caso você o solicite. Mas - importante, você não tem um cache.

Mais detalhes - portanto, se você já pediu um mxregistro usando dig -t mx example.come seu /etc/resolv.conf é 8.8.8.8, fazer qualquer coisa dentro do TTL da zona retornará o resultado em cache. De certa forma, se você está procurando algo sobre sua própria zona e como o Google a vê, meio que envenenou seus resultados de DNS com o Google pelo TTL da sua zona. Não é ruim se você tiver um TTL curto, um pouco de lixo se você tiver um 1hr.

Portanto, embora +traceo ajude a ver o que seria visto se você estivesse perguntando pela primeira vez ao Google e não tivesse entrada em cache, pode ser uma idéia falsa de que o Google dirá a todos o mesmo que seu +traceresultado, o que isso não acontecerá se você tiver solicitado anteriormente e tiver um TTL longo, pois ele servirá a partir do cache até o TTL expirar - ENTÃO servirá da mesma forma que o que você +tracerevelou.

Não pode ter muitos detalhes IMO.

Este bash irá escavar as entradas DNS do example.com do seu primeiro servidor de nomes listado:

dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer

• A escavação interna consulta o DNS do Google (8.8.8.8) para obter os servidores de nomes da example.com.
• A escavação externa consulta o servidor de nome do example.com.

Aqui está o mesmo que um alias para um .zshrc (e provavelmente .bashrc):

# e.g. `checkdns google.com`
checkdns () { dig @$(dig @8.8.8.8 $1 ns +short | head -n1) $1 ANY +noall +answer; ping -c1 $1; }

Aqui está a saída para / .:

☀  checkdns slashdot.org                                                                                                dev
-->Server DNS Query

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.dnsmadeeasy.com. slashdot.org ANY +noall +answer
; (2 servers found)
;; global options: +cmd
slashdot.org.       21600   IN  SOA ns0.dnsmadeeasy.com. hostmaster.slashdotmedia.com. 2016045603 14400 600 604800 300
slashdot.org.       86400   IN  NS  ns3.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns4.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns0.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns2.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns1.dnsmadeeasy.com.
slashdot.org.       3600    IN  MX  10 mx.sourceforge.net.
slashdot.org.       3600    IN  TXT "google-site-verification=mwj5KfwLNG8eetH4m5w1VEUAzUlHotrNwnprxNQN5Io"
slashdot.org.       3600    IN  TXT "v=spf1 include:servers.mcsv.net ip4:216.34.181.51 ?all"
slashdot.org.       300 IN  A   216.34.181.45
-->Local DNS Query
PING slashdot.org (216.34.181.45) 56(84) bytes of data.
64 bytes from slashdot.org (216.34.181.45): icmp_seq=1 ttl=242 time=33.0 ms

--- slashdot.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.026/33.026/33.026/0.000 ms

Essa solução é complicada o suficiente para ser impraticável de lembrar, mas simples o suficiente para que o problema não seja resolvido. dignão é minha especialidade - melhorias são bem-vindas :-)