Dans le but de proposer un meilleur service IPv6, Yahoo a proposé ce qu’on peut appeler un hack DNS :
http://www.networkworld.com/news/2010/032610-yahoo-dns.html
Le contexte :
la volonté des services providers est de fournir un service sur IPv6 qui soit aussi bon (pour ne pas dire meilleur) que celui sur IPv4. Or dans bien des cas, un host va faire une requête quad-A afin de récupérer une adresse IPv6 correspondant à un nom de host, ceci même si la connectivité IPv6 n’est pas transcendante. Google s’est saisi du problème en instituant un système de whitelist, c’est à dire constituer une liste de resolvers DNS d’ISP fournissant une bonne connectivité IPv6. Dans ce cas, on entre dans une procédure ou finalement Google décide qui est “bon” ou qui ne l’est pas.
Le hack proposé par Yahoo :
Dans le cas de Yahoo, l’approche est sensiblement différente puisqu’ils proposent une approche “technique” cette fois. Si l’on voulait résumer cette approche, cela consisterait à dire qu’un autoritative DNS (la destination donc) n’accepterait une query “quad-A” d’un resolver DNS (l’origine) que si cette demande DNS est faite sur un transport IPv6. De la même facon, une requête “A” serait uniquement acceptée sur un transport IPv4. L’idée est donc de dire que si la demande “quad-A” est faite sur un transport IPv6, le service fourni par l’opérateur devrait être suffisamment correct pour que la demande soit acceptée.
L’approche de Yahoo est donc de proposer une modification à la source (resolver DNS de l’ISP) plutot qu’à la destination (autoritative servers), et donc de refuser une requète DNS provenant d’une source address IPv4.
On peut considérer cette approche comme biaisée dans la mesure ou cela revient à considérer que la demande DNS doit se faire sur le même protocole que celui qui sera utilisée vers la cible. Maintenant tout le monde essaie de trouver une solution, Yahoo a maintenant la sienne …
Dans le même temps Google propose de simplifier le système de whitelisting en laissant les ISP faire du opt-in de leur adresse de resolvers :
Pour plus d’information, on pourra se reporter ici :
http://www.ietf.org/proceedings/10mar/slides/dnsop-7.pdf
Authors
