[gull] Le DNS, mon meilleur ennemi [was : Suite et fin]

[Marc SCHAEFER]

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 ...