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.
Respuestas:
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
+norecursese recomienda. +recurseestá activado de forma predeterminada ocasionalmente cambiará la forma en que un servidor DNS interpreta su pregunta por completo.
+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.
dig @8.8.8.8 example.com. Los registros aparecen mucho más rápido allí.
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.
+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.
+norecurserecomendación, ya que confundió el problema.
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.
dig mydomain.com +tracesolo me devuelve los resolvdresultados del trozo de 127.0.0.53. Ver github.com/systemd/systemd/issues/5897
+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).
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
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 :-)