Définition et concepts de base

Les bases de type WHOIS contiennent des informations techniques et administratives permettant entre autres de savoir qui est le titulaire d'un nom de domaine, qui gère tel bloc d'adresses IP (v4 ou v6), quelle est la politique de routage de tel AS... Il s'agit de bases distribuées à accès public dont l'interrogation est possible en utilisant des outils disponibles en standard sur une grande partie des systèmes Unix (commande whois tout simplement). Si ce n'est pas le cas, il existe un certain nombre de clients dont l'un des plus usités est celui qu'il est possible de télécharger sur le site du RIPE.

Il existe de plus, sur les sites des organismes assurant la gestion de bases WHOIS, des outils de consultation via une interface Web. De telles interfaces peuvent être trouvées sur les sites du RIPE, de l'INTERNIC, du 6BONE, ou bien encore de l'AFNIC. En ce qui concerne la distribution de l'information, tout ce qui concerne l'adressage IP et les informations de routage se trouve réparti sur 3 bases. La base ARIN pour l'Amérique du nord et du sud, les Caraïbes et l'Afrique sub-saharienne; la base RIPE pour l'Europe et une partie de l'Afrique; enfin la base APNIC pour la zone Asie Pacifique. Pour les adresses IPv6 de test (préfixe 3FFE::/16) il existe une base spécifique gérée par le 6BONE.

Types de données spécifiques à IPv6

Il existe 2 types de données qui ont été spécialement créés pour répondre aux besoins spécifiques à IPv6. Il s'agit des types inet6num et ipv6-site.

Les objets de type inet6num sont présents dans les bases RIPE, ARIN, APNIC et 6BONE, ceux de type ipv6-site ne sont utilisés que dans la base 6BONE car ils sont pour l'instant réservés aux adresses de test. D'ailleurs, ces deux types sont utilisés à titre expérimental et leurs format peut être amené à être modifié selon les besoins futurs.

Type inet6num

Ce type de données va permettre de définir les propriétés associées à un préfixe IPv6 donné. Le format qui est décrit ci-après ne concerne pas la base ARIN qui adopte un format minimaliste à l'image de la base INTERNIC pour les noms de domaines.

Format générique (template) d'un objet de type inet6num

Chaque ligne du template donne des informations sur un attribut. Après le nom de l'attribut, on indique sont statut (obligatoire, optionnel ou généré), s'il ne doit être présent qu'une seule fois ou non dans un objet et pour finir si cet attribut est une clef de recherche dans la base.

inet6num: [mandatory] [single] [primary/look-up key]
netname: [mandatory] [single] [lookup key]
descr: [mandatory] [multiple] [ ]
country: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
rev-srv: [optional] [multiple] [inverse key]
status: [generated] [single] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

• inet6num: Préfixe IPv6 dont on définit les attributs (format préfixe/taille du préfixe).
• netname: Le nom associé à la plage d'adresses définie par le préfixe.
• descr: Description succincte de l'objet.
• country: Code en 2 lettres (ISO 3166) identifiant le pays du contact administratif de l'organisme auquel appartient le préfixe.
• admin-c: Référence à un objet de type person/role identifiant un contact administratif pour l'objet inet6num. Cette référence est un NIC-Handle, c'est-à-dire un objet unique dans la base.
• tech-c: Référence à un objet de type person/role identifiant un contact technique pour l'objet inet6num. Cette référence est un NIC-Handle, c'est à dire un objet unique dans la base.
• rev-srv: Serveur de noms pour les reverses de la plage d'adresses définie par le préfixe.
• status: Type du préfixe (TLA, Sub-TLA, NLA, ...).
• remarks: Remarques divers et variées.
• notify: E-Mail de la personne qui est prévenue lors de toute modification effectuer sur l'objet.
• mnt-by: Référence à un objet de type mntner identifiant les personnes habilitées à modifier l'objet, ainsi que la méthode d'authentification.
• mnt-lower: Référence à un objet de type mntner identifiant les personnes habilitées à fournir des espaces d'adresses (avec ce préfixe) a des utilisateurs finaux.
• changed: E-Mail de la personne ayant effectuer la dernière mise à jour de l'objet, ainsi que la date de cette modification.
• source: Identification de la base où se trouve cet objet (6BONE, RIPE, APNIC, ARIN, ...)

Exemple d'objet de type inet6num

Si on utilise la commande suivante :

> whois -h whois.ripe.net 2001:0660::/35

On obtient le résultat suivant :

inet6num: 2001:0660::/35
netname: FR-RENATER-20000321
descr: Renater Sub-TLA block
descr: Réseau National de télécommunications pour la
descr: Technologie l'Enseignement et la Recherche
descr: National telecommunications network
descr: for Technology, Education and Research
country: FR
admin-c: BT261-RIPE
admin-c: GR1378-RIPE
tech-c: GR1378-RIPE
status: SUBTLA
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: RENATER-MNT
changed: hostmaster@ripe.net 20000321
changed: hostmaster@ripe.net 20000322
source: RIPE

On peut donc en déduire que le préfixe 2001:0660::/35 appartient au réseau FR-RENATER-20000321, qu'il s'agit d'un sub-TLA français géré par Renater. On a aussi les NIC-handles des différents contacts techniques et administratifs.

Type ipv6-site

Ce type d'objet est uniquement utilisé, pour le moment en tout cas, dans la base 6BONE, c'est à dire sur les adresses de test IPv6 (de type 3FFE::/16). Il sert a décrire les sites utilisant des adresses en IPv6.

Template d'un objet de type ipv6-site

Le type ipv6-site est décrit dans un document dont la validité a expiré le draft draft-ietf-ngtrans-6bone-registry-03.txt.

ipv6-site: [mandatory] [single]
origin: [mandatory] [single]
descr: [mandatory] [single]
location: [optional] [multiple]
country: [mandatory] [multiple]
prefix: [mandatory] [multiple]
application: [optional] [multiple]
tunnel: [optional] [multiple]
native: [optional] [multiple]
contact: [mandatory] [multiple]
remarks: [optional] [multiple]
url: [optional] [multiple]
notify: [optional] [multiple]
mnt-by: [optional] [multiple]
changed: [mandatory] [multiple]
source: [mandatory] [single]

• ipv6-site: Nom du site.
• origin: Numéro de l'AS (Autonomous System) dont fait partie le site.
• descr: Description succinte de l'objet.
• location: "Coordonnées terrestre" du site, pour plus de détails, se référer au RFC 1876.
• country: Code en 2 lettres (ISO 3166) identifiant le pays du contact administratif de l'organisme auquel appartient le site.
• prefix: Liste des préfixes IPv6 utilisés sur ce site.
• application: Liste des applications disponibles sur le site. En plus du nom de l'application, on indique l'équipement sur lequel elle est accessible. Par exemple "http://www.ipv6.toto.fr".
• tunnel: Les tunnels permettent d'encapsuler un protocole dans un autre. En l'occurrence, il s'agit principalement de tunnels IPv6 au-dessus d'une infrastructure en IPv4. On indique le protocole du tunnel, celui de l'infrastructure, le nom de la machine sur le site qui fait une des extrémités du tunnel, le nom de la machine distante qui fait l'autre bout du tunnel, le site où cette machine se trouve (optionnel), et pour finir le protocole de routage utilisé : STATIC, BGP4+... (optionnel). Par exemple:

IPv6 in IPv4 popeye.site1.fr -> olive.site2.fr OLIVE-SITE BGP4+

• native: Similaire a l'attribut "tunnel", à ceci près que cette fois-ci on décrit les connexion natives IPv6. La syntaxe est la même.
• contact: Référence à un objet de type "person" identifiant un contact pour le site.
• remarks: Remarques diverses et variées sur le fonctionnement général du site.
• url: Pointeurs sur quelques pages d'informations supplémentaires à propos du site.
• notify: E-Mail de la personne qui est prévenue lors de toute modification effectuée sur l'objet.
• mnt-by: Référence à un objet de type mntner identifiant les personnes habilitées à modifier l'objet, ainsi que la méthode d'authentification.
• changed: E-Mail de la personne ayant effectuée la dernière mise à jour de l'objet, ainsi que la date de cette modification.
• source: Identification de la base où se trouve cet objet (6BONE, RIPE, APNIC, ARIN, ...)

Exemple d'objet de type ipv6-site

Si on utilise la commande suivante :

> whois -h whois.6bone.net G6-UTBM

On obtient le résultat suivant :

ipv6-site: G6-UTBM
origin: AS1717
descr: Université de Technologie de Belfort-Montbéliard
country: FR
prefix: 3FFE:303:22::/48
tunnel: IPv6 in IPv4 testnm.utbm.fr ->
ipv6-cisco.ipv6.u-strasbg.fr G6-PIR-GE STTIC
contact: TN1-6BONE
remarks: This object is automatically converted from the RIPE181 registry
changed: noel@dpt-info.u-strasbg.fr 20000315
changed: auto-dbm@whois.6bone.net 20010117
source: 6BONE

Création, modification et suppression d'objets

Les différentes opérations possibles sur les objets contenus dans les bases de type WHOIS se passent toutes de la même manière, il suffit d'envoyer un mail a une adresse spécifique :

• auto-dbm@whois.6bone.net pour la base du 6BONE,
• auto-dbm@ripe.net pour la base RIPE.

Certains sites proposent des interfaces plus pratiques, comme sur le site de Viagenie65 qui permettent de réaliser tous les types d'opérations beaucoup plus facilement en évitant les habituelles erreurs de syntaxes qui ne manquent pas d'arriver en utilisant la technique des mails.

Création

Avant toute création, il est nécessaire d'avoir au moins un objet de type "person" ou "role" dans la base où l'on souhaite travailler afin d'obtenir un identifiant unique, plus communément appelé NIC-handle. Un objet de type "person" va être créé pour définir une personne physique.

L'objet de type role, lui, définit plus une fonction qu'un individu et son utilisation principale est de décrire par exemple une équipe technique d'un organisme. Lorsqu'un des membres de cette équipe s'en va ou qu'un nouveau arrive il suffit de modifier le contenu de l'objet de type role, il n'y a pas besoin de mettre à jour les autres objets qui référencent ce NIC-handle. Donc, la technique la plus approprié pour débuter tout enregistrement dans une base est de créer les objets "person" nécessaires afin d'obtenir des NIC-Handles, puis de créer le ou les objets "role" qui référencent les objets de types "person" précédemment créés et c'est ce dernier NIC-Handle obtenu que l'on choisira d'utiliser en priorité pour les contacts techniques ou administratifs. Si on choisit d'utiliser la technique de création par mail, il suffit d'envoyer un template correspondant à l'objet a créer correctement rempli. Pour avoir le format exact et la syntaxe de chaque attribut, il faut utiliser la commande suivante :

> whois -h whois.6bone.net -v ipv6-site

La commande précédente permet d'obtenir une documentation complète de l'objet de type ipv6-site tel qu'il est défini dans la base du 6BONE. Selon le même principe on peut demander la documentation concernant un objet de type person dans la base RIPE :

> whois -h whois.ripe.net -v person

Si jamais l'option "-v" n'est pas prise en compte par le client whois de votre système, il faut télécharger une version prenant quelques options avancées66.

Modification

Pour la modification par mail, il faut récupérer l'objet tel qu'il est stocké dans la base en utilisant tout simplement la commande whois, modifier le contenu et envoyer le mail ainsi compose.

Suppression

Pour la suppression, il faut récupérer l'objet dans la base et le renvoyer en ajoutant un attribut supplémentaire "delete" dans le template. Cela donnera quelque chose comme :

...
remarks: Ceci est un objet de test
delete: Un texte quelconque
changed: test@test.tt 20011111
source: G6BONE

Toutefois, si l'objet est protégé, il ne pourra être supprimé que si l'on connaît la méthode d'authentification.

Problèmes spécifiques à WHOIS

Le principal problème des bases WHOIS est qu'il existe deux grandes tendances au niveau du format des données, le style INTERNIC, minimaliste et à la lecture peu aisée et le style RIPE, plus complet et plus facile à comprendre.

Le second problème, qui en découle, est que les informations ne sont plus centralisées comme cela a été le cas à une époque. Si cela n'est pas trop dramatique en ce qui concerne les adresses IP puisqu'il n'y a que 3 bases (ARIN, APNIC et RIPE), cela est beaucoup plus gênant pour les noms de domaines puisque pratiquement chaque organisme d'enregistrement possède sa propre base. Et bien entendu, chacun utilise des templates plus ou moins différents dérivés des style RIPE et INTERNIC.

Le troisième problème, qui résulte des deux précédents, est qu'une même information stockée dans deux bases différentes n'aura pas du tout le même format et donc offrira plus ou moins de détails. Pour finir, il faut savoir que ces bases ne sont là qu'à titre d'information et leur contenu n'influence pas le fonctionnement de l'Internet. Il arrive donc que l'information que l'on obtient soit incomplète ou erronée.

Conclusion, si les bases de type WHOIS sont des alliés précieux pour obtenir des informations rapidement et facilement, une analyse technique un peu plus poussée est souvent nécessaire pour en vérifier la véracité et la complétude.