DNS poisoned cache does not have any effect

I try to reproduce the attack, revealed by Dan Kaminsky in 2008, to poison DNS cache. I made my own virtual network, and all I do is confined within.

The poisonning seems to work. But is doesn't. Why?

The target domain is example.com. Here's my network:

 - 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.

Basically, when someone asks for www.example.com, or whatever, the Resolver asks DNS0, DNS1 and then DNS2. Finally, he stores the interesting records in his cache. It should looks more or less like this:

.                 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)

I made a program to perform the attack. It seems to work. Indeed, here's the cache of the 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)

But in fact, it doesn't work:

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

And here's what the Resolver's cache looks like now:

;
; 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)

I don't know what happened. I could see, using wireshark, that when I type dig www.example.com, the Resolver asks DNS2 and not the Attacker. But when I see his cache (the one after a 'successful' attack), he's not supposed to know DNS2.

Does any of you have an idea about what is going wrong?

Thanks, and have a nice day.