On Tue, Jul 04, 2023 at 10:03:19AM +0200, Laurent Barme <5...@barme.fr> wrote a message of 63 lines which said:
> > Autre rappel : il n'y a aucun rapport entre l'adresse de transport > > de la requête DNS (IPv4 ou IPv6) et le type de données demandé (A > > ou AAAA). > > L'adresse de transport de la requête DNS dépend quand même de ce que > peut faire le poste : s'il n'a pas d'IPv6, la requête se fera > seulement en IPv4 et l'adresse retournée sera une IPv4 > (heureusement). Non. Je répète : la famille de l'adresse retournée dépend de la famille demandée (A pour IPv4 et AAAA pour IPv6) et en aucun cas du protocole de transport. Vous voulez une démonstration ? % dig -4 @dns.google www.afnic.fr AAAA ... ;; ANSWER SECTION: www.afnic.fr. 600 IN AAAA 2a00:e00:0:5::2 ... ;; SERVER: 8.8.4.4#53(dns.google) (UDP) % dig -6 @dns.google www.afnic.fr A ... ;; ANSWER SECTION: www.afnic.fr. 600 IN A 91.188.78.66 ... ;; SERVER: 2001:4860:4860::8844#53(dns.google) (UDP) En outre, ce n'est pas (en général) le poste client final qui fait la requête aux serveurs faisant autorité mais le résolveur, qui peut avoir de l'IPv6 si le poste client n'en a pas, et réciproquement. > En fait, c'est moins l'adresse de transport de la requête qui > m'intéresse que son résultat. Celui-ci dépend bien sûr du DNS > sollicité mais aussi de l'adresse de transport de la requête. Non, c'est faux. (À part des services de déboguage comme ip.dyn.bortzmeyer.fr.) > Il y a bien une résolution IPv4 ou IPv6 qui dépende des OS et ISP, > ce qui explique des comportements différents selon le contexte > (OS/ISP) lorsqu'un nom de domaine contacté a simultanément une > adresse IPv4 et une adresse IPv6. Cela dépend entièrement du type de données demandé. > Alors, on est d'accord, ce qui ne va pas c'est le site pourvu d'une A et > d'une AAAA mais qui n'écoute que sur l'A. Oui, c'est une erreur. La plupart du temps, l'algorithme des globes oculaires heureux est là pour contourner ce problème mais c'est quand même une erreur de l'administrateur. Rien à voir avec IPv6, c'est le même type d'erreur que de faire pointer un enregistrement MX vers une machine qui n'écoute pas sur le port 25. > (d'autant plus que le serveur en question n'a pas IPv6, ce qui lui épargne > potentiellement 2^64 sources d'attaques à filtrer). Euh, quand vous voulez filtrer un /64, vous mettez 2^64 adresses dans votre configuration ? --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
