IPv6 à la racine des DNS

Posté par  . Modéré par Nÿco.
Étiquettes :
0
4
jan.
2008
Internet
A partir du 4 février, l'IANA va ajouter les adresses IPv6 à 4 des 13 serveurs racines DNS. Il sera dès lors possible à des machines 100% IPv6 de faire des résolutions de noms, la plupart des TLD (.be,.com, etc.) ayant déjà des serveurs « IPv6 ready ».

Actuellement, seules les adresses IPv4 sont présentes dans la zone racine et ce à cause d'une limitation historique de la taille des requêtes DNS (en UDP). Il est probable que pour l'utilisateur moyen ça ne change encore pas grand chose, mais c'est encore une bonne nouvelle pour le déploiement de l'IPv6.

Aller plus loin

  • # déploiement représentatif

    Posté par  (site web personnel) . Évalué à 2.

    C'est une bonne nouvelle suite à l'annonce sur https://linuxfr.org//2007/10/28/23267.html du RIPE [http://en.wikipedia.org/wiki/RIPE] pour lancer le déploiement de IPv6 et l'annonce de certains fournisseurs d'accès [https://linuxfr.org/~plic/25817.html] de la fourniture d'IPv6 pour leurs abonnés internautes.

    Cela permet de tester de bout en bout (accès IPv6, requêtes DNS pour trouver l'IPv6 des serveurs, accès aux serveurs en IPv6) que tout fonctionne en IPv6.

    Reste à trouver de plus en plus de serveurs en IPv6 et aussi s'assurer que ça fonctionne déjà bien chez soi, comme commencé dans ce journal : https://linuxfr.org//~carlo/25836.html
    Certaines distributions ont commencé à recenser les applications impactées http://wiki.mandriva.com/en/Docs/SysAdmin/Networking/IPV6 [en] n'hésitez pas à participer à ce travail d'intégration dans votre distribution pour que cela fonctionne hors de la boîte pour le plus grand monde ;-)

    Déjà pour l'accès Free IPv6, j'avais commencé la prise de notes sur http://wiki.eagle-usb.org/wakka.php?wiki=FreeIPv6to4rd vous pouvez completer, cela étant un wiki.

  • # l'annonce de l'icann

    Posté par  . Évalué à 1.

    http://www.icann.org/minutes/prelim-report-18dec07.htm
    voir : Discussion of Supporting IPv6 in the Root Server System

  • # Faire un serveur compatible ipv6 ?

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Et si on installe un serveur web/mail, comment peut-on le rendre compatible IPv6 de la manière la plus transparente possible ?

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Faire un serveur compatible ipv6 ?

      Posté par  . Évalué à 1.

      La plupart des implémentations de serveurs web et mail aujourd'hui le gèrent déjà. C'est généralement le coup d'une ligne en plus dans la configuration. Si le support de l'IPv6 est opérationnel côté kernel, le plus dur est fait.

      Par exemple pour lighttpd, il suffit d'ajouter:
      server.use-ipv6 = "enable"

      Pour postfix, c'est plutôt :
      inet_protocols = ipv4, ipv6

      Pour cyrus, me semble pas avoir fait quelque chose de spécial, je crois que c'est une option à la compilation.

      Grosso modo, un petit tour dans le manuel de chaque service, et c'est réglé !

  • # .

    Posté par  . Évalué à 2.

    Actuellement, seules les adresses IPv4 sont présentes dans la zone racine et ce à cause d'une limitation historique de la taille des requêtes DNS (en UDP).
    Et ils ont resolu le pb comment ?

    • [^] # Re: .

      Posté par  (site web personnel) . Évalué à 3.

      bin je cite l'article de arstechnica
      The trouble is that the original Domain Name System specification only allows for 512-byte packets in the DNS protocol. With 13 root servers, we're already well over 400 bytes. Any useful number of IPv6 addresses for root servers would push this beyond the 512-byte limit. So for a long time, the parties involved have considered the possibilities of ill effects when IPv6 addresses for the root DNS servers are added to "the dot." (A dot signifies the end of a DNS name. A dot without a name is therefore the root of the DNS hierarchy.)

      The message from IANA links to a lengthy report, written by ICANN's Security and Stability Advisory and Root Server System Advisory Committees, detailing all the possible issues that could come up. The majority of modern DNS software is capable of sending and receiving packets larger than 512 bytes, so anyone running these should be fine. If a DNS server doesn't indicate this capability in its request, the root server will fit as much as it can within a 512-byte packet and mark the answer as "truncated," which is the requester's cue to retry the request over TCP rather than the usual UDP. So older DNS software shouldn't have any problems, either, so long as firewalls don't block DNS packets larger than 512 bytes or DNS requests over TCP.

      z'ont implémenté des logiciels nouveaux gérant au-delà de la spécification d'origine du protocole, seuls de vieux DNS avec de vieux logiciels risquent de ne pas passer à IPv6 (une bonne manière de les réformer lors de la migration), ils seront identifiés dans cette phase préliminaire, même si une alternative a été proposée pour que ça marchotte quand même.

      • [^] # Re: .

        Posté par  . Évalué à 2.

        même si une alternative a été proposée pour que ça marchotte quand même.
        Enfin le 512 octets c'est parce que la norme udp dis qu'il faut pouvoir envoyer un datagramme d'au moins 512 octets.
        Et le coup du truncated+tcp, c'est le fonctionnement normal du dns quand on doit envoyer des requêtes plus grosses (transfert de zone par exemple).
        L'alternative elle existait déjà dans le standard dns depuis fort longtemps ;)

      • [^] # arstechnica ne s'est pas bien exprimé

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        the root server will fit as much as it can within a 512-byte packet and mark the answer as "truncated,"


        Ce n'est pas vraiment exact (sauf à utiliser le mot troncation dans un sens très général, alors qu'il a une signification bien précise pour le DNS).

        Comme la taille de la section Réponse ou Autorité ne va pas changer (il n'y a toujours que treize serveurs), il n'y aura pas de troncation. Il y aura simplement sélection des enregistrements dans la section Addition, et cette section n'est pas obligatoire.

        Donc, le risque n'était pas la troncation, mais le fait que la sélection des colles (les adresses IP des serveurs) pourrait ne laisser que des adresses IPv4 ou bien que des adresses IPv4, ce qui serait ennuyeux pour le client mono-protocole.

        Avec EDNS0, le problème disparait.

        Le rapport complet du SSAC pour ceux qui ont le courage : http://www.icann.org/committees/security/sac018.pdf

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.