Forzar excavación para resolver sin usar caché

91

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.

Daniel
fuente

Respuestas:

121

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
Ladadadada
fuente
2
Ah, esta bien. Sí, estaba familiarizado con la sintaxis @, pero no tuve la idea de consultar el servidor autorizado. ¡Gracias!
Daniel
3
Nota al margen: en los casos en que intente ver qué respuestas obtendría un servidor de almacenamiento en caché, +norecursese recomienda. +recurseestá activado de forma predeterminada ocasionalmente cambiará la forma en que un servidor DNS interpreta su pregunta por completo.
Andrew B
44
¿Qué sucede si está esperando que cambien los servidores autorizados?
fifi finance
@KasperSouren ¿Estás hablando de los registros NS en los servidores autorizados o los registros de pegamento en el padre? Puede encontrar al padre +tracepero tenga cuidado con el almacenamiento en caché. Andrew B escribió una buena explicación de cómo el almacenamiento en caché puede engañarte cuando esperas a que cambien los servidores de nombres.
Ladadadada
3
también puedes consultar en google dns dig @8.8.8.8 example.com. Los registros aparecen mucho más rápido allí.
máquinaaddict
26

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.

thomasrutter
fuente
10
Usar +norecursesolo le dice al servidor de nombres que devuelva la información que tenga (incluida la información almacenada en caché, si la hay), por lo que eso no es correcto. +tracefuncionará porque seguirá la cadena de recursión hasta un servidor autorizado.
Raman
1
Tenga en cuenta que he modificado esta respuesta para eliminar la +norecurserecomendación, ya que confundió el problema.
thomasrutter
13

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.

c0ntr1but3
fuente
¿Dig tiene su propio caché o usa el caché del sistema operativo?
CMCDragonkai
Cavar no tiene caché. Sin embargo, si el servidor de nombres ascendente que está utilizando lo hace, se beneficia de eso.
thomasrutter
dig mydomain.com +tracesolo me devuelve los resolvdresultados del trozo de 127.0.0.53. Ver github.com/systemd/systemd/issues/5897
James Bowery
Al usar +tracedig comienza la traza usando el servidor de nombres especificado (por ejemplo, 8.8.8.8 si eso es lo que ha configurado) para la primera búsqueda (la zona raíz), pero luego usa los servidores de nombres devueltos para consultas adicionales. Entonces, si su servidor de nombres configurado no funciona o no responde correctamente a una consulta para los servidores de nombres raíz, puede tener problemas (como en el comentario anterior).
thomasrutter
2

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 :-)

Michael Cole
fuente