Je suis pas certain que ce soit le plus réaliste, tu n'y auras pas accès.
Si tu pars du postulat que en part de marché, tu as la majorité sur les 4 gros, tu n'auras pas accès à leurs cache, c'est presque certain.
C'est comme si tu demandais à Google des stats sur 8.8.8.8, je suis loin d'être certains qu'il les donnent, ils en ont un usage interne, ce sont des données précieuses monnayables, de là à les donner, je me fais pas beaucoup d'illusions.

Pas sur. C'est l'ARCEP qui ferait la demande pas un individu random et meme Google partagerait ce genre de chose en retirant ce qu'ils exploitent (le profilage d'un utilisateur).

Le problème, et pour l'avoir vécu, ce genre de demande trouve souvent un frein non pas pour les raisons que tu invoques mais tout simplement pour des raisons de mise en oeuvre pratique (technique, accès, traitement de filtrage/anonymisation, qui s'occupe de cela en interne, etc).

oui sur la partie qui parle "DNS" on est d'accord.
Je pensais plus aux données qu'ils collectent chaque jour a des fins de stats/optimisation donc des données découplées de la production/criticité de fonctionnement du service, un peu comme les logs d'un serveur web.

Apres rien ne dit que les opérateurs collectent quoique ce a ce niveau. Ils en ont peut-être pas l'usage ou le besoin.

Pour revenir a ip6.nl , il  y a "IPv6-only DNS" dans leur critère pour donner une étoile mais comment ils mesurent cela ? en forçant le résolveur récursif qui résout a n'utiliser qu'IPv6 ?
Donc par exemple, cela implique que pour a.b.c, si b ne marche qu'en IPv4 la résolution échourait même si a.b.c a des serveurs de noms en IPv6 ?
est-ce comme cela qu'il faut le comprendre et le mettre en oeuvre ?

Les résolveurs DNS chez les opérateurs, c'est le truc ultra protégé, redondé, sécurisé, régionalisé...

La moindre évolution fait l'objet de grosses validation et d'un déploiement progressif sur l'ensemble du parc.

Quand le DNS tombe en panne, tout est cassé.

C'était pas arrivé une fois il y a quelques temps chez l'un des OCEN ?

C'est pas clair pour moi et ce n'est pas forcément un point intéressant à reprendre.

Exemple de cas où cela échoue : https://ip6.nl/#!cetu.gouv.fr

Lorsqu'un domaine possède des serveurs de noms IPv6, mais que le test IPv6 uniquement échoue, c'est généralement soit parce que les serveurs de noms IPv6 ne sont pas réellement accessibles, soit parce que les enregistrements glue sont manquants. En d'autres termes, les adresses IPv6 des serveurs de noms ne sont pas encore enregistrées auprès du registre de domaine. Contactez votre registraire de nom de domaine pour obtenir des instructions.

C'est une question de glue records à renseigner sur le domaine parent. Là en l'occurence "cetu" doit pas avoir de ns pointant à partir de gouv.fr ( à première vue, j'ai pas regardé, ni interrogé les ns).

Sur une machine IPv6 only

root@debian-revns:/home/philippe# host -v -t NS cetu.gouv.fr
Trying "cetu.gouv.fr"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22457
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cetu.gouv.fr. IN NS

;; ANSWER SECTION:
cetu.gouv.fr. 3600 IN NS ns6.oleane.net.
cetu.gouv.fr. 3600 IN NS ns7.oleane.net.

Received 76 bytes from 2001:4860:4860::8888#53 in 68 ms
root@debian-revns:/home/philippe# host -v -t NS gouv.fr
Trying "gouv.fr"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16646
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;gouv.fr. IN NS

;; AUTHORITY SECTION:
fr. 1800 IN SOA nsmaster.nic.fr. hostmaster.nic.fr. 2231405823 3600 1800 3600000 5400

Received 85 bytes from 2001:4860:4860::8888#53 in 28 ms
root@debian-revns:/home/philippe# host -v -t NS gouv.fr
Trying "gouv.fr"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15299
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;gouv.fr. IN NS

;; AUTHORITY SECTION:
fr. 1772 IN SOA nsmaster.nic.fr. hostmaster.nic.fr. 2231405823 3600 1800 3600000 5400

Received 85 bytes from 2001:4860:4860::8888#53 in 56 ms
root@debian-revns:/home/philippe#
Je suppose que c'est le problème que référence de "glue records" ip6.nl ( mais là il faut engueuler l'AFNIC  )

[edit]
Je plaisante, on sait jamais, il y en a qui prennent parfois au premier degrés. Si l'AFNIC a construit cela ainsi, c'est qu'il y a une raison.
De là à ce que Stéphane Bortzmeyer me tombe sur le coin de la figure. 
[/edit]

Je suppose que c'est le problème que référence de "glue records" ip6.nl ( mais là il faut engueuler l'AFNIC  )

ben non les glue records sont corrects justement... y'a pas de circularité vu que cetu.gouv.fr a ses NS sur oleane.net et pas cetu.gouv.fr.

et gouv.fr est un ccSLD donc fait partie intégrante .fr, il n'y pas d'étape '.gouv.fr' a tester.

a priori c'est oleane.net le coupable:

#obtenir les serveurs de .net en IPv6 via google par exemple:
host -v -6 -t NS net dns.google
ca donne la liste des serveurs ayant autorité pour .net
on en choisi un au hasard, par exemple: a.gtld-servers.net. puis on l'interroge pour oleane.net (toujours en IPv6):
host -v -6 -t NS oleane.net a.gtld-servers.net
ca donne bien des glue records, mais pas les valeurs IPv6.

bien que
host -v -t NS cetu.gouv.fr ns6.oleane.netdonne des IPv6 pour ns6 et ns7

il n'y pas de glue records IPv6 pour ns0 et ns1 dans la zone .net. ce qui expliquerai le souci ?

et ce bien que
host -v -6 -t NS oleane.net ns0.oleane.neta des glue records IPv6...mais la ce n'est pas la réponse d'un des serveurs de .net

c'est plutôt Orange qu'il faut engueuler la ? ...