Início / server / Perguntas / 372066
Accepted
Daniel
Asked: 2012-03-22 09:15:48 +0800 CST

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

  • 772

Eu estou querendo saber se existe uma maneira de consultar um servidor DNS e ignorar o cache (com dig). Muitas vezes eu mudo uma zona no servidor DNS e quero verificar se ela resolve corretamente na 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 é realmente algo legal.

linux domain-name-system dig

5 respostas

  1. Best Answer

    Você pode usar a @sintaxe para pesquisar o domínio de um servidor específico. Se o servidor DNS for autoritativo 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
    • 194

  2. Não há mecanismo no protocolo DNS para forçar um servidor de nomes a responder sem usar seu cache. O Dig em si não é um servidor de nomes, é simplesmente uma ferramenta que passa sua consulta para os servidores de nomes que você configurou, usando solicitações DNS padrão. O DNS inclui uma maneira de dizer a um servidor para não usar recursão, mas isso não é o que você deseja. Isso só é útil quando você deseja consultar diretamente um servidor de nomes autoritário.

    Se você quiser impedir que um servidor de nomes responda 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 é impossível.

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

    dig example.com +trace

    Na prática, como isso só consultará os servidores autorizados em vez do seu resolvedor de cache local, o resultado não ficará obsoleto, mesmo que esses servidores empreguem o cache interno. O benefício adicional de usar +traceé que você consegue ver todas as solicitações separadas feitas ao longo do caminho.

    • 50

  3. Algo importante a ser observado aqui, que noto que muitas pessoas nunca incluem quando falam , +traceé que usar +tracesignifica 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 de escavação funcionará como um servidor DNS recursivo, se você perguntar. Mas - importante, você não tem um cache.

    Mais detalhes - então, 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ê, você meio que envenenou seus resultados de DNS com o Google para o TTL de sua zona. Nada mal se você tiver um TTL curto, um pouco ruim se você tiver um de 1 hora.

    Portanto, embora +traceajude você a ver o que SERIA visto se você estivesse perguntando ao Google pela PRIMEIRA vez e não tivesse uma entrada em cache, pode dar uma falsa ideia de que o Google estará dizendo a todos o mesmo que seu +traceresultado, o que não será se você tiver perguntado anteriormente e tiver um TTL longo, pois ele servirá do cache até que o TTL expire - ENTÃO ele servirá da mesma forma que o que você +tracerevelou.

    Não pode ter muitos detalhes IMO.

    • 24

  4. Este bash escavará as entradas DNS de example.com do 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 de example.com.
    • A escavação externa consulta o primeiro servidor de nomes de 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 corrigido. dignão é minha especialidade - melhorias são bem-vindas :-)

    • 7

  5. Graças a essas soluções, posso verificar a propagação de registros DNS TXT que preciso adicionar à Zona DNS do AZURE, para certificados LetsEncrypt. Aqui está o meu comando dig:

    dig @8.8.8.8 +nocmd _acme-challenge.ultrasecretprojec.to txt +noall +answer
    • 2

relate perguntas