Un peu d'histoire, avec ce RFC 810, qui
mettait à jour le format du fichier géant qui, à l'époque, contenait
la liste de toutes les machines de
l'Internet. Il remplaçait le RFC 608.
Par rapport à son prédécesseur, ce RFC marquait le début de la fin de ce fichier
géant : ses limites étaient désormais bien comprises, et le
DNS était en cours
d'élaboration, quoique encore dans le futur. En attendant ce système
décentralisé et réparti, notre RFC mettait à jour la syntaxe du
fichier HOSTS.TXT
, aussi appelé
« hosts » ou « host
table ». Il s'appliquait à
l'Internet mais aussi à son prédécesseur
Arpanet qui, à l'époque, vivait encore, une
vie séparée. Le fichier était ensuite distribué par un serveur
centralisé, décrit dans le RFC 811. Si vous
vouliez le fichier entier, notre RFC rappelait les instructions, à
l'époque où les URL n'existaient pas encore : « Connectez-vous
à 10.0.0.73
en FTP, en utilisant le compte
ANONYMOUS
et le mot de passe
GUEST
, puis utilisez la commande
get
pour le fichier
HOSTS.TXT
». (On notera qu'à
l'époque, le FTP anonyme était réellement
anonyme, la convention d'utiliser son adresse comme mot de passe n'existait pas
encore.)
Bon, quelle était la syntaxe de ce fichier ? Les noms étaient
composés de lettres ASCII, de chiffres, de
traits d'union et de
points, en 24 caractères maximum. Ils étaient
insensibles à la casse. Il existait des
conventions de nommage : un routeur devait
avoir un nom se terminant en -GATEWAY
ou
-GW
. Un TAC devait se nommer
quelquechose-TAC
. (Le RFC ne prend pas la peine
d'expliquer ce qu'est un TAC. Un TAC,
Terminal Access Controller était un ordinateur
spécialisé dans le service de terminaux, qui n'avait pas de compte
local et ne servait qu'à se connecter à des ordinateurs
distants.)
Le RFC décrit ensuite le format des adresses. Loin des débuts de
l'Arpanet, elles étaient déjà sur 32 bits à
l'époque (cela avait été normalisé par le RFC 796 en 1981). La longueur du
préfixe dépendait de la valeur des premiers bits de l'adresse (le
système des classes, qui a été abandonné en 1993).
Le fichier contenait aussi les noms des réseaux. Pour les
machines, le fichier ne contenait pas que noms et adresses. À cette
époque sans Web et sans
moteur de recherche, il servait aussi à
publier les services disponibles sur chaque machine. Et il indiquait
aussi le système d'exploitation des machines,
information utile quand on voulait se connecter avec
telnet. (D'autres protocoles nécessitaient de
connaitre ce système d'exploitation. L'utilisation de FTP en dépendait, sans
compter les problèmes d'encodage des
caractères, dans un monde sans
Unicode.) Voici quelques exemples de
machines, datant de 1983 :
HOST : 10.0.0.4, 192.5.12.21 : UTAH-CS : VAX-11/750 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP :
HOST : 10.0.0.6 : MIT-MULTICS,MULTICS : HONEYWELL-DPS-8/70M : MULTICS : TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,TCP/ECHO,TCP/DISCARD,ICMP :
HOST : 10.0.0.9 : HARV-10,ACL : DEC-10 : TOPS10 ::
HOST : 32.2.0.42 : UCL-TAC,LONDON-TAC : H-316 : TAC : TCP :
HOST : 26.4.0.73 : SRI-F4 : FOONLY-F4 : TENEX ::
HOST : 10.0.0.51, 26.0.0.73 : SRI-NIC,NIC : DEC-2060 : TOPS20 : TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP :
Vous noterez que l'université d'Utah
utilise toujours, en 2021, le même préfixe
192.5.12.0/24
… Par contre, le
MIT n'a plus de service ECHO… (Ce service
était normalisé dans le RFC 862.) La machine de
l'UCL était une des rares étrangères aux
USA. Le Foonly qu'on voit au
SRI était une machine connue pour avoir fait
les CGI des films Tron
et, come le note John Shaft, Looker :
« première fois qu'il était possible de voir de la
3D avec ombrage dans un film, de mémoire. Un
corps humain de surcroît. ». Quant à la machine
SRI-NIC
, c'est elle qui distribuait ce fichier
(son adresse avait changé depuis la publication du RFC).
L'internet était encore assez centralisé à l'époque, et il était
possible de décider d'un « jour J », où on fait changer tout le
monde en même temps : ce RFC fixait la date au 1er mai 1982, où tout
le monde devait utiliser le nouveau format, l'ancien, celui du RFC 608, étant abandonné.
Une copie du fichier de 1983 est en
ligne (merci à Patrick Mevzek pour l'avoir trouvée) et j'en
ai fait une copie locale.
RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
- 31 mars -
Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau (...)
Association entre adresse IP et AS
- 29 mars -
Dans les discussions au sujet du réseau Internet, on voit souvent passer des demandes sur l'AS associé à une adresse IP ou bien le contraire. Mais (...)
DNS hackathon 2025 in Stockholm
- 23 mars -
On 15 and 16 March 2025, I was at the DNS hackathon 2025 in Stockholm, organised by RIPE NCC, DNS-OARC and Netnod. I worked on a mechanism to (...)
RFC 9755: IMAP Support for UTF-8
- 18 mars -
Successeur du RFC 6855, voici la normalisation de la gestion d'Unicode par le protocole IMAP (dans sa version 4rev1) d'accès aux boîtes aux (...)
RFC 8738: Automated Certificate Management Environment (ACME) IP Identifier Validation Extension
- 7 mars -
Le protocole ACME, surtout connu via son utilisation par l'AC Let's Encrypt, permet de prouver la « possession » d'un nom de domaine, pour avoir un (...)