Gostaria de saber se existe uma maneira de consultar um servidor DNS e ignorar o armazenamento em cache (com dig ). Muitas vezes eu 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, muitas vezes recebo as antigas. Reiniciar ou carregar o servidor não é realmente algo legal.
Você pode usar a sintaxe @ para pesquisar o domínio em um determinado servidor. Se o servidor DNS for autoritativo para esse domínio, a resposta não será um resultado armazenado em cache.
dig @ns1.example.com example.com
Você pode encontrar os servidores autoritativos solicitando os registros NS de um domínio:
dig example.com NS
Não existe uma maneira padrão e confiável de forçar um servidor de nomes a responder sem usar seu cache. Dig em si não é um servidor de nomes, é simplesmente uma ferramenta que passa sua consulta para qualquer servidor de nomes que você tenha configurado, usando solicitações DNS padrão. Existe uma maneira de dizer "não use recursão", mas isso não é o que você quer - simplesmente impediria qualquer pesquisa de nomes de domínio na Internet mais ampla.
Se você quiser impedir que um servidor de nomes responda a partir de seu cache, você deve conseguir isso alterando a configuração no servidor de nomes , mas se você não controlar o servidor de nomes, não faça isso.
Você pode, no entanto, obter acesso a ignorar os servidores de nomes configurados e executar sua própria solicitação recursiva que retorna aos servidores raiz. Para fazer isso, use a opção +trace .
dig example.com +trace
Na prática, como isso consultará apenas os servidores autoritativos em vez do resolvedor de cache local, o resultado não será obsoleto, mesmo se esses servidores empregarem o cache interno. O benefício adicional de usar +trace é que você consegue ver todas as solicitações separadas feitas ao longo do caminho.
Algo importante a ser observado aqui, que eu noto que muitas pessoas nunca incluem quando fala sobre +trace é que usar +trace significa que o cliente dig fará o rastreamento, não o servidor DNS especificado em sua configuração (/ etc / resolv.conf). Então, em outras palavras, seu cliente dig irá funcionar como um servidor DNS recursivo, se você pedir. Mas - importante, você não tem um cache.
Mais detalhes - assim, se você já pediu um registro mx usando dig -t mx example.com e seu /etc/resolv.conf é 8.8.8.8, então fazer qualquer coisa dentro do TTL da zona retornará o resultado armazenado em cache. De certa forma, se você está procurando algo sobre sua própria zona e como o Google a vê, você meio que envenenou seus resultados de DNS com o Google para o TTL da sua Zona. Nada mal se você tiver um TTL curto, um pouco ruim se você tiver um 1hr.
Assim, embora +trace ajude você a ver o que seria visto se estivesse perguntando ao Google pela PRIMEIRA vez e não tivesse uma entrada em cache, isso pode lhe dar uma ideia falsa de que o Google estará dizendo a todos o mesmo qual foi o resultado de +trace , o que não aconteceria se você tivesse perguntado anteriormente e tivesse um TTL longo, já que ele será exibido do cache até que o TTL expire - ENTÃO ele será exibido da mesma forma que o seu +trace revelado.
Não é possível ter muitos detalhes sobre o IMO.
Este bash vai cavar 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
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, mas simples o suficiente para que o problema não seja corrigido. dig não é minha especialidade -
melhorias bem-vindas: -)