Solución 1:
Puedes usar el @ 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 almacenado en caché.
dig @ns1.example.com example.com
Puede encontrar los servidores autorizados solicitando el NS registros para un dominio:
dig example.com NS
Solución 2:
No existe ningún mecanismo en el protocolo DNS para obligar a un servidor de nombres a responder sin usar su caché. Dig en sí no es un servidor de nombres, es simplemente una herramienta que pasa su consulta a cualquier servidor de nombres que haya configurado, utilizando solicitudes de DNS estándar. DNS sí incluya una forma de decirle a un servidor que no use la recursividad, pero esto no es lo que desea. 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 modificando la configuración en el servidor de nombres , pero si no controlas el servidor de nombres, esto es imposible.
Sin embargo, puede hacer dig para bypass los servidores de nombres configurados y realiza su propia solicitud recursiva que vuelve a los servidores raíz. Para hacer esto, use el +trace opción.
dig example.com +trace
En la práctica, dado que esto solo consultará a los servidores autorizados en lugar de a su resolución de almacenamiento en caché local, el resultado no será obsoleto incluso si esos servidores emplean almacenamiento en caché interno. El beneficio adicional de usar +trace es que puedes ver todas las solicitudes separadas realizadas a lo largo de la ruta.
Solución 3:
Algo importante a tener en cuenta aquí, que noto que muchas personas nunca incluyen cuando hablan de +trace es que usando +trace significa que el cliente de excavación hará el seguimiento, no el servidor DNS especificado en su configuración (/etc/resolv.conf). Entonces, 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 caché.
Más detalles, por lo que si ya ha solicitado un mx grabar usando dig -t mx example.com y su /etc/resolv.conf es 8.8.8.8, entonces 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 la ve Google, en cierto modo 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.
Entonces, mientras +trace te ayudará a ver lo que se vería si le preguntaras a Google por PRIMERA vez y no tuviera una entrada en caché, puede darte una idea falsa de que Google les dirá a todos lo mismo que tu +trace El resultado fue, que no lo hará si lo hubieras preguntado previamente y tuvieras un TTL largo, ya que lo servirá desde la memoria caché hasta que caduque el TTL; ENTONCES, servirá lo mismo que tu +trace revelado.
En mi opinión, no puede tener demasiados detalles.
Solución 4:
Este bash buscará las entradas DNS de example.com desde su primer servidor de nombres listado:
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 nombres 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 que no sea práctica de recordar, pero lo suficientemente simple como para que el problema no se solucione. dig no es mi especialidad - se aceptan mejoras :-)