On Thu, Feb 02, 2006 at 11:57:08PM +0100, Julien Escario wrote: > Concernant DNS, Marc et moi avons eu l'occasion d'en parler dans le train > aujourd'hui et il ne semble pas d'accord avec moi. De toute façon, je sais > bien > qu'il ne m'aime pas, je suis trop talentueux, ca lui demande des efforts de > modestie ;-)
Je suis pour l'émulation, pas la compétition :) http://agora.qc.ca/mot.nsf/Dossiers/Emulation > Plus sérieusement, DNS est un système simple, certes mais qui me fait plutôt > l'effet d'une pieuvre géante en liberté. En fait il faut différencier le protocole, l'implémentation, et les aspects "non techniques" > 1) Le système est entièrement tenu par les U.S. c.f. les récents débats sur la > société de l'information à Tunis. non technique mais: http://en.wikipedia.org/wiki/DNS_root_zone nous indique que 3 DNS servers se trouvent en dehors des Etats-Unis (3 en Europe, 1 au Japon). Ce qui ne veut pas dire que l'organisation interne (accès aux données maîtres) n'est pas en mains US. Notons aussi que certains root DNS servers sont en `anycast' (soit en IPV6: un parmi N serveur; en IPv4: magouillage en utilisant les annonces de routes BGP). Malgré tout, ce que tu relèves est très important. C'est un fait qu'également la plupart des entreprises de transport de données sont plus ou moins en mains US (citons Cablecom). Je pense qu'il y a cependant plus grave: le nombre d'entreprises qui pensent que s'héberger dans un sous-domaine de com. est une bonne idée. La loi US s'applique alors! Sans aucune protection du droit des marques européens, et en fort US. > 2) Plus particulièrement par une soit-disante association appellée l'ICANN > qui C'est déjà mieux qu'avant où c'était un bureau à Berkeley, non ? :) > ...) et plus particulièrement Verisign, société on ne peux plus commerciale > qui Internet aujourd'hui *est* largement financé par les entreprises commerciales. > fait régulièrement n'importe quoi (dernier en date : site finder qui dirigeait > tous les noms de domaines non enregistrés sur leur site) oui, c'était très drôle. > 3) On a rajouté, par dessus, au fil du temps, tout un tas d'extensions plus ou > moins pratiques. top domains, pas des extensions :-> > 4) Beaucoup d'implémentations ne respectent pas le standard. Exemple typique : > le résolveur de Windows qui réécrit les temps de vie comme il a envie. aucun protocole n'est parfaitement implémenté, et il y a des bugs partout, un nouveau standard ne pourrait pas éviter cela (sauf à produire également une suite de test ou une implémentation de référence *obligatoire*). P.ex. un compilateur Ada ne peut s'appeler ainsi que s'il passe la suite de test officielle. > 5) Une erreur est indebugable. Par exemple : je monte mon serveur web qui > pointe > un domaine sur une IP. Rien n'empêche le fournisseur X de réécrire > partiellement > ou totalement mes défitions pour ses clients, je n'ai aucun pouvoir sur ce > qu'il > fait avec son résolveur. C'est le problème des réponses non "authoritative" > (une > idée de traduction ?). Il est donc possible que tout d'un coup, un client n'ai > plus accès à un site (service) à cause d'un "cache poisoning", qu'il va > répandre > en plus. Oui, d'ailleurs ce que je fais systématiquement quand j'ai des doutes est de vérifier ce que répondent plusieurs DNS de divers gros fournisseurs. Il faut aussi savoir que si on transfère un domaine d'une compagnie d'hébergement A à B, changer chez NIC/CH n'est pas suffisant: il faut forcer, peut-être au marteau, la compagnie A de déconfigurer la zone. Et vérifier que c'est fait par une requête directe. > 6) Non sécurisé. Encore qu'un bidouillage appellé DNSSEC semble possible. Je > n'ai jamais fait et je doute que beaucoup de monde le supporte. Sisi, ça commence. > 7) Une latence d'environ 12h pour la propagation des changements faits sur une > zone (et jusqu'à 48h des fois !) Non, je n'ai jamais expérimenté ce genre de délais. Mais avant des changements, en général 3-4 jours avant je baisse le refresh de la zone et des entrées particulières, style à 4h, voire beaucoup moins. > Et surtout, c'est fortement hiérarchisé, ce qui induit cette situation de > monopole décrite plus haut. Comment éviter la racine ? Par broadcasts? Ne pas oublier que beaucoup d'administrateurs ne mettent jamais à jour le fichier hint racine eux-mêmes, donc on dépend du fait que tous les serveurs root se connaissent et que le client BIND mette à jour cette liste dynamiquement ... _______________________________________________ gull mailing list [email protected] http://lists.alphanet.ch/mailman/listinfo/gull
