¿Por qué ‘dig +trace’ resuelve y ‘dig’ a secas no?

Analizando un problema de resolución DNS esta tarde he detectado algo que me ha parecido curioso. El dominio en cuestión no resolvía utilizando un determinado servidor DNS. Voy a enseñaros el ejemplo con un servidor DNS ficticio «10.0.0.115» y un nombre de dominio «test.com»:

$ dig @10.0.0.115 test.com

; <<>> DiG 9.7.3 <<>> @10.0.0.115 test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57041
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

 ;; QUESTION SECTION:
 ;test.com.            IN    A

 ;; Query time: 214 msec
 ;; SERVER: 10.0.0.115#53(10.0.0.115)
 ;; WHEN: Wed Nov 30 18:00:33 2011
 ;; MSG SIZE  rcvd: 32

Vemos efectivamente que recibimos un SERVFAIL y no hay respuesta del registro A del dominio. El paso siguiente es hacer debug y sacar la traza con +trace para ver todos los saltos y encontrar donde está el problema:

$ dig +trace  @10.0.0.115 test.com

; <<>> DiG 9.7.3 <<>> +trace @10.0.0.115 test.com
; (1 server found)
;; global options: +cmd
.            72650    IN    NS    e.root-servers.net.
.            72650    IN    NS    f.root-servers.net.
.            72650    IN    NS    g.root-servers.net.
.            72650    IN    NS    h.root-servers.net.
.            72650    IN    NS    i.root-servers.net.
.            72650    IN    NS    j.root-servers.net.
.            72650    IN    NS    k.root-servers.net.
.            72650    IN    NS    l.root-servers.net.
.            72650    IN    NS    m.root-servers.net.
.            72650    IN    NS    a.root-servers.net.
.            72650    IN    NS    b.root-servers.net.
.            72650    IN    NS    c.root-servers.net.
.            72650    IN    NS    d.root-servers.net.
;; Received 364 bytes from 10.0.0.115#53(10.0.0.115) in 213 ms

com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    a.gtld-servers.net.
;; Received 492 bytes from 192.228.79.201#53(b.root-servers.net) in 223 ms

test.com.        172800    IN    NS    ns1.servidordns.com.
test.com.        172800    IN    NS    ns2.servidordns.com.
;; Received 117 bytes from 192.48.79.30#53(j.gtld-servers.net) in 341 ms

test.com. 14400 IN A 93.93.108.200
test.com.        86400    IN    NS    ns2.servidordns.com.
test.com.        86400    IN    NS    ns1.servidordns.com.
;; Received 101 bytes from 93.93.108.58#53(ns2.servidordns.com) in 212 ms

Curiosamente, al ejecutar el dig +trace sí que ha llegado al servidor DNS autoritativo y recibido respuesta del registro A. ¿Por qué? Esto es debido a que dig +trace no utiliza la caché del servidor DNS que estamos utilizando. En caso de que esta caché sea incorrecta nos encontraríamos con esta situación.

La solución pasa por reiniciar el servidor DNS que tiene la entrada incorrecta o esperar a que expire el TTL y automáticmaente se actualicen los registros de la zona DNS.