Soluzione 1:
Puoi usare il @ sintassi per cercare il dominio da un particolare server. Se il server DNS è autorevole per quel dominio, la risposta non sarà un risultato memorizzato nella cache.
dig @ns1.example.com example.com
Puoi trovare i server autorevoli chiedendo il NS record per un dominio:
dig example.com NS
Soluzione 2:
Non esiste alcun meccanismo nel protocollo DNS per forzare un server dei nomi a rispondere senza utilizzare la sua cache. Dig in sé non è un server dei nomi, è semplicemente uno strumento che passa la tua query a qualsiasi server dei nomi che hai configurato, utilizzando richieste DNS standard. DNS fa includi un modo per dire a un server di non usare la ricorsione, ma questo non è quello che vuoi. Questo è utile solo quando vuoi interrogare direttamente un nameserver autorevole.
Se volessi impedire a un server dei nomi di rispondere dalla sua cache, potresti farlo solo modificando la configurazione sul server dei nomi , ma se non controlli il nameserver, questo è impossibile.
Puoi, tuttavia, usare dig per bypassare i nameserver configurati ed eseguire la propria richiesta ricorsiva che risale ai root server. Per fare questo, usa il +trace opzione.
dig example.com +trace
In pratica, poiché questo interrogherà solo i server autorevoli piuttosto che il tuo risolutore di cache locale, il risultato non sarà obsoleto anche se quei server utilizzano la cache interna. Il vantaggio aggiuntivo dell'utilizzo di +trace è che puoi vedere tutte le richieste separate fatte lungo il percorso.
Soluzione 3:
Qualcosa di importante da notare qui, che noto che molte persone non includono mai quando parlano di +trace è quello che usa +trace significa che il client dig eseguirà la traccia, non il server DNS specificato nella tua configurazione (/etc/resolv.conf). Quindi, in altre parole, il tuo client dig funzionerà come farebbe un server DNS ricorsivo, se lo chiedi. Ma, cosa importante, non hai una cache.
Maggiori dettagli - quindi se hai già chiesto un mx registra utilizzando dig -t mx example.com e il tuo /etc/resolv.conf è 8.8.8.8 quindi fare qualsiasi cosa all'interno del TTL della zona restituirà il risultato memorizzato nella cache. In un certo senso, se stai cercando qualcosa sulla tua zona e su come Google la vede, hai in qualche modo avvelenato i tuoi risultati DNS con Google per il TTL della tua zona. Non male se hai un TTL breve, un po' spazzatura se ne hai uno di 1 ora.
Quindi, mentre +trace ti aiuterà a vedere cosa VEDREBBE essere visto se lo chiedessi a Google per la PRIMA volta e non avesse voci memorizzate nella cache, potrebbe darti la falsa idea che Google dirà a tutti la stessa cosa di ciò che il tuo +trace risultato è stato, cosa che non accadrà se l'hai chiesto in precedenza e hai un TTL lungo, poiché lo servirà dalla cache fino alla scadenza del TTL - ALLORA servirà come il tuo +trace rivelato.
Non posso avere troppi dettagli IMO.
Soluzione 4:
Questa bash scaverà le voci DNS di example.com dal suo primo server dei nomi elencato:
dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
- L'inner dig interroga il DNS di Google (8.8.8.8) per ottenere i server dei nomi di example.com.
- Il dig esterno interroga il primo server dei nomi di example.com.
Ecco lo stesso di un alias per un .zshrc (e probabilmente .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; }
Ecco l'output per /.:
☀ 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
Questa soluzione è abbastanza complicata da essere poco pratica da ricordare, ma abbastanza semplice da non risolvere il problema. dig non è la mia specialità - miglioramenti ben accetti :-)