Aller au contenu principal

6. SUPPORT SERVICES (Services de support)

Cette section discute de trois catégories de services de support : Traduction de noms de domaine, Initialisation d'hôte et Gestion à distance.

6.1 DOMAIN NAME TRANSLATION (Traduction de noms de domaine)​

6.1.1 Introduction​

Le système de noms de domaine (DNS) est un système de base de données distribué pour traduire les noms d'hôtes en adresses IP et vice versa. DNS est essentiel pour le fonctionnement d'Internet.

Chaque hôte Internet DOIT implémenter un résolveur DNS (MUST) pour interroger les serveurs DNS pour la résolution de noms.

6.1.2 Protocol Walk-Through (Parcours du protocole)​

DNS fonctionne sur un modèle client-serveur :

  • Résolveur: Client qui interroge les serveurs DNS
  • Serveur de noms: Serveur qui répond aux requêtes DNS

Format de message DNS​

Les messages DNS se composent de :

  • En-tête: Contient les indicateurs de requête/réponse et les compteurs
  • Section Question: Contient la requête
  • Section Réponse: Contient les enregistrements de ressources répondant à la requête
  • Section Autorité: Contient les enregistrements NS pour les serveurs faisant autorité
  • Section Additionnelle: Contient des enregistrements supplémentaires utiles

Types d'enregistrements de ressources​

Les types d'enregistrements de ressources (RR) DNS courants incluent :

  • A: Adresse IPv4
  • AAAA: Adresse IPv6
  • CNAME: Nom canonique (alias)
  • MX: Échangeur de courrier
  • NS: Serveur de noms
  • PTR: Pointeur (recherche inversée)
  • SOA: Début d'autorité
  • TXT: Chaînes de texte

6.1.3 Specific Issues (Problèmes spécifiques)​

6.1.3.1 Resource Record Caching (Mise en cache des enregistrements)​

Un résolveur DNS DEVRAIT mettre en cache les enregistrements de ressources (SHOULD) selon leurs valeurs de durée de vie (TTL). Le résolveur DOIT respecter les valeurs TTL (MUST).

6.1.3.2 Negative Caching (Mise en cache négative)​

Un résolveur DEVRAIT implémenter la mise en cache négative (SHOULD) pour mettre en cache les informations sur les noms de domaine ou enregistrements de ressources inexistants.

6.1.3.3 Multiple Addresses (Adresses multiples)​

Lorsqu'une requête DNS renvoie plusieurs adresses, le résolveur DEVRAIT essayer toutes les adresses si la première connexion échoue (SHOULD).

6.1.3.4 CNAME Records (Enregistrements CNAME)​

Un résolveur DOIT gérer correctement les enregistrements CNAME (MUST) en suivant la chaîne CNAME pour obtenir l'adresse réelle.

6.1.4 DNS Requirements Summary (Résumé des exigences DNS)​

FonctionnalitéSectionMUSTSHOULDMAYRemarque
Implémenter un résolveur DNS6.1.1✓
Mettre en cache les enregistrements6.1.3.1✓
Respecter les valeurs TTL6.1.3.1✓
Implémenter mise en cache négative6.1.3.2✓
Gérer les enregistrements CNAME6.1.3.4✓
Essayer plusieurs adresses6.1.3.3✓

6.2 HOST INITIALIZATION (Initialisation d'hôte)​

6.2.1 Introduction​

L'initialisation d'hôte fait référence au processus par lequel un hôte obtient ses paramètres de configuration au démarrage. Les protocoles courants pour l'initialisation d'hôte incluent :

  • BOOTP: Protocole Bootstrap
  • DHCP: Protocole de configuration dynamique d'hôte
  • RARP: ARP inversé

6.2.2 Protocol Walk-Through (Parcours du protocole)​

BOOTP/DHCP​

BOOTP et DHCP permettent à un hôte de découvrir son adresse IP, son masque de sous-réseau, sa passerelle par défaut et d'autres paramètres de configuration à partir d'un serveur.

Le processus implique généralement :

  1. Découverte: Le client diffuse un message de découverte
  2. Offre: Le serveur offre des paramètres de configuration
  3. Demande: Le client demande des paramètres spécifiques
  4. Accusé de réception: Le serveur confirme la configuration

6.2.3 Specific Issues (Problèmes spécifiques)​

6.2.3.1 Configuration Parameters (Paramètres de configuration)​

Un protocole d'initialisation d'hôte DEVRAIT fournir au moins les paramètres suivants (SHOULD) :

  • Adresse IP
  • Masque de sous-réseau
  • Passerelle par défaut
  • Adresses de serveur DNS

6.2.3.2 Lease Time (Durée de bail)​

Pour les protocoles comme DHCP qui utilisent des adresses louées, le client DOIT respecter la durée de bail (MUST) et renouveler le bail avant expiration.

6.2.4 Initialization Requirements Summary (Résumé des exigences d'initialisation)​

FonctionnalitéSectionMUSTSHOULDMAYRemarque
Supporter BOOTP/DHCP6.2.1✓
Fournir paramètres de base6.2.3.1✓
Respecter la durée de bail6.2.3.2✓

6.3 REMOTE MANAGEMENT (Gestion à distance)​

6.3.1 Introduction​

Les protocoles de gestion à distance permettent aux administrateurs réseau de surveiller et gérer les hôtes Internet à distance. Le protocole principal pour la gestion à distance est :

  • SNMP: Protocole simple de gestion de réseau

6.3.2 Protocol Walk-Through (Parcours du protocole)​

SNMP utilise un modèle gestionnaire-agent :

  • Gestionnaire: Station de gestion qui interroge les agents
  • Agent: Logiciel s'exécutant sur les périphériques gérés qui répond aux requêtes

Opérations SNMP​

  • GET: Récupérer une variable de gestion
  • GET-NEXT: Récupérer la variable de gestion suivante
  • SET: Modifier une variable de gestion
  • TRAP: Notification asynchrone de l'agent au gestionnaire

Base d'informations de gestion (MIB)​

La MIB définit la structure et la sémantique des informations de gestion. Chaque objet gérable est identifié par un identifiant d'objet (OID).

6.3.3 Specific Issues (Problèmes spécifiques)​

6.3.3.1 SNMP Implementation (Implémentation SNMP)​

Un hôte PEUT implémenter un agent SNMP (MAY). S'il est implémenté, l'agent DEVRAIT supporter au moins MIB-II (SHOULD).

6.3.3.2 Security (Sécurité)​

Les implémentations SNMP DEVRAIENT implémenter le contrôle d'accès basé sur la communauté (SHOULD). Pour SNMPv3, les implémentations DEVRAIENT supporter l'authentification et le chiffrement (SHOULD).

6.3.4 Management Requirements Summary (Résumé des exigences de gestion)​

FonctionnalitéSectionMUSTSHOULDMAYRemarque
Implémenter un agent SNMP6.3.3.1✓
Supporter MIB-II6.3.3.1✓
Implémenter contrôle d'accès6.3.3.2✓
Dernière mise à jour le