Forzar excavación para resolver sin usar caché

Me pregunto si hay una manera de consultar un servidor DNS y evitar el almacenamiento en caché (con dig). A menudo cambio una zona en el servidor DNS y quiero verificar si se resuelve correctamente desde mi estación de trabajo. Pero como el servidor almacena en caché las solicitudes resueltas, a menudo recibo las anteriores. Reiniciar o cargar el servidor no es realmente algo agradable.

Puede usar la @sintaxis para buscar el dominio desde un servidor en particular. Si el servidor DNS tiene autoridad para ese dominio, la respuesta no será un resultado en caché.

dig @ns1.example.com example.com

Puede encontrar los servidores autorizados solicitando los NSregistros de un dominio:

dig example.com NS

No hay ningún mecanismo en el protocolo DNS que obligue a un servidor de nombres a responder sin usar su caché. Excavar en sí mismo no es un servidor de nombres, es simplemente una herramienta que pasa su consulta a los servidores de nombres que haya configurado, utilizando solicitudes DNS estándar. DNS hace incluir una manera de decirle a un servidor a no utilizar la recursividad, pero esto no es lo que quiere. Eso solo es útil cuando desea consultar directamente un servidor de nombres autorizado.

Si desea evitar que un servidor de nombres responda desde su caché, solo podrá hacerlo alterando la configuración en el servidor de nombres , pero si no controla el servidor de nombres, esto es imposible.

Sin embargo, puede excavar para omitir los servidores de nombres configurados y realizar su propia solicitud recursiva que vuelve a los servidores raíz. Para hacer esto, use la +traceopción.

dig example.com +trace

En la práctica, ya que esto solo consultará a los servidores autorizados en lugar de a su resolutor de almacenamiento en caché local, el resultado no será obsoleto incluso si esos servidores emplean almacenamiento en caché interno. El beneficio adicional de usar +tracees que puede ver todas las solicitudes separadas realizadas a lo largo del camino.

Algo importante a tener en cuenta aquí, que noto que muchas personas nunca incluyen al hablar +tracees que usar +tracesignifica que el cliente de excavación hará el seguimiento, no el servidor DNS especificado en su configuración (/etc/resolv.conf). En otras palabras, su cliente de excavación funcionará como lo haría un servidor DNS recursivo, si lo solicita. Pero, lo que es más importante, no tienes un caché.

Más detalles: por lo tanto, si ya solicitó un mxregistro utilizando dig -t mx example.comy su /etc/resolv.conf es 8.8.8.8, hacer cualquier cosa dentro del TTL de la zona devolverá el resultado almacenado en caché. En cierto modo, si está buscando algo sobre su propia zona y cómo Google lo ve, ha envenenado sus resultados de DNS con Google para el TTL de su zona. No está mal si tienes un TTL corto, algo basura si tienes uno de 1 hora.

Por lo tanto, si bien +tracelo ayudará a ver qué se vería si le preguntara a Google por PRIMERA vez y no tuviera una entrada en caché, puede darle una falsa idea de que Google le dirá a todos lo mismo que su +traceresultado, que no lo haría si lo hubiera pedido anteriormente y tenga un TTL largo, ya que lo servirá desde la caché hasta que caduque el TTL; LUEGO servirá lo mismo que lo que +tracereveló.

No puedo tener demasiados detalles de la OMI.

Este bash cavará las entradas DNS de example.com desde su primer servidor de nombres:

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

• La excavación interna consulta el DNS de google (8.8.8.8) para obtener los servidores de nombres de example.com.
• La excavación externa consulta el servidor de nombre de example.com.

Esto es lo mismo que un alias para un .zshrc (y probablemente .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; }

Aquí está la salida 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

Esta solución es lo suficientemente complicada como para no ser práctica de recordar, pero lo suficientemente simple como para que el problema no se solucione. digno es mi especialidad - mejoras bienvenidas :-)