Bonjour, j'ai quelques questions en vrac sur l'infra Milkywan, par curiosité 
J'ai fait un peu mumuse avec les DNS de Milkywan, notamment pour tester le DNS64 + NAT64, et je dois avouer être bluffé par le fonctionnement silencieux et invisible de ce système.

1) Parmis les DNS Milkywan (130.117.11.11 et 2a0b:cbc0:42::42), l'IPv4 ne semble pas être sur la plage d'IP de Milkywan. Est ce fait exprès ? En IPv4 il n'est d'ailleurs joignable que depuis le réseau Milkywan, pas depuis l'exterieur. J'ai d’ailleurs remarqué que le DNS en IPv4 (130.117.11.11) avait un ping plus rapide et semblait régionalisé, contrairement à celui en IPv6.

2) Est ce qu'il y aurait un projet futur de mettre en place des DNS "sécurisés" (type DNS over TLS ou DNS over HTTPS) ? En effet le ping vers ce DNS est plu rapide que tous les autres DNS (sécurisé mais aussi ceux de mon FAI) que j'ai, et je serai très intéressé de les utiliser mais pas au prix de perdre le chiffrement.

3) En testant le NAT64, de ce que je comprends, lorsqu'on l'utilise et que l'on tente de joindre une ressource IPv4 only depuis un appareil en IPv6 only, la conversion est faite via le DNS64 puis on "sort" via le routeur en NAT64 (testé avec ipv4.lafibre.info et on obtient l'IPv4 du server NAT64).
De même, en désactivant les règles de NAT depuis mon tunnel vers Milkywan, je me suis rendu compte que l'infrastructure Milkywan savait faire du CGNAT si jamais j'essayais d'accéder à internet depuis mon IP privée de mon tunnel. C'est très bien parce que même si mon routeur est mal configuré ou que je n'ai pas d'IPv4 publique chez Milkywan et que je n'utilise pas les DNS de Milkywan (pour utiliser le DNS64+NAT64) j'ai tout de même accès à internet. Il ne me semble pas que ce CGNAT était présent il y a quelques années.
Mais entre le NAT64 et le CGNAT cela n'est il pas risqué pour Milkywan de "partager" la même IP pour les clients ? Je pense notamment en cas d'enquete judiciaire, comment retrouver l'utilisateur en question ? Il y a des logs de connexion comme chez les "gros" FAI faisant du CGNAT ?


(PS : si besoin de retirer les IP citées, pas de soucis)

1) Parmis les DNS Milkywan (130.117.11.11 et 2a0b:cbc0:42::42), l'IPv4 ne semble pas être sur la plage d'IP de Milkywan. Est ce fait exprès ? En IPv4 il n'est d'ailleurs joignable que depuis le réseau Milkywan, pas depuis l'exterieur. J'ai d’ailleurs remarqué que le DNS en IPv4 (130.117.11.11) avait un ping plus rapide et semblait régionalisé, contrairement à celui en IPv6.

130.117.11.11 est une ip Cogent qui était louée à Appliwave fut-il un temps, Appliwave nous mettait un /27 à disposition sur ce /24. On la garde parce qu'elle ne sert qu'en interne, c'est un peu moche mais c'est pas bien grave
Normalement l'IPv4 et l'IPv6 sont routées pareil, j'ai check vite fait et je tape bien en local en v6 aussi.

2) Est ce qu'il y aurait un projet futur de mettre en place des DNS "sécurisés" (type DNS over TLS ou DNS over HTTPS) ? En effet le ping vers ce DNS est plu rapide que tous les autres DNS (sécurisé mais aussi ceux de mon FAI) que j'ai, et je serai très intéressé de les utiliser mais pas au prix de perdre le chiffrement.

Pas prévu tout de suite, ça ne sert pas à grand chose de chiffrer à l'interieur de notre réseau (il faut bien se rappeler que les DNS sont principalement à destination des abonnés FTTH/xDSL). Ça serait un ajout intéressant mais on a déjà fort à faire sur les choses essentielles

3) En testant le NAT64, de ce que je comprends, lorsqu'on l'utilise et que l'on tente de joindre une ressource IPv4 only depuis un appareil en IPv6 only, la conversion est faite via le DNS64 puis on "sort" via le routeur en NAT64 (testé avec ipv4.lafibre.info et on obtient l'IPv4 du server NAT64).
De même, en désactivant les règles de NAT depuis mon tunnel vers Milkywan, je me suis rendu compte que l'infrastructure Milkywan savait faire du CGNAT si jamais j'essayais d'accéder à internet depuis mon IP privée de mon tunnel. C'est très bien parce que même si mon routeur est mal configuré ou que je n'ai pas d'IPv4 publique chez Milkywan et que je n'utilise pas les DNS de Milkywan (pour utiliser le DNS64+NAT64) j'ai tout de même accès à internet. Il ne me semble pas que ce CGNAT était présent il y a quelques années.
Mais entre le NAT64 et le CGNAT cela n'est il pas risqué pour Milkywan de "partager" la même IP pour les clients ? Je pense notamment en cas d'enquete judiciaire, comment retrouver l'utilisateur en question ? Il y a des logs de connexion comme chez les "gros" FAI faisant du CGNAT ?

On a du log sur le NAT64 et le CGNAT donc en cas de réquisition ça devrait le faire.
Le CGNAT a toujours été présent

On ne fait plus d'A+P sur le CGNAT pour deux raisons :
- Il est très peu utilisé (en fait il n'y a plus que les tunnels qui ont du NAT)
- Ça devenait ingérable au moindre churn

NAT64 le remplace, avec un stack de logging comme les gros FAI

1)  J'ai d’ailleurs remarqué que le DNS en IPv4 (130.117.11.11) avait un ping plus rapide et semblait régionalisé, contrairement à celui en IPv6.

pour info, le ping n'est qu'une partie de la rapidité d'un serveur DNS.  Il faut mesurer le temps de résolution plutôt que le temps d'un ping.

La commande 'dig' permet de faire cela par exemple, cf la ligne 'query time' (par exemple: dig lafibre.info @ip_du_serveur_dns)

On peut très bien avoir un serveur a 2 ou 3 ms de 'ping' de distance qui est en moyenne plus long a répondre qu'un serveur qui se situe a 10ms de ping.

Un serveur très utilisé comme 8.8.8.8 ou 1.1.1.1 par exemple même si il est plus "loin" en ping peut souvent répondre plus vite car il aura plus de réponses en cache par exemple ou une meilleur latence avec le reste de l'internet.

Il est 3 facteurs qui contribuent donc: le ping, le temps de traitement du serveur (= fonction du matériel, sa charge et de sa connectivité vers les autres serveurs DNS) et le pourcentage de réponses en cache qui est principalement lié a son nombre d'utilisateurs et a son dimensionnement.

Un serveur très utilisé comme 8.8.8.8 ou 1.1.1.1 par exemple même si il est plus "loin" en ping peut souvent répondre plus vite car il aura plus de réponses en cache par exemple ou une meilleur latence avec le reste de l'internet.

D'autant plus que 8.8.8.8 et 1.1.1.1 sont des adresses Anycast qui permettent de contacter le serveur "le plus proche" / "le plus efficace" parmi un ensemble de serveurs.
Idem pour les "root servers" DNS.