El caché envenenado de DNS no tiene ningún efecto [cerrado]

Intento reproducir el ataque, revelado por Dan Kaminsky en 2008, para envenenar el caché de DNS. Hice mi propia red virtual, y todo lo que hago está confinado dentro.

El envenenamiento parece funcionar. Pero es no . ¿Por qué ?

El dominio de destino es example.com . Aquí está mi red:

 - Resolver:  200.200.200.1
   Resolves the DNS queries.

 - DNS   #0:  200.200.200.2
   Root DNS Server.

 - DNS   #1:  200.200.200.3
   Authoritative for '.com' zone.

 - DNS   #2:  200.200.200.4
   Authoritative for 'example.com' zone.
   It also runs a web server: www.example.com.

 - Attacker:  200.200.200.5
   The attacker. Tries to perform the attack.
   The attacher is configured to be authoritative for 'example.com' (as DNS2).
   But as he is not referenced by the DNS servers, he won't be asked anything.
   The purpose of the attack is to be stored in the cache of the Resolver.
   Therefore, as long as it's in the cache, any query to <rdm>.example.com will
   be forwarded to him.
   The attacker runs a web server too, and wants to 'steal' www.example.com.

Básicamente, cuando alguien pide www.example.com , o lo que sea, el Resolver pregunta DNS0 , DNS1 y luego DNS2 . Finalmente, almacena los registros interesantes en su caché. Debería verse más o menos así:

.                 300   IN   NS   ns.
ns.               300   IN   A    200.200.200.2 (DNS 0)

com.              300   IN   NS   ns.com.
ns.com.           300   IN   A    200.200.200.3 (DNS 1)

example.com.      200   IN   NS   ns.example.com.
ns.example.com.   200   IN   A    200.200.200.4 (DNS 2)

www.example.com.  100   IN   A    200.200.200.4 (DNS 2 runs a web serv)

Hice un programa para realizar el ataque. Parece funcionar. De hecho, aquí está el caché del Resolver :

;
; Start view _default
;
;
; Cache dump of view '_default' (cache _default)
;
$ DATE 20141229094639 (09:46:39, 29th of December 2014)
; authanswer
.                    295    IN NS   ns.
; glue
com.                 295    NS      ns.com.
; glue
example.com.         196    NS      ns.example.com.
; glue
ns.example.com.      56     A       200.200.200.5 (Attacker)
; glue
ns.com.              295    A       200.200.200.3 (DNS 1)
; additional
ns.                  295    A       200.200.200.2 (DNS 0)

Pero, de hecho, no funciona:

 $ dig www.example.com +short
   200.200.200.4 (DNS 2 web serv!)

Y aquí está el aspecto del caché de Resolver ahora:

;
; Start view _default
;
;
; Cache dump of view '_default' (cache _default)
;
$ DATE 20141229094652 (09:46:52, 29th of December 2014)
; authanswer
.                    282    IN NS   ns.
; glue
com.                 282    NS      ns.com.
; authauthority
example.com.         97     NS      ns.example.com.
; answer
ns.example.com.      97     \-AAAA  ;-$NXRRSET
; example.com SOA ns.example.com. admin.example.com. 2014111400 86400 900 1209600 3600
; glue
                     193    A       200.200.200.4 (DNS 2)
; authanswer
www.example.com.     97     A       200.200.200.4 (DNS 2)
; glue
ns.com.              282    A       200.200.200.3 (DNS 1)
; additional
ns.                  282    A       200.200.200.2 (DNS 0)

No sé lo que pasó. Pude ver, utilizando wireshark, que cuando escribo dig www.example.com , el Resolver pregunta DNS2 y no el Attacker . Pero cuando veo su caché (el que está después de un ataque 'exitoso'), se supone que no debe saber DNS2 .

¿Alguno de ustedes tiene una idea acerca de lo que está mal?

Gracias, y que tengas un buen día.