Mi chiedo se esiste un modo per interrogare un server DNS e bypassare la memorizzazione nella cache (con dig). Spesso cambio una zona sul server DNS e voglio verificare se si risolve correttamente dalla mia workstation. Ma poiché il server memorizza nella cache le richieste risolte, spesso ottengo quelle vecchie. Il riavvio o il caricamento del server non è davvero bello.
Risposte:
È possibile utilizzare la @sintassi per cercare il dominio da un determinato 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 i NSrecord per un dominio:
dig example.com NS
+norecurseè consigliabile. +recurseè attivo per impostazione predefinita cambierà occasionalmente il modo in cui un server DNS interpreta completamente la tua domanda.
+tracema fai attenzione alla memorizzazione nella cache. Andrew B ha scritto una buona spiegazione di come la memorizzazione nella cache può ingannarti quando aspetti che i nameserver cambino.
dig @8.8.8.8 example.com. i record appaiono molto più velocemente lì.
Non esiste alcun meccanismo nel protocollo DNS per forzare un nameserver a rispondere senza usare la sua cache. Dig stesso non è un nameserver, è semplicemente uno strumento che trasmette la tua query a qualunque nameserver che hai configurato, usando richieste DNS standard. DNS non includere un modo per dire a un server di non usare la ricorsione, ma questo non è ciò che si desidera. È utile solo quando si desidera interrogare direttamente un nameserver autorevole.
Se vuoi impedire a un nameserver di rispondere dalla sua cache, potresti farlo solo modificando la configurazione sul nameserver , ma se non controlli il nameserver, questo è impossibile.
Tuttavia, è possibile ottenere scavare per bypassare i nameserver configurati ed eseguire la propria richiesta ricorsiva che risale ai server root. Per fare questo, usa l' +traceopzione.
dig example.com +trace
In pratica poiché ciò interrogherà solo i server autorevoli anziché il risolutore di cache locale, il risultato non sarà obsoleto anche se quei server utilizzano la cache interna. Il vantaggio aggiuntivo dell'utilizzo +traceè che puoi vedere tutte le richieste separate fatte lungo il percorso.
+norecurseindica semplicemente al nameserver di restituire qualsiasi informazione disponga (incluse eventuali informazioni memorizzate nella cache), quindi non è corretto. +tracefunzionerà perché seguirà la catena di ricorsione fino a un server autorevole.
+norecurseraccomandazione poiché confondeva il problema.
Qualcosa di importante da notare qui, che noto che molte persone non includono mai quando parlano +traceè che usando +tracesignifica che il client dig farà la traccia, non il server DNS specificato nella tua configurazione (/etc/resolv.conf). Quindi, in altre parole, il tuo client di scavo funzionerà come farebbe un server DNS ricorsivo, se lo chiedi. Ma - soprattutto, non hai una cache.
Maggiori dettagli - quindi se hai già richiesto un mxrecord usando dig -t mx example.come il tuo /etc/resolv.conf è 8.8.8.8 allora fare qualcosa 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 la vede Google, hai in qualche modo avvelenato i tuoi risultati DNS con Google per il TTL della tua zona. Non male se hai un TTL corto, un po 'spazzatura se ne hai uno di 1 ora.
Quindi, mentre +traceti aiuterà a vedere cosa DOVREBBE essere visto se lo chiedessi a Google per la PRIMA volta e non avesse una voce memorizzata nella cache, potrebbe darti una falsa idea che Google dirà a tutti lo stesso del tuo +tracerisultato, che non lo sarebbe se lo avessi chiesto in precedenza e avessi un TTL lungo, poiché lo servirà dalla cache fino alla scadenza del TTL - POI servirà lo stesso di quello che hai +tracerivelato.
Impossibile avere troppi dettagli IMO.
dig mydomain.com +tracemi restituisce solo i resolvdrisultati dello stub 127.0.0.53. Vedi github.com/systemd/systemd/issues/5897
+tracedig inizia la traccia utilizzando il nameserver specificato (ad es. 8.8.8.8 se è quello che è stato configurato) per la prima ricerca (la zona radice), ma successivamente utilizza i nameserver restituiti per ulteriori query. Pertanto, se il server dei nomi configurato non funziona o non risponde correttamente a una query per i server dei nomi radice, è possibile che si verifichino problemi (come nel commento sopra).
Questo bash scava 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
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 poter risolvere il problema. dignon è la mia specialità - miglioramenti benvenuti :-)