Mon blog

Couturé de cicatrices, ce RFC qui a été amendé par pas moins de vingt-six autres RFC tient toujours. "1035" est toujours la norme du DNS, un protocole sur lequel repose la quasi-totalité des applications de l'Internet. Le DNS est un des plus grands succès de l'Internet (qui se souvient aujourd'hui du ridicule X.500 ?) et notre RFC est donc une lecture indispensable.

Qui osera reprendre ces vingt-huit (avec le RFC 1034 et le 1035) documents et les consolider en un jeu de normes cohérent et à jour ? Sans doute personne, vue l'ampleur de la tâche. En attendant cette très hypothétique synthèse, prévenons tout de suite les lecteurs : lire le 1035 seul peut entrainer des problèmes.

Si son compagnon, le RFC 1034 pose les principes de base du DNS, la structure arborescente des données et le principe client-serveur du protocole, notre RFC descend, lui, dans les détails très concrets et spécifie, dans sa section 3, le format des données (resource records, les enregistrements du DNS) et dans sa section 4 celui des messages échangés entre clients et serveurs. Ces messages sont composés de plusieurs parties (la partie "Question", la partie "Réponse", la partie "Autorité", qui indique les serveurs faisant autorité pour la zone) et le résultat de la commande dig montre ces différentes sections.

Revenant sur le RFC 1034 (la séparation entre les deux RFC n'est pas toujours très logique et on est quasiment toujours obligé de lire les deux), notre RFC revient ensuite sur le format des fichiers de zone et sur l'algorithme utilisé par les logiciels.

En guise de conclusion, rappelons un avertissement : vue l'importance du DNS aujourd'hui, vue la quantité d'expérience accumulée depuis que ce protocole existe, vu le nombre de RFC qui contribuent à décrire le DNS, l'implémenteur de ce protocole ou le simple curieux qui voudrait apprendre ne doivent pas de contenter des deux RFC fondateurs mais doivent être prêts à avaler de nombreux autres textes.