.

• [^]Re: .

  Posté par baud123 (Jabber id, page perso, ) le 04/01/2008 à 22:07. (lien). É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 briaeros007 () le 05/01/2008 à 11:20. (lien). É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 ;)

    --
    Subete ga wakatta toki…watashi ga anta wo korosu.

    • [^]EDNS0, pas TCP

      Posté par Stephane Bortzmeyer (page perso, ) le 05/01/2008 à 22:57. (lien). Évalué à 2.

      L'alternative elle existait déjà dans le standard dns depuis fort longtemps ;)

      
      
      L'alternative avec TCP, oui, depuis le début, mais elle est coûteuse pour le serveur.
      
      Ce qui est plus nouveau, c'est EDNS0 (http://www.bortzmeyer.org/2671.html), qui permet de faire sauter la limite des 512 octets, et qui n'a été massivement déployé que depuis quelques années.

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

    Posté par Stephane Bortzmeyer (page perso, ) le 05/01/2008 à 23:06. (lien). É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