Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

WHOIS DB - Manuel de référence

Revu pour l'utilisation d'AFRINIC par: Adiel Akplogan
Identifiant du document: afsup-dbref200501-Draft
Date: 20 Janvier 2005


Abstrait

Ce document décrit les fonctionnalités de la base de données AFRINIC qui utilise le langage de spécification de politique de routage (RPSL) [1] pour représenter tous les objets de la base de données. Bien que ce document ait tendance à être autonome, le lecteur est encouragé à lire le RPSL [ 1 ] et RPSS [ 2 ] spécifications pour des informations plus détaillées, des exemples d'utilisation et des définitions. Pour un tutoriel sur RPSL, le lecteur doit lire le document des applications RPSL [ 3 ]


Tabel de contenu

Introduction
   1.0 Requêtes dans la base de données AFRINIC
      1.1 Requêtes utilisant des clés primaires et de recherche
      1.2 Recherches d'adresses IP
         1.2.1 Recherche par défaut des plages IP dans la base de données AFRINIC
         1.2.2 Des requêtes plus et moins spécifiques
      1.3 Requêtes inverses
      1.4 Récupérer tous les membres des objets set
      1.5 Recherches plus / moins spécifiques pour les domaines in-addr.arpa et ip6.arpa
      1.6 Mécanisme de référence pour les domaines
      1.7 Contrôle d'accès aux requêtes
      1.8 Autres fonctionnalités du serveur
   2.0 Mises à jour dans la base de données AFRINIC
      2.1 Format d'un message de mise à jour
      2.2 Création, modification et suppression d'un objet
         2.2.1 Traitement d'objets
         2.2.2 Création d'un nouvel objet
         2.2.3 Modification d'un objet existant
         2.2.4 Supprimer un objet
      2.3 Mises à jour par e-mail
         2.3.1 Prise en charge MIME
         2.3.2 Prise en charge PGP
         2.3.3 Traitement de la ligne d'objet
      2.4 Mises à jour à l'aide de l'utilitaire networkupdate
      2.5 Remerciements et notifications
         2.5.1 Remerciements
         Notifications 2.5.2
      2.6 Protection des données
         2.6.1 Modèle d'autorisation
         2.6.2 Protection des objets individuels
         2.6.3 Protection de l'espace objet aut-num
         2.6.4 Protection de l'espace d'adressage
         2.6.5 Protection des objets avec des noms hiérarchiques
         2.6.6 Protection de l'espace objet du domaine
         2.6.7 Protection de l'appartenance à un ensemble [**]
   3.0 Mise en miroir de la base de données AFRINIC 
   annexes

Conventions utilisées dans ce document

Dans ce document, les conventions suivantes sont utilisées:

indique un espace réservé ou une spécification de syntaxe [option] indique un texte facultatif ou un argument de commande.

Veuillez noter que dans les modèles d'objet, les crochets "[]" sont utilisés pour spécifier le type d'un attribut. "attribut:" indique un attribut.


Introduction

La base de données de gestion de réseau AFRINIC contient des informations sur les allocations et les attributions d'espace d'adresses IP. Le registre de routage dans la région AFRINIC sera effectué à ce stade par RIPE NCC. Cette base de données ne contient aucune information sur le nom de domaine. Veuillez consulter le IANA Base de données ccTLD pour une liste complète des administrateurs ccTLD.

Les informations contenues dans la base de données AFRINIC sont accessibles au public à des fins de fonctionnement Internet convenues, mais sont protégées par le droit d'auteur. S'il te plait regarde Annexe A3 "Informations sur le droit d'auteur".

L'expression "base de données AFRINIC" est souvent utilisée pour faire référence au logiciel d'interface plutôt qu'aux informations stockées dans la base de données. Dans des situations ambiguës, ce manuel de référence clarifiera ce qui est discuté.

Ce document décrit les fonctionnalités de la base de données AFRINIC (basée sur la version 3.0 de RIPE NCC WHOIS). Cette version utilise le langage de spécification de politique de routage (RPSL) [1]. Il intègre également la sécurité du système de politique de routage (RPSS) [2] pour fournir des mécanismes d'autorisation permettant un niveau de sécurité plus élevé pour le registre de routage. Notez que cette dernière fonctionnalité n'est pas encore utilisée par AFRINIC.

Ce document est autonome. Cependant, il ne contient pas d'exemples d'utilisation et d'illustrations de principes et de concepts liés à la fonctionnalité et à la mise en œuvre de la base de données AFRINIC. Le "Manuel de l'utilisateur de la base de données AFRINIC"[5] et le "Manuel des opérations de la base de données AFRINIC" [5] comblera cette lacune et fournira des exemples et des informations détaillées sur la manière d'interagir avec la base de données AFRINIC et de configurer et d'exécuter le logiciel serveur de la base de données AFRINIC. Le lecteur est également encouragé à lire le RPSL [1] et RPSS [2] spécifications pour des informations plus détaillées, des exemples d'utilisation et des définitions. Pour un tutoriel sur RPSL, le lecteur doit lire le document des applications RPSL [3].

 

1.0 Requêtes dans la base de données AFRINIC

Cette section décrit les fonctionnalités fournies dans la base de données AFRINIC pour permettre aux utilisateurs de récupérer des objets de base de données. L'interrogation de la base de données se fait à l'aide d'un client qui utilise le Whois protocole [12] pour interroger et obtenir les réponses.

Cette base de données incorporait un mécanisme pour activer whois serveur pour suivre automatiquement les réponses aux requêtes et limiter la récupération des informations de contact à partir de la base de données AFRINIC est également décrit dans cette section. L'intention est de limiter les utilisations non opérationnelles des données (telles que la publicité) tout en permettant de réaliser les utilisations opérationnelles de la base de données.

Il existe un ensemble de règles générales sur les réponses du serveur:

  • La sortie commençant par le signe% est soit un code de réponse du serveur, soit un message d'information. Un commentaire contient un espace blanc après le signe%, tandis que les messages du serveur commencent juste après le signe%. S'il te plait regarde Annexe A2 "Codes de réponse et messages de la base de données AFRINIC" pour plus d'informations.
  • Une ligne vide ("\ n \ n") est un délimiteur d'objet.
  • Deux lignes vides signifient la fin d'une réponse du serveur.
  • Lors de l'utilisation du mécanisme de référence, la sortie du serveur référé est transmise au client sans modification. Voir section 1.6 "Mécanisme de référence pour les domaines" pour plus d'information.

Le format général d'une requête est:

[-query_flags [argument de requête]]

 

1.1 Requêtes utilisant des clés primaires et de recherche  

Les requêtes normales sont effectuées à l'aide des clés primaires et de recherche comme argument d'une requête. Ces requêtes sont présentées dans Tableau 1 . Veuillez vous référer au document "Types d'objets dans la base de données AFRINIC" pour la définition des clés primaires et de recherche pour une classe.

 

1.2 Recherches d'adresses IP  

Le service le plus important fourni par la base de données AFRINIC est probablement de fournir des informations sur les réseaux IP sur Internet. Ces informations sont stockées dans la base de données sous forme d'inetnum.

Les inetnum et inet6num stockent des informations sur les plages d'adresses IP.

Pour IPv4, le préfixe est un entier de 32 bits écrit en notation quadruple en pointillés et ayant la valeur de l'adresse IP la plus basse de la plage. La longueur du préfixe est un nombre entier compris entre 0 et 32 ​​(par exemple, 193.0.0.0/22 ​​spécifie la plage de 1024 IPv4 adresses commençant par, et incluant, 193.0.0.0).

Les objets inetnum représentent un IPv4 espace d'adressage en notation de plage où la plage est explicitement spécifiée comme deux entiers de 32 bits écrits en notation quadruple en pointillés séparés par un tiret ("-") (par exemple 93.0.0.0-193.0.3.255, qui spécifie la même plage que ci-dessus).

En traitant avec IPv6 plages d'adresses, seule la norme IPv6 la notation de préfixe est autorisée (la longueur du préfixe doit être comprise entre 0 et 128 et le préfixe est un entier de 128 bits, écrit en groupes hexadécimaux de 2 octets séparés par des deux-points et avec l'utilisation possible de la notation abrégée pour les chaînes de 0 consécutifs).

Lorsqu'il interroge la base de données pour obtenir des informations sur une plage d'adresses IP, l'utilisateur peut utiliser comme clés de recherche les notations de plage suivantes:

  • un préfixe, qui a la même signification que ci-dessus;
  • une plage explicite, également comme ci-dessus;
  • un numéro IP unique, qui, lorsqu'il est utilisé comme argument d'une requête, est interprété comme une plage d'exactement 1 adresse.

Ces types de requêtes sont présentés dans Tableau 2 . Le reste de cette section décrit comment un utilisateur peut demander le renvoi de différents types d'informations, par rapport à une plage d'adresses IP particulière.

Avant d'entrer dans les détails, il est utile de définir trois concepts fréquemment utilisés dans ce type de requêtes et qui sont définis par rapport à la plage spécifiée par l'utilisateur (référence):

  • Une plage moins spécifique est une plage qui contient la totalité de la plage de référence et est plus grande (contient plus d'adresses IP) que la plage de référence.
  • Une plage plus spécifique est une plage contenue dans la plage de référence et contient moins d'adresses IP que la plage de référence.
  • Une correspondance exacte fait référence à une plage identique à la plage de référence.

 

1.2.1 Recherche par défaut des plages IP dans la base de données AFRINIC 

Lorsqu'aucun indicateur n'est spécifié et que la clé de requête est envoyée au whois serveur est une plage d'adresses IP (soit IPv4 or IPv6, exprimée sous la forme d'une seule adresse IP, de deux adresses IP séparées par un tiret ("-") ou une plage d'adresses IP en notation de préfixe), l'AFRINIC whois le serveur essaiera de trouver une correspondance exacte pour cette plage.

Si une correspondance exacte est trouvée, elle est renvoyée. Sinon, une recherche de la plus petite plage moins spécifique est effectuée et celle-ci est renvoyée.

 

1.2.2 Des requêtes plus et moins spécifiques

Parfois, la correspondance exacte n'est pas l'information souhaitée. Dans ce cas, il existe un ensemble d'indicateurs qui modifient la réponse du whois serveur. Cet ensemble de 4 indicateurs ("-M", "-m", "-L" et "-l") fournit deux types génériques de requêtes appelées requêtes de plus en moins spécifiques.

 

1.2.2.1 Requêtes moins spécifiques 

Ceux-ci font référence aux requêtes déclenchées par l'utilisation des drapeaux "-l" et "-L". Ces requêtes renverront des informations sur les plages d'adresses IP qui contiennent entièrement la plage fournie par l'utilisateur et peuvent contenir plus d'adresses.

L'indicateur "-L" demande que le serveur renvoie la correspondance exacte, le cas échéant, et tous les objets contenant des informations sur les plages IP qui sont plus grandes que la plage fournie par l'utilisateur et la contiennent entièrement.

L'indicateur "-l" demande que le serveur ne retourne PAS la correspondance exacte mais uniquement la plus petite des plages IP qui est plus grande que la plage fournie par l'utilisateur et qui la contient entièrement. Il s'agit généralement de la plage spécifique à un niveau.

 

1.2.2.2 Requêtes plus spécifiques 

Ceux-ci font référence aux requêtes déclenchées par l'utilisation des drapeaux "-m" et "-M". Ces requêtes renverront des informations sur les plages d'adresses IP qui sont entièrement contenues dans la plage fournie par l'utilisateur et contiennent moins d'adresses.

L'indicateur "-M" demande qu'au lieu de renvoyer la correspondance exacte, le serveur doit renvoyer toutes les sous-plages complètement contenues dans la plage fournie par l'utilisateur, quelle que soit leur taille.

Le "-m" est l'équivalent plus spécifique du drapeau "-l". Il demande qu'au lieu de renvoyer la correspondance exacte, le serveur doit renvoyer des sous-plages qui sont entièrement contenues dans la plage fournie par l'utilisateur. Mais au lieu de signaler toutes les sous-plages existantes, il ne renverra que les plus grandes plages contenues dans la plage utilisateur. Ceux-ci sont généralement appelés un niveau plus spécifique.

 

1.3 Requêtes inverses 

Les requêtes inverses sont effectuées sur des clés inverses telles que définies dans les modèles d'objet de la base de données AFRINIC. Pour une liste complète de ces modèles, veuillez vous référer au document "Types d'objets dans la base de données AFRINIC". En émettant ce type de requête, le client demande tous les objets qui font référence

l'objet avec la clé spécifiée comme argument de requête à renvoyer par la base de données. On peut également demander une requête inverse pour plusieurs attributs (par exemple trouver quels objets référencent un objet mntner spécifique par des attributs "mnt-by:", "mnt-lower:").

Dans ce cas, l'indicateur de requête doit être représenté par une liste d'attributs séparés par des virgules à rechercher. Aucun espace blanc n'est autorisé dans la liste.

Veuillez vous référer au Tableau 4 pour une liste complète des requêtes inverses prises en charge.

 

1.4 Récupérer tous les membres des objets set 

Dans RPSL [3] il existe deux façons dont un objet peut être membre d'un objet défini.

La première consiste à répertorier les objets dans un attribut "members:" de l'objet set. C'est le type de relation de membre présent dans "Représentation des politiques de routage IP dans un registre de routage" [4] (par exemple, attribut "as-list:" dans les objets as-macro).

L'autre façon de spécifier une relation d'appartenance consiste à utiliser l'attribut "member-of:". Cet attribut peut être utilisé dans les classes route, aut-num et inet-rtr. La valeur de l'attribut "member-of:" identifie un objet défini dont cet objet veut être membre.

Cependant, spécifier membre-de ne suffit pas. L'objet set doit également avoir un attribut "mbrs-by-ref:" listant le mainteneur de l'objet voulant être membre de l'ensemble. C'est-à-dire que le propriétaire de l'ensemble doit valider la revendication d'appartenance d'un objet avec un attribut "member-of:", et il le fait en faisant correspondre la ligne mnt-by de l'objet avec l'un des responsables du "mbrs-by-" ref: "attribut de l'objet défini.

 

1.5 Recherches plus / moins spécifiques pour les domaines in-addr.arpa et ip6.arpa 

La base de données AFRINIC prend en charge les recherches IP, y compris les fonctionnalités «-x», «-m», «-M», «-l» et «-L» pour les domaines de délégation inversée. Pour demander que les domaines de délégation inversée soient recherchés, utilisez l'indicateur "-d" dans votre Whois Requête de recherche IP.

 

1.6 Mécanisme de référence pour les domaines 

Le mécanisme de référence permet aux administrateurs de registres de domaine d'instruire le whois serveur pour répondre à l'utilisateur en récupérant les données de la base de données du registre du domaine plutôt que des données locales. Sa mise en œuvre se compose de deux parties différentes:

  1. Suppression du nom de domaine: lorsqu'aucun objet de domaine correspondant n'est trouvé dans la base de données avec le nom spécifié dans la requête, le nom de domaine est supprimé vers les domaines de niveau supérieur (xxx.yyy.zzz devenant yyy.zzz) et la recherche est répétée jusqu'à ce qu'un l'objet de domaine est trouvé ou la chaîne de recherche devient vide. Pour des raisons de compatibilité ascendante, si l'objet de domaine trouvé par suppression de domaine ne contient pas d'attribut «refer:», alors il est considéré qu'aucun objet n'est trouvé et un message approprié est affiché. S'il te plait regarde Annexe A2 "Codes de réponse et messages de la base de données AFRINIC" pour plus d'informations.
  2. L'attribut "refer:": l'attribut "refer:" donne aux administrateurs de noms de domaine la possibilité de pointer whois serveur vers un serveur faisant autorité pour obtenir des informations sur le nom de domaine. Cet attribut spécifie le nom d'hôte, le port et le type de référence que le serveur doit utiliser pour rediriger la requête. S'il te plait regarde Annexe A1 "Attributs d'objet" pour la syntaxe de cet attribut.

Si une requête au whois le serveur entraîne la récupération d'un objet local qui contient un attribut "refer:", le serveur se connecte au serveur distant et émet un whois requête pour le nom de domaine demandé. Tout ce qui est retourné est ensuite envoyé à l'utilisateur. Ce mécanisme est désactivé en incluant l'indicateur "-R" dans la requête d'origine.

 

1.7 Contrôle d'accès aux requêtes 

Cette section décrit le mécanisme de contrôle du nombre d'objets de base de données whois le client peut récupérer depuis le whois serveur. L'objectif est de contrôler et d'empêcher l'utilisation abusive de la base de données par des requêtes systématiques d'informations de contact potentiellement utilisées à des fins non convenues (par exemple, le spam).

Par conséquent, le système de contrôle d'accès limite uniquement la quantité d'informations de contact (nombre d'objets de personne et de rôle) qui peuvent être récupérées dans un certain laps de temps. Aucune limitation n'existe sur le nombre d'autres objets.

Cependant, il faut garder à l'esprit que de nombreuses recherches de types d'objet, autres que personne et rôle, renvoient également les informations de contact par défaut. Pour éviter d'être bloqué dans de tels cas, il est conseillé d'utiliser l'indicateur de requête "-r".

Chaque fois qu'une personne ou un objet de rôle est récupéré, un compteur est diminué. Lorsqu'il atteint zéro, l'exécution de la requête est abandonnée et la connexion est interrompue, affichant un message d'erreur au client (voir «Erreurs d'accès» dans Annexe A2 "Codes et messages de réponse de la base de données AFRINIC"), également un compteur de dépassements (refus) est incrémenté. La base de données peut limiter le nombre de refus, après quoi l'hôte est définitivement bloqué de l'accès à la base de données AFRINIC. L'administration de la base de données peut également bloquer un client manuellement au cas où un comportement abusif serait découvert.

Le compteur récupère à temps. L'hôte peut reprendre l'interrogation des informations de contact après la récupération du compteur afin que l'hôte obtienne une limite non nulle pour les contacts la prochaine fois. La comptabilité est basée sur l'adresse IP d'un client.

Le serveur de base de données AFRINIC fournit une fonctionnalité pour les clients proxy (par exemple, les serveurs Web exécutant des interfaces cgi vers la base de données AFRINIC) qui permet à la comptabilité d'être basée non pas sur l'adresse IP du proxy, mais plutôt sur les clients qui utilisent ce proxy pour interroger la base de données AFRINIC. L'indicateur "-V" prend en charge cette fonctionnalité. Dans ce cas, le format de la requête est le suivant:

-V ,ipv4-adresse>

De

est une balise client qui représente généralement la version du logiciel utilisée par le proxy;

<ipv4-address> est le IPv4 adresse du client qui interroge la base de données à l'aide du proxy.

 

Notez que l'adresse IP du proxy doit être enregistrée dans la liste de contrôle d'accès de la base de données AFRINIC. Veuillez contacter l'administration de la base de données AFRINIC si vous avez besoin de cette option.

 

1.8 Autres fonctionnalités du serveur 

Le serveur de base de données AFRINIC prend en charge la récupération de certaines informations sur lui-même et les ensembles de données servis à l'aide d'un indicateur de requête "-q".

L'indicateur "-q" prend des arguments qui font répondre le serveur avec des informations qui ne sont pas extraites des bases de données qu'il dessert mais plutôt sur la configuration du système. Ce drapeau peut actuellement prendre deux arguments:

* version (utilisation: -q version). Affichez les informations de version du logiciel serveur.

* sources (utilisation: -q sources). Répertoriez toutes les sources disponibles. Le format de la sortie est:

: : : -

- est la chaîne qui identifie la base de données

(par exemple AFRINIC); identifie la version du protocole de mise en miroir.

peut prendre l'une des valeurs suivantes:

- O / N / X - peut refléter / ne peut pas refléter / obscurcir

est le plus petit numéro de série disponible

est le numéro de série le plus récent disponible.

La sémantique suivante s'applique:

Y: - mise en miroir autorisée, séries de la première à la dernière plage disponibles.

N: - la mise en miroir n'est pas autorisée pour des raisons administratives. Demandez l'autorisation de l'administration de la base de données.

N: 0- mise en miroir physiquement impossible (par exemple, instantané statique de la dernière série).

X: pas de mise en miroir autorisée. Une explication est donnée dans le .

Les tableaux 1 à 6 contiennent tous les types de requêtes pris en charge par la base de données AFRINIC:

Tableau 1 Requêtes utilisant des clés primaires et de recherche

Drapeau

Clé (s) de recherche

d'Entourage

 

(IPv4 préfixe d'adresse, plage ou adresse unique)

Renvoie inetnum, achemine les objets avec une correspondance exacte sur la clé spécifiée. Si la correspondance exacte n'existe pas, les objets avec la plus petite correspondance moins spécifique sont renvoyés. Lorsqu'une seule adresse est spécifiée, un objet inet-rtr dont l'attribut "ifaddr:" correspond à l'argument de requête est également renvoyé.

 

(IPv6 adresse ou IPv6 préfixe)

Renvoie un objet inet6num avec une correspondance exacte sur une clé spécifiée. Si la correspondance exacte n'existe pas, l'objet avec la plus petite correspondance moins spécifique est renvoyé.

 

Renvoie un objet aut-num dont l'attribut "aut-num:" correspond à l'argument de requête et à un objet as-block avec la plage contenant l'objet aut-num, s'il existe.

 

- (plage de séparé par "-")

Renvoie un objet as-block dont la clé primaire définit une plage qui correspond ou contient entièrement la plage spécifiée dans l'argument de requête.

 

Renvoie les objets domaine et inet-rtr dont les clés primaires correspondent à l'argument de requête. Pour les domaines, une requête de référence peut être effectuée. Dans ce cas, la requête réelle est effectuée par le serveur référé et les résultats sont transmis de manière transparente au client. Voir section 2.7 "Mécanisme de référence pour les domaines" pour plus d'information.

 

Renvoie un objet irt dont la clé primaire correspond à l'argument de requête.

 

Renvoie tous les objets personne et rôle dont les attributs "personne:" ou "rôle:" contiennent le nom spécifié dans l'argument de requête.

 

Renvoie un ensemble dont la clé primaire correspond à l'argument de requête.

 

Renvoie un objet personne ou rôle dont l'attribut "nic-hdl:" correspond à l'argument de requête.

 

Renvoie un objet mntner dont la clé primaire correspond à l'argument de requête.

 

 Tableau 2 Recherches d'adresses IP

Drapeau

Clé (s) de recherche

d'Entourage

-l

Renvoie les objets inetnum, inet6num ou route de premier niveau moins spécifiques, à l'exclusion des correspondances exactes.

-L

Renvoie tous les objets inetnum, inet6num ou route moins spécifiques, y compris les correspondances exactes.

-m

Renvoie des objets inetnum, inet6num ou route plus spécifiques de premier niveau, à l'exclusion des correspondances exactes.

-M

Renvoie tous les objets inetnum, inet6num ou route plus spécifiques, à l'exception des correspondances exactes.

-x

Demande que seule une correspondance exacte sur un préfixe soit effectuée. Si aucune correspondance exacte n'est trouvée, aucun objet n'est renvoyé.

-d

Active les recherches sur les domaines de délégation inverse. Peut être utilisé avec les drapeaux "-x", "-m", "-M", "-l" et "-L".

-c

Renvoie le plus petit objet inetnum ou inet6num le moins spécifique contenant la référence à un objet irt. Le résultat de cette recherche est un objet inetnum ou inet6num et des contacts référencés, si la récursivité du nom n'est pas désactivée (indicateur "-r"). Il ne contient pas l'objet irt référencé, ni les coordonnées de l'équipe. Prière de se référer à pour plus d'informations sur l'objet irt.

 

 Tableau 3 Requêtes inverses

Drapeau
(forme alternative)

Clé (s) de recherche

d'Entourage

-je ac
(-i administrateur-c)

ou

Renvoie tous les objets dont les attributs "admin-c:" correspondent à l'argument de requête.

-je ah
(-i auteur)

ou

Renvoie tous les objets limerick dont l'attribut "author-c:" correspond à l'argument de requête.

-je pn
(-i personne)

ou

Renvoie tous les objets dont l'attribut "admin-c:", "tech-c:", "zone-c:", "author:" ou "cross-nfy:" correspond à l'argument de requête.

-je ct
(-Je croise-mnt)

Renvoie tous les objets route et aut-num dont les attributs "cross-mnt:" correspondent à l'argument de requête.

-je cn
(-je traverse nfy)

ou

Renvoie tous les objets route et aut-num dont l'attribut "cross-nfy:" correspond à l'argument de requête.

-je je
(-je irt-nfy)

Renvoie tous les objets irt dont l'attribut "irt-nfy:" correspond à l'argument de requête.

-je la
(-je local-comme)

Renvoie tous les objets inet-rtr dont l'attribut "local-as:" correspond à l'argument de requête.

-je mi
(-je mnt-irt)

Renvoie tous les objets inetnum et inet6num dont l'attribut "mnt-irt:" correspond à l'argument de requête.

-i monsieur
(-i mbrs-par-ref)

Renvoie tous les objets set (as-set, route-set et rtr-set) dont l'attribut "mbrs-by-ref:" correspond à l'argument de requête.

-je mo
(-i membre-de)

Renvoie tous les objets dont l'attribut "member-of:" correspond à l'argument de requête et leur revendication d'appartenance est validée par l'attribut "mbrs-by-ref:" de l'ensemble. L'absence de l'attribut "mbrs-by-ref:" signifie que l'appartenance n'est définie que par l'attribut "members:" de l'ensemble.

-je mb
(-je mnt-par)

Renvoie tous les objets dont l'attribut "mnt-by:" correspond à l'argument de requête.

-je ml
(-i mnt-inférieur)

Renvoie tous les objets dont l'attribut "mnt-lower:" correspond à l'argument de requête.

-je mn
(-je mnt-nfy)

Renvoie tous les objets mntner dont l'attribut "mnt-nfy:" correspond à l'argument de requête.

-je suis
(-i mnt-routes)

Renvoie tous les objets aut-num, inetnum et route dont l'attribut "mnt-routes:" correspond à l'argument de requête.

-je ny
(-Je préviens)

Renvoie tous les objets dont l'attribut "notify:" correspond à l'argument de requête.

-je ns
(-I nserveur)

ou (IPv4/IPv6 adresse)

Renvoie tous les objets de domaine dont l'attribut "nserver:" correspond à l'argument de requête.

-i ou
(-i origine)

Renvoie tous les objets de route dont l'attribut "origin:" correspond à l'argument de requête.

-je rb
(-i référence par)

Renvoie tous les objets mntner dont l'attribut "referral-by:" correspond à l'argument de requête.

-je rz
(-je rev-srv)

ou (IPv4/IPv6 adresse)

Renvoie tous les objets inetnum et inet6num dont l'attribut "rev-srv:" correspond à l'argument de requête.

-je sd
(-i sous-dom)

Renvoie tous les objets de domaine dont l'attribut "sub-dom:" correspond à l'argument de requête.

-je tc
(-je technologie-c)

ou

Renvoie tous les objets dont l'attribut "tech-c:" correspond à l'argument de requête.

-je dt
(-i mise à jour)

Renvoie tous les objets mntner dont l'attribut "upd-to:" correspond à l'argument de requête.

-je zc
(-je zone-c)

ou

Renvoie tous les objets dont l'attribut "zone-c:" correspond à l'argument de requête.

 

Tableau 4 Prise en charge des requêtes pour les outils

Drapeau

Clé (s) de recherche

d'Entourage

-F

 

Produit une sortie utilisant une notation abrégée pour les noms d'attribut. Produit des réponses plus lentes.

-K

 

Demande que seules les clés primaires d'un objet soient retournées. Les exceptions sont des objets set, où les attributs "members:" seront également retournés. Cet indicateur ne s'applique pas aux objets personne et rôle.

-k

(requête normale facultative)

Demande une connexion persistante. Après avoir renvoyé le résultat, la connexion ne sera pas fermée par le serveur et un client peut émettre plusieurs requêtes sur la même connexion. Notez que le serveur implémente un protocole "stop-and-wait", où aucune requête suivante ne peut être envoyée avant de recevoir une réponse pour la précédente. Utilisez RIPE whois client pour pouvoir envoyer des requêtes en mode batch. À l'exception de la première «requête -k», «-k» sans argument ferme la connexion persistante.

-g

(demande de mise en miroir)

Demandez un flux NRTM au serveur. Voir section 4.0 "Mise en miroir de la base de données RIPE" pour plus d'information.

Tableau 5 Requêtes diverses

Drapeau Argument

d'Entourage

-R

 

Désactive l'utilisation du mécanisme de référence pour les recherches de domaine, de sorte que la base de données renvoie un objet dans la base de données RIPE avec la correspondance exacte avec l'argument de recherche, plutôt que d'effectuer une recherche de référence.

-r

 

Désactive la récursivité des informations de contact après avoir récupéré les objets qui correspondent à la clé de recherche.

-T

(liste de types d'objets séparés par des virgules, aucun espace blanc n'est autorisé)

Limite les types d'objets à rechercher dans la requête.

-a

 

Spécifie que le serveur doit effectuer des recherches dans toutes les sources disponibles. Voir aussi la requête "-q sources".

-s

(liste de sources séparées par des virgules, aucun espace blanc n'est autorisé)

Spécifie quelles sources et dans quel ordre doivent être recherchées lors de l'exécution d'une requête.

Tableau 6 Requêtes d'information

Drapeau

Argument

d'Entourage

-q

sources

Renvoie l'ensemble actuel de sources ainsi que les informations requises pour la mise en miroir. Voir section 2.9 "Autres fonctionnalités du serveur" pour plus d'information.

-q

version

Affiche la version actuelle du serveur.

-t

Demande un modèle pour le type d'objet spécifié.

-V

 

Envoie des informations sur le client au serveur.

-v

Demande un modèle détaillé pour le type d'objet spécifié.

Les notations suivantes sont utilisées dans ce tableau:

désigne le nom complet ou abrégé d'une classe spécifique;
est une chaîne sans espace blanc qui porte généralement le nom du logiciel du client.

Veuillez vous référer à la section 2.8 "Contrôle d'accès aux requêtes" pour plus d'informations sur l'utilisation de cet indicateur pour les clients proxy. D'autres notations sont expliquées dans le tableau A1.

 

2.0 Mises à jour dans la base de données AFRINIC 

Pour créer un nouvel objet, mettre à jour un objet existant ou supprimer un objet de la base de données AFRINIC, un message de mise à jour doit être envoyé à la base de données pour traitement. Deux types de soumissions sont possibles:

* Mises à jour via e-mail qui est la principale interface publique, et en ligne;

* Mises à jour via l'interface "networkupdate". Cette méthode est interne et n'est utilisée qu'à partir de nœuds autorisés; typiquement, les nœuds appartenant au LAN du bureau interne de l'AFRINIC.

 

2.1 Format d'un message de mise à jour 

Si vous envoyez le message par e-mail, le message peut également être un message codé MIME. La mise à jour est normalement en texte brut. Dans le premier cas, chaque partie MIME valide est traitée comme un message distinct. Le message de mise à jour peut contenir plusieurs objets. Veuillez consulter la section 2.3.1 "Prise en charge MIME" pour plus d'information.

Dans un message de mise à jour, un objet doit être représenté textuellement sous la forme d'une liste de paires attribut-valeur. Chaque paire attribut-valeur est écrite sur une ligne distincte. Le nom de l'attribut commence à la colonne 0, suivi du caractère ":" et suivi de la valeur de l'attribut. L'attribut, qui porte le même nom que la classe de l'objet, doit être spécifié en premier. La valeur d'un attribut peut être divisée sur plusieurs lignes, en ayant un espace, un onglet ou un plus ("+")

caractère comme premier caractère des lignes de suite. Le caractère «+» pour la continuation de ligne permet aux valeurs d'attribut de contenir des lignes vides. Plus d'espaces peuvent éventuellement être utilisés après le caractère de continuation pour augmenter la lisibilité. L'ordre des paires attribut-valeur est significatif. Aucun attribut vide (un attribut avec une valeur vide) n'est autorisé, sauf si le type d'une valeur d'attribut est . La définition d'objet commence par le

attribut de classe et se termine par la première ligne vide ("\ n \ n"). Aucune ligne vierge n'est autorisée dans l'objet.

La définition d'un objet peut contenir des commentaires. Un commentaire peut être n'importe où dans la définition d'un objet, il commence au premier caractère "#" sur une ligne et se termine au premier caractère de fin de ligne. Un commentaire ne peut pas commencer à la colonne 0. Les caractères d'espace blanc peuvent être utilisés pour améliorer la lisibilité.

Pour plus d'informations sur le format des objets, consultez le document "Bjects et attributs de la base de données AFRINIC".

Chaque partie du message qui n'est pas reconnue en tant qu'objet de base de données est ignorée et le message d'erreur est émis dans l'accusé de réception.

 

2.2 Création, modification et suppression d'un objet 

Pour créer, mettre à jour ou supprimer des objets, un message contenant les objets doit être préparé en suivant les modèles d'objet et envoyé à la base de données pour traitement. Un message peut contenir plusieurs objets, chacun d'eux peut nécessiter une opération différente: création, modification ou suppression.

 

2.2.1 Traitement d'objets 

En règle générale, l'ordre des objets dans le message n'est pas modifié. La base de données traite les objets un par un, il est donc de la responsabilité de l'utilisateur de s'assurer que toutes les références peuvent être résolues. La seule exception est liée à l'utilisation des poignées NIC "AUTO" pour l'attribution automatique d'une valeur pour l'attribut "nic-hdl:" dans les objets person ou role. Dans ce cas, les objets dotés de descripteurs NIC "AUTO" sont traités avant que tout autre objet pouvant les référencer ne soit traité.

Lors du traitement d'un objet, le serveur effectue les vérifications suivantes:

  • Vérifie que la syntaxe d'un objet est correcte.
  • Vérifie que l'objet passe les contrôles d'autorisation.
  • Vérifie que toutes les références peuvent être résolues sans conflits.
  • Vérifie que l'opération ne compromet pas l'intégrité référentielle. Ceci est effectué pour la suppression d'un objet afin de s'assurer qu'il n'est référencé à partir d'aucun autre objet dans la base de données AFRINIC.
  • Vérifie que le handle NIC demandé n'est pas utilisé et peut être alloué. Cette opération est effectuée uniquement pour la création d'objets de personne ou de rôle qui demandent un descripteur de carte réseau particulier.

Si toutes les vérifications ont réussi, le serveur crée l'objet dans la base de données AFRINIC. Si l'une de ces étapes échoue, l'opération échoue pour l'objet. Cela se reflète dans le message d'accusé de réception et, sous certaines conditions, dans les messages de notification.

Une fois que la base de données a fini de traiter l'intégralité du message, un message d'accusé de réception est composé et envoyé à l'expéditeur de la mise à jour d'origine comme spécifié dans le champ "Répondre à:" ou "De:" dans le message de mise à jour, si "Répondre à : "n'a pas été spécifié.

Dans certains cas également, des messages de notification sont envoyés. Veuillez consulter la section Notifications 2.5.2" pour plus d'informations.

 

2.2.2 Création d'un nouvel objet

Si un objet avec les mêmes clés primaires que l'objet dans le message de mise à jour n'existe pas dans la base de données, l'opération supposée est la création d'objet. Pour la création d'objets de personne et de rôle, on peut utiliser des "poignées NIC AUTO", en demandant au serveur d'attribuer automatiquement une poignée NIC. Dans ce cas, la valeur de l'attribut "nic-hdl:" doit être:

nic-hdl: AUTO-1 [ ]

Si la (2 à 4 caractères) sont spécifiés, puis le serveur essaiera de les utiliser pour construire le handle NIC. Si la sont omis, le serveur devinera les initiales de l'attribut "person:" ou "role:".

 

2.2.3 Modification d'un objet existant 

Si un objet avec les mêmes clés primaires que l'objet dans le message de mise à jour existe déjà dans la base de données, l'opération supposée est la modification d'objet. Le serveur compare les anciennes et les nouvelles versions de l'objet et signale une erreur de non-opération si elles sont identiques. Lors de la comparaison des versions, les espaces blancs ne sont pas pris en compte.

 

2.2.4 Supprimer un objet

La suppression de l'objet est demandée en ajoutant un attribut spécial "delete:" à l'objet:

supprimer:

La suppression n'est acceptée que si l'objet du message est exactement le même que celui de la base de données sur le point d'être supprimé. Lors de la comparaison des versions, les espaces blancs ne sont pas pris en compte. En outre, l'opération ne peut pas réussir si l'objet est référencé à partir d'autres objets dans la base de données.

 

2.3 Mises à jour par e-mail 

Un e-mail contenant une mise à jour doit être envoyé à l'adresse e-mail du robot AFRINIC Database: auto-dbm@AFRINIC.net. Après avoir traité le message, un accusé de réception est renvoyé à l'utilisateur, contenant des informations sur les mises à jour d'objets qui ont réussi et celles qui ont échoué, ainsi que la raison de l'échec. Dans certains cas, des messages de notification sont envoyés aux utilisateurs concernés. Veuillez consulter la section 3.5.2 «Notifications» pour plus d'informations.

2.3.1 Prise en charge MIME 

Le logiciel de base de données prend en charge MIME. Cette fonctionnalité est principalement destinée à faciliter la signature cryptographique du message lors de l'utilisation d'agents de messagerie qui placent la signature dans une partie MIME distincte, non incluse dans le corps du message.

Il permet également de définir des étendues d'autorisation dans le message (par exemple des parties où différents mots de passe s'appliquent) et de signer des messages imbriqués qui peuvent être nécessaires dans certaines conditions lors de la mise à jour d'objets dont l'autorisation doit être dérivée de plusieurs parties.

Les règles suivantes s'appliquent lors de la soumission de mises à jour à l'aide de l'encapsulation MIME.

A. Le logiciel reconnaît les en-têtes suivants et les actions appropriées sont prises:

  • multipart / signé
  • multipart / alternative
  • multipart / mixte
  • multipart / inconnu
  • application / signature pgp
  • text / plain

Tous les autres types de contenu sont traités comme texte / simple.

B. Chaque partie MIME est traitée comme un message distinct avec les implications suivantes:

  • Les informations d'autorisation ne sont valides que dans une seule partie, sauf pour le type MAIL-FROM, qui est valable pour tout le message.
  • L'affectation de la poignée AUTO NIC est effectuée uniquement dans une seule partie (voir la section 2.3.2 suivante «Prise en charge de PGP»).

2.3.2 Prise en charge PGP 

La base de données prend en charge les messages signés PGP. Les règles suivantes s'appliquent lors de la soumission de mises à jour à l'aide de ce schéma d'autorisation.

Lorsque vous utilisez l'encapsulation MIME, une partie signée PGP d'un message de mise à jour doit être soumise à l'aide d'un type composite à plusieurs parties / signé. Dans ce cas, la première partie du corps contient le message de mise à jour (qui peut également être un message encapsulé MIME) et le deuxième corps contient une signature PGP encapsulée avec le type discret MIME application / signature pgp. En ce qui concerne l'attribution du handle AUTO NIC, la partie signée PGP est traitée comme un message distinct. Si l'une des signatures échoue dans une partie signée imbriquée, la partie entière est rejetée.

2.3.3 Traitement de la ligne d'objet 

Les trois mots clés valides dans la ligne d'objet d'un message de mise à jour sont NEW, HELP et HOWTO. Utilisez NOUVEAU mot-clé seul si vous souhaitez que la base de données accepte uniquement les nouveaux objets. Les mots clés HOWTO et HELP peuvent être utilisés pour obtenir un texte d'aide contenant des informations sur la façon d'interroger et de mettre à jour la base de données (dans ce cas, le corps du message est ignoré). S'il y a plus d'un mot clé ou s'il n'y a pas de mot clé dans la ligne d'objet, alors toute la ligne d'objet est ignorée.

2.4 Mises à jour à l'aide de l'utilitaire networkupdate 

Aucune encapsulation MIME n'est possible lors de l'utilisation de la mise à jour réseau. Aucune authentification PGP n'est possible lors de l'utilisation de la mise à jour réseau.

2.5 Remerciements et notifications 

2.5.1 Remerciements  

Le traitement de chaque objet valide dans le message de soumission (c'est-à-dire chaque objet dans des parties en texte brut, des parties MIME prises en charge et / ou des parties signées PGP valides) est reflété dans le message d'accusé de réception. Ce message contient des informations indiquant si la création, la modification ou la suppression a réussi ou non. Lorsqu'il y a une partie MIME avec un type non pris en charge dans le message entrant, un avertissement sera ajouté à l'accusé de réception, indiquant que cette partie MIME est ignorée. Le message d'accusé de réception est renvoyé à l'adresse e-mail de l'expéditeur ("Répondre à:" ou "De:", si la première n'est pas spécifiée).

Le message d'accusé de réception commence par l'en-tête du message de mise à jour d'origine sous forme de citation, suivi des résultats des mises à jour effectuées pour chaque objet valide du message.

Le format d'un rapport d'opération réussi est le suivant:

D'ACCORD: [ ]

De

peut être Nouveau, Mettre à jour, Supprimer, selon l'opération effectuée.

est la classe de l'objet qui a été traité.

est la clé primaire de l'objet.

Par exemple :

Mettre à jour OK: [personne] FOO12770-AFRINIC

Les mises à jour ayant échoué sont signalées comme suit:

ÉCHOUÉ: [ ]

suivi du texte de l'objet avec une explication plus détaillée de la cause de l'échec.
Il existe plusieurs raisons pour lesquelles l'opération peut échouer pour l'objet. Elles sont:

  • erreur de syntaxe
    L'objet soumis est syntaxiquement incorrect. Veuillez consulter Annexe A1 pour la description des attributs.
  • violation de l'intégrité référentielle
    Si un objet fait référence à des objets (au moyen des attributs "admin-c:", "tech-c:", "zone-c:", "mnt-by:", etc.) qui n'existent pas dans la base de données, création ou les opérations de modification échoueront. Pour les suppressions, il n'est pas autorisé de supprimer un objet référencé à partir d'un autre objet.
  • échec d'autorisation
    Lorsque les vérifications d'autorisation échouent, l'opération échoue. Veuillez vous référer à la section 2.6 "Protection des données" pour plus d'information.

Notifications 2.5.2 

Il existe trois types de notifications:

  • notifications normales
  • transférer des messages
  • notifications croisées.

2.5.2.1 Notifications normales  

Des notifications normales sont envoyées:

  • lorsqu'un objet avec un attribut "notifier:" est mis à jour. L'attribut "notify:" de l'ancienne version de l'objet est utilisé si l'objet était déjà dans la base de données, et l'attribut "notify:" du nouvel objet est utilisé si l'objet est nouveau.
  • quand un objet qui est maintenu (c'est-à-dire qu'il a un attribut "mnt-by:") est mis à jour et que le ou les responsables ont des attributs "mnt-nfy:". Les boîtes e-mail mentionnées dans les attributs "mnt-nfy:" des responsables concernés doivent être utilisées.
  • Lorsqu'un objet inetnum, route ou domaine est créé dans un espace protégé par un objet moins spécifique (par l'attribut "mnt-lower:" de l'objet).
  • lorsqu'une référence à un objet irt est ajoutée ou supprimée d'un objet inetnum ou inet6num (au moyen de l'attribut "mnt-irt:"), et que l'objet irt contient un ou des attributs "irt-nfy:". Les boîtes de messagerie mentionnées dans les attributs "irt-nfy:" sont utilisées.

2.5.2.2 Transférer des messages 

Lorsqu'une mise à jour ne réussit pas les vérifications d'autorisation, cet objet dans le message de mise à jour est transféré à l'adresse de messagerie spécifiée dans l'attribut "upd-to:" du ou des responsables concernés.

2.5.2.3 Notifications croisées 

Des notifications croisées sont envoyées:

  • lorsqu'un objet d'itinéraire nouveau ou supprimé chevauche un autre objet d'itinéraire. Une notification sera envoyée à l'expéditeur de l'objet d'itinéraire.
  • Lorsqu'un objet d'itinéraire nouveau ou supprimé chevauche un autre objet d'itinéraire doté d'un attribut «cross-nfy:» ou «cross-mnt:». La notification doit être envoyée aux attributs "mnt-nfy:" des responsables mentionnés dans l'attribut "cross-mnt:" et aux attributs "e-mail:" des objets personne et rôle dont le descripteur NIC est mentionné dans le " cross-nfy: "attribut des objets d'itinéraire qui se chevauchent.
  • Lorsqu'un objet route nouveau ou supprimé chevauche un autre objet route dont "origin" est un objet aut-num qui a les attributs "cross-nfy:" ou "cross-mnt:". La notification doit être envoyée aux attributs "mnt-nfy:" des responsables mentionnés dans l'attribut "cross-mnt:" et aux attributs "e-mail:" des objets personne ou rôle dont le descripteur NIC est mentionné dans le " cross-nfy: "attribut de l'objet aut-num.

2.6 Protection des données  

La base de données AFRINIC fournit des mécanismes pour contrôler qui peut apporter des modifications à la base de données et quels changements ils peuvent apporter. La distinction entre "qui" et "quoi" sépare l'authentification de l'autorisation.

  • L'authentification est le moyen de déterminer qui tente d'apporter une modification.
  • L'autorisation est de déterminer si une transaction réussissant un contrôle d'authentification spécifique est autorisée à effectuer une opération donnée.

Différentes parties de la base de données nécessitent différents niveaux de protection. Certaines applications nécessitent une authentification basée sur un cryptage fort. Dans d'autres cas, un cryptage fort peut ne pas être nécessaire ou peut ne pas être légalement disponible. Pour cette raison, plusieurs méthodes d'authentification sont prises en charge par le serveur.

2.6.1 Modèle d'autorisation 

Les objets mntner servent de conteneur pour contenir les filtres d'authentification. Une référence à un responsable dans un autre objet définit l'autorisation d'effectuer des opérations sur l'objet ou sur un ensemble d'objets associés. Cette référence est fournie au moyen des attributs "mnt-by:", "mnt-lower:", "mnt-routes:" et "mbrs-by-ref:". Le responsable contient un ou plusieurs attributs "auth:". Chaque attribut "auth:" commence par un mot clé identifiant la méthode d'authentification suivi des informations d'authentification nécessaires pour appliquer cette méthode.

Lors de la soumission d'une mise à jour nécessitant l'autorisation d'un mntner, les informations d'authentification valides pour ce mntner doivent être fournies. Différentes méthodes nécessitent des informations d'authentification différentes, comme indiqué ci-dessous.

Les méthodes d'authentification actuellement prises en charge sont les suivantes:

Méthode / description

NONE

Aucune vérification d'autorisation n'est effectuée.

COURRIER DE*

Il s'agit d'un contrôle d'authentification très faible et déconseillé. Les informations d'authentification sont une expression régulière sur des caractères ASCII. Le responsable est authentifié si le champ "De:" des en-têtes de courrier RFC 822 correspond à cette expression régulière. Comme la falsification des en-têtes de courrier est assez facile, il s'agit d'une forme d'authentification très faible.

CRYPTE-PW

Il s'agit d'une forme d'authentification relativement faible. Les informations d'authentification sont un mot de passe crypté fixe au format cryptage UNIX. Le responsable est authentifié si la transaction contient le mot de passe en texte clair du responsable. Le mot de passe étant en texte clair dans les transactions, il peut être capturé par espionnage. La forme cryptée du mot de passe n'est plus affichée dans la sortie d'une requête, afin de le protéger des attaques de devinettes de mot de passe. Les informations d'authentification sont fournies à l'aide d'un pseudo-attribut "mot de passe:". La valeur de cet attribut est un mot de passe en texte clair. Il peut apparaître n'importe où dans le corps du message, mais pas dans les en-têtes de courrier. La continuation de ligne n'est pas autorisée pour cet attribut.

MD5-PW

Ce schéma est basé sur l'algorithme de hachage MD5 et fournit une authentification plus forte que CRYPT-PW. Les informations d'authentification stockées dans la base de données sont une phrase de passe chiffrée à l'aide de l'algorithme md5-crypt, qui est une concaténation de la chaîne "$ 1 $", du salt et de la sortie de hachage de 128 bits. Parce qu'il utilise un sel de 8 caractères et une phrase de passe presque illimitée, ce schéma est plus stable contre les attaques par dictionnaire. La forme cryptée du mot de passe est filtrée de whois sortie de requête pour le protéger des attaques de cracking. Les informations d'authentification sont fournies à l'aide d'un pseudo-attribut "password:". La valeur de cet attribut est une phrase secrète en texte clair. Il peut apparaître n'importe où dans le corps du message, mais pas dans les en-têtes de courrier. La continuation de ligne n'est pas autorisée pour cet attribut, l'attribut et la phrase de passe doivent tenir sur une seule ligne. Si la clé est divisée sur plusieurs lignes, cela sera traité comme une erreur de syntaxe.

CLÉ PGP

Forme d'authentification forte. Les informations d'authentification sont une identité de signature pointant vers un certificat de clé publique, qui est stocké dans un objet séparé. Le responsable est authentifié si la transaction est signée par la clé privée correspondante. AFRINIC ne garantit pas qu'une clé appartient à une entité spécifique; ce n'est pas une autorité de certification. Tout le monde peut fournir à la base de données toutes les clés publiques avec toutes les informations de propriété et ces clés peuvent être utilisées pour protéger d'autres objets en vérifiant que la mise à jour provient de quelqu'un qui connaît la clé secrète correspondante.

* Le schéma d'authentification MAIL-FROM n'est pas valide dans la base de données AFRINIC.

2.6.2 Protection des objets individuels  

Les objets individuels peuvent être protégés avec un objet mntner. Le mntner est référencé par l'attribut "mnt-by:" dans l'objet. Le type d'attribut est multiple, de sorte que plusieurs partenaires peuvent protéger l'objet. Seuls les partenaires référencés par les attributs "mnt-by:" sont autorisés à modifier ou supprimer l'objet. Notez que les vérifications d'authentification sont OR-ed, donc si au moins un mntner est authentifié, l'opération est autorisée. Cela signifie que la protection d'objet est aussi faible que la méthode d'authentification la plus faible utilisée dans les partenaires référencés par l'objet. Lorsque l'attribut "mnt-by:" est ajouté à un objet pour la première fois (dans le cadre de la création ou de la modification d'un objet), l'opération doit réussir les vérifications d'authentification pour le ou les mntner référencés par cet attribut.

2.6.3 Protection de l'espace objet aut-num 

La protection de l'espace objet aut-num se fait à l'aide d'une classe as-block. Le mntner qui autorise la création d'objets as-block ou d'objets aut-num plus spécifiques est spécifié par l'attribut "mnt-lower:" de l'objet as-block. Si aucun attribut "mnt-lower:" n'est spécifié, l'attribut "mnt-by:" est utilisé.

2.6.4 Protection de l'espace d'adressage 

Les allocations et affectations d'espace d'adressage sont représentées par les objets inetnum et inet6num. L'attribut "mnt-lower:" est utilisé pour référencer un mntner qui autorise la création d'objets inetnum ou inet6num plus spécifiques. Si aucun attribut "mnt-lower:" n'est spécifié, l'espace d'adressage n'est pas protégé.

2.6.5 Protection des objets avec des noms hiérarchiques 

De nombreux objets RPSL n'ont pas de hiérarchie naturelle mais autorisent des noms hiérarchiques. Quelques exemples sont les types d'objet as-set et route-set. Un ensemble as peut avoir un nom ne correspondant à aucune hiérarchie de nommage tel que "AS-Foo" ou il peut avoir un nom hiérarchique de la forme "AS1: AS-BAR". Lorsqu'un nom hiérarchique n'est pas utilisé, l'autorisation pour des objets tels que as-set et route-set correspond aux règles pour les objets individuels décrites dans la section 3.6.2 "Protection des objets individuels". 

Si des noms hiérarchiques sont utilisés, l'ajout d'un objet doit être autorisé par l'objet dont la clé est nommée par tout à gauche du deux-points le plus à droite dans le nom de l'objet ajouté.

L'autorisation est déterminée en utilisant d'abord la référence du responsable "mnt-lower:" ou, en cas d'absence, en utilisant la référence "mnt-by:".

2.6.6 Protection de l'espace objet du domaine 

La protection de l'espace objet du domaine se fait avec l'attribut "mnt-lower:". Lorsqu'il est utilisé dans l'objet domaine, cet attribut fait référence au mntner qui autorise la création d'objets de domaine directement en dessous dans l'arborescence de domaine enregistrée dans la base de données AFRINIC. Par exemple, un objet de domaine de premier niveau (ccTLD) protège la création des objets de domaine de deuxième niveau, des objets de domaine de troisième niveau s'il n'y a pas d'objet de domaine de deuxième niveau correspondant, etc. Notez que l'objet de domaine de premier niveau ( ccTLD ou gTLD) ne peuvent pas être créés dans la base de données AFRINIC par les utilisateurs, uniquement par l'administrateur de la base de données.

2.6.7 Protéger l'appartenance à un ensemble 

Lorsque l'appartenance à un ensemble est spécifiée via l'utilisation de l'attribut "membre de:", le serveur vérifie la validité de l'appartenance lors de la création ou de la mise à jour d'un objet-membre. Cet attribut "membre de:" peut être utilisé dans les classes route, aut-num et inet-rtr. La valeur de l'attribut "member-of:" identifie un objet défini dont cet objet veut être membre.

Cependant, spécifier "membre de:" ne suffit pas. L'objet set doit également avoir un attribut "mbrs-by-ref:" listant le mainteneur de l'objet voulant être membre de l'ensemble. C'est-à-dire que le propriétaire de l'ensemble doit valider la revendication d'appartenance d'un objet avec un attribut "member-of:", et il le fait en faisant correspondre la ligne mnt-by de l'objet avec l'un des responsables du "mbrs-by-" ref: "attribut de l'objet défini. Si la revendication n'est pas valide au moment où le serveur crée ou modifie un membre d'objet (route, aut-num ou inet-rtr), l'opération échoue. Si l'attribut "mbrs-by-ref:" est manquant, l'ensemble est défini explicitement par l'attribut "members:".

3.0 Mise en miroir de la base de données AFRINIC 

La mise en miroir en temps quasi réel (NRTM) est un mécanisme qui permet whois les serveurs, autres que le serveur principal pour une base de données donnée, pour avoir une copie à jour de toutes les données du serveur principal en obtenant des modifications au fur et à mesure qu'elles sont traitées par le serveur principal.

Périodiquement (défini par la configuration, généralement toutes les 15 minutes environ), le serveur distant se connecte au serveur principal et demande toutes les modifications qui ont été traitées depuis la dernière connexion. Lorsque toutes les données sont récupérées, la connexion est fermée, jusqu'à ce qu'il soit temps pour une nouvelle connexion.

Dans la base de données AFRINIC, le serveur NRTM écoute sur un port différent du whois port (43).

Le NomComXNUMX de l'AFRINIC whois Le serveur génère un numéro de séquence chaque fois qu'il traite une mise à jour dans la base de données. Dans le but de générer ces numéros de série, le serveur décrit toutes les modifications apportées à la base de données en termes de deux opérations atomiques: suppression et ajout.

Lors de l'envoi de données à un serveur miroir, le serveur principal enverra l'une des deux chaînes (ADD ou DELETE) suivies de deux caractères de nouvelle ligne et de l'objet correspondant (soit l'objet tel qu'il était avant la suppression ou l'objet tel qu'il doit être ajouté ou modifié ). Si la chaîne "ADD" est suivie d'un objet déjà existant dans la base de données, alors cette opération est considérée comme une modification. La mise en miroir en temps quasi réel est demandée avec l'indicateur "-g". Les arguments de ce drapeau sont:

-g <source>: : -

De

* est la chaîne qui identifie la base de données (par exemple AFRINIC).

* une version du protocole de mise en miroir que le prend en charge (2 pour AFRINIC).

* est le numéro de série le plus bas demandé.

* est le numéro de série le plus récent demandé ou le mot-clé LAST qui indique au serveur principal d'envoyer toutes les mises à jour jusqu'à la plus récente disponible au moment de la requête. Notez que le serveur ne fournira jamais le dernier objet traité ou affichera qu'il est disponible pour la mise en miroir. Ceci est fait pour protéger les serveurs secondaires au cas où la dernière mise à jour provoquerait une corruption de la base de données et une panne du serveur.

Un client peut demander une connexion persistante en incluant l'indicateur "-k" avec une demande de mise en miroir (requête "-g"). Dans ce cas, le dernier argument est ignoré et les nouveaux objets sont fournis par le serveur dès qu'ils sont traités. Le client est responsable de la fermeture de la connexion.

L'indicateur "-q sources" peut être utilisé avec le serveur miroir pour récupérer des informations concernant les possibilités de mise en miroir disponibles. Veuillez consulter la section 2.9 «Autres fonctionnalités du serveur» pour plus de détails.

Notez que le serveur ne retourne jamais la dernière série en cas de demande de mise en miroir. Ainsi, si la dernière série provoque un crash du serveur et une corruption de la base de données, elle ne se propage jamais aux serveurs secondaires. La dernière série n'est pas affichée avec la requête "-q sources" également.

Au début du flux de données, le serveur principal enverra la chaîne suivante:

Version% START: NRTM_Protocol_version_ # source avant-dernier

Par exemple:% START Version: 2 AFRINIC: 1539595-1539597

Une fois la dernière donnée envoyée au serveur miroir, le serveur principal enverra la chaîne:

Source% END pour signaler la fin de la transmission.

Par exemple :

% FIN AFRINIC