Remarques :

• Ce tutoriel nécessite un accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, reportez-vous à Introduction à Oracle Cloud Infrastructure Free Tier.
• Il utilise des exemples de valeurs pour les informations d'identification, la location et les compartiments Oracle Cloud Infrastructure. Lorsque vous terminez votre atelier, remplacez ces valeurs par celles propres à votre environnement cloud.

Implémenter la haute disponibilité sur le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure

Introduction

OraStage est une entreprise leader dans le secteur de l'énergie, spécialisée dans les solutions d'énergies renouvelables et les technologies énergétiques innovantes, elle a annoncé une décision stratégique de migrer ses workloads vers Oracle Cloud Infrastructure (OCI) pour améliorer les performances, l'évolutivité et la sécurité.

Compte tenu des besoins et conditions spécifiques décrits par OraStage, l'entreprise a besoin d'un système de noms de domaine (DNS) hybride. La solution dans le cloud et hybride ici signifie utiliser leur propre système DNS de domaine de noms Internet Berkeley version 9 (BIND9) en plus du service DNS OCI, où l'architecture finale qu'ils cherchent à créer est présentée dans l'image suivante.

OraStage Exigences relatives au DNS :

• L'entreprise dispose de plusieurs domaines et sous-domaines internes, qui doivent tous être résolus par leur DNS BIND9 dans OCI, où OraStage gérera toutes les zones et tous les enregistrements associés. L'un de ces domaines est orastage.com que nous allons utiliser dans ce tutoriel. Par conséquent, toute requête vers orastage.com doit être transmise à son répertoire BIND9.

• Ils doivent encore résoudre les domaines natifs OCI (oraclevcn.com, oraclecloud.com, etc.) dans certains cas, ce qui sera fait à l'aide des composants DNS privés OCI : vues privées, transmission des adresses et des règles, et adresses d'écoute.

• Toutes les requêtes doivent être inspectées par une instance de pare-feu pfSense.

• Pour éviter un point d'échec unique, OraStage prévoit d'utiliser un autre serveur DNS et d'utiliser OCI Load Balancer pour distribuer les requêtes entre le DNS principal et le DNS secondaire.

Cette série de tutoriels vous guidera pas à pas pour répondre aux exigences décrites ci-dessus et créer la solution complète à partir de zéro. Vous pouvez facilement accéder à chaque tutoriel à partir de la liste ci-dessous :

• Tutoriel 1 : Configuration du DNS BIND9 dans OCI. Découvrez comment installer et configurer BIND9 sur une instance de calcul, ce qui en fait le serveur DNS local pour deux environnements de test dans OCI. Ces environnements seront composés de serveurs "Frontend" et "Backend", chacun hébergé dans un réseau satellite distinct. Le serveur BIND9 traitera toutes les requêtes DNS dirigées vers orastage.com.

• Tutoriel 2 : Implémentation de la haute disponibilité sur le scénario DNS BIND9 dans OCI. Ce tutoriel se concentre sur l'ajout d'un serveur BIND9 secondaire et la configuration d'un équilibreur de charge réseau (NLB) pour distribuer le trafic DNS entre les deux serveurs. Les requêtes DNS vers orastage.com seront dirigées vers l'adresse IP de l'équilibreur de charge réseau, qui équilibrera la charge entre les serveurs BIND9 principal et secondaire. Si un serveur devient indisponible, la résolution DNS se poursuit sans interruption de service.

• Tutoriel 3 : Utilisation d'OCI DNS pour résoudre des domaines natifs. Se concentrer uniquement sur un cas d'emploi spécifique, dans lequel nous utilisons des composants DNS natifs dans OCI, au cas où il serait nécessaire de résoudre des domaines natifs tels que oraclevcn.com et oraclecloud.com. BIND9 DNS n'est pas utilisé dans ce tutoriel.

• Tutoriel 4 : Ajout de la sécurité à l'architecture DNS à l'aide du pare-feu pfSense. Se concentrer sur l'installation d'un pare-feu pfSense dans le VCN hub dans OCI et effectuer la configuration réseau requise pour acheminer tout le trafic Est-Ouest, y compris les requêtes DNS (effectuées dans les tutoriels précédents) via le pare-feu à inspecter.

Présentation

Aujourd'hui, une infrastructure DNS fiable et efficace est essentielle pour garantir des opérations réseau transparentes. Dans le premier tutoriel : Configuration du système de noms de domaine BIND9 dans Oracle Cloud Infrastructure, nous avons déjà expliqué comment BIND9, l'un des logiciels DNS les plus utilisés, qui fournit des fonctionnalités robustes et une flexibilité pour gérer les services DNS, peut être déployé et utilisé dans OCI. Bien qu'un seul serveur BIND9 puisse gérer efficacement les demandes DNS, l'ajout d'un second serveur BIND9 offre de nombreux avantages qui améliorent les performances et la fiabilité globales de votre réseau.

Ce tutoriel vous guidera tout au long du processus de configuration d'un serveur BIND9 secondaire et d'un équilibreur de charge dans OCI, en mettant en évidence les avantages de cette configuration. En implémentant ceci, vous obtiendrez :

• Redondance : garantie de la disponibilité continue des services DNS, même en cas de panne du serveur principal.

• Equilibrage de charge : distribution de la charge des requêtes DNS entre les serveurs, ce qui améliore les temps de réponse et réduit le risque de surcharge.

• Distribution géographique : si nécessaire, le fait de placer des serveurs DNS à différents emplacements peut offrir des temps de réponse plus rapides aux utilisateurs globaux.

• Sécurité renforcée : réduire les risques en séparant et en sécurisant les services DNS sur plusieurs serveurs.

OCI Network Load Balancer

Un équilibreur de charge réseau flexible OCI (NLB) est un service qui aide à répartir le trafic entrant sur plusieurs ressources back-end. Cela est particulièrement utile pour gérer les volumes de trafic élevés et s'assurer que les applications restent disponibles et réactives même en cas de défaillance d'un ou de plusieurs serveurs.

L'équilibreur de charge réseau OCI fonctionne sur les couches 3 et 4 du modèle OSI (Open Systems Interconnection), gérant des protocoles tels que TCP (Transmission Control Protocol), UDP (User Datagram Protocol) et ICMP (Internet Control Message Protocol). En équilibrant efficacement la charge, il peut améliorer les performances des applications, fournir une haute disponibilité et améliorer l'évolutivité globale du système. Le service propose également des fonctionnalités telles que des vérifications de l'état pour surveiller le statut des serveurs back-end, garantissant ainsi que le trafic est uniquement dirigé vers des instances opérationnelles et en bon état.

En résumé, un équilibreur de charge réseau OCI joue un rôle clé dans le maintien de la fiabilité et de l'évolutivité des applications en répartissant intelligemment le trafic réseau entre plusieurs ressources. En raison de tous les avantages que nous avons mentionnés, nous allons ajouter un équilibreur de charge réseau à notre configuration pour optimiser notre solution DNS.

Objectifs

• Déployez OCI Network Load Balancer et un serveur BIND9 secondaire dans OCI intégré de manière transparente à votre réseau, garantissant ainsi une infrastructure DNS robuste et résiliente.

• L'objectif principal de ce tutoriel est d'autoriser le client FE-VM (fe.orastage.com) à interroger BE-VM (be.orastage.com), et inversement, avec DNS-NLB distribuant les demandes client entre Primary-DNS (primary-dns.orastage.com) et Secondary-DNS (secondary-dns.orastage.com) pour répondre à toutes les requêtes.

Architecture finale

Prérequis

• Accès à une location OCI et droits d'accès permettant de gérer le réseau et les services de calcul requis.

• Compréhension de base du routage et de la sécurité du réseau OCI et de leurs fonctionnalités : réseau cloud virtuel (VCN), table de routage, passerelle de routage dynamique (DRG), liste de sécurité, bastion et équilibreur de charge réseau OCI.

• Compréhension de base du service OCI Logging.

• Compréhension de base d'Ubuntu Linux et DNS en général.

• Veillez à suivre le premier tutoriel : Configurez le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure, où vous devez déjà avoir créé l'architecture suivante.

  

Tâche 1 : provisionnement de l'instance DNS secondaire et configuration de BIND9

Reportez-vous au premier tutoriel : Configuration du système de noms de domaine BIND9 dans Oracle Cloud Infrastructure, où les tâches 2 et 3 indiquent la création et la configuration de l'instance DNS principal, les mêmes tâches doivent être effectuées pour configurer le DNS secondaire. Tenez compte des informations suivantes :

• Le nom de l'instance est Secondary-DNS.

• Il réside dans le même sous-réseau que le DNS principal et une adresse IP de 10.0.0.20 doit lui être affectée.

• Par le biais du processus de configuration, chaque fois que DNS principal 10.0.0.10 est mentionné, il doit être remplacé par DNS secondaire 10.0.0.20, le nom de domaine qualifié complet de cette instance doit être secondary-dns.orastage.com.

• Utilisez la même clé SSH.

• Le même bastion OCI utilisé pour accéder à DNS principal peut également être utilisé pour accéder au DNS secondaire, mais à l'aide d'une nouvelle session.

• Dans le fichier /var/lib/bind/db.orastage.com pour les instances principale et secondaire, assurez-vous que tous les enregistrements suivants sont présents afin que les deux serveurs DNS puissent se résoudre mutuellement en plus des instances FE-VM et BE-VM.

  primary-dns                 IN  A       10.0.0.10
  secondary-dns               IN  A       10.0.0.20
  fe                          IN  A       10.1.0.5
  be                          IN  A       10.2.0.5
  

A la fin de cette tâche, l'architecture doit se présenter comme suit :

Tâche 2 : configuration d'un équilibreur de charge réseau OCI

Tâche 2.1 : Ajouter des détails

• Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Fonctions de réseau.
  2. Cliquez sur équilibreur de charge réseau.

  

• Cliquez sur Créer un équilibreur de charge réseau.

  

  1. Nom de l'équilibreur de charge : entrez un nom.
  2. Choisir le type de visibilité : sélectionnez Privé.
  3. Choisir la mise en réseau : sélectionnez DNS-VCN et son sous-réseau privé, où nous allons placer l'équilibreur de charge réseau.
  4. Fournissez les informations relatives au jeu de transport, puis cliquez sur Suivant.

  

  

Tâche 2.2 : configurer un processus d'écoute

Un processus d'écoute est un composant essentiel d'un équilibreur de charge qui est chargé de recevoir un type spécifique de trafic avec certains ports (par exemple, TCP/port 80, UDP/port 21) et de le diriger vers des serveurs back-end. Dans ce tutoriel, nous voulons que le processus d'écoute écoute sur le port 53 (TCP) et (UDP), car le DNS les utilise tous les deux.

• Saisissez les informations suivantes .

  1. Nom du processus d'écoute : Entrez un nom.
  2. Indiquer le type de trafic géré par le processus d'écoute : sélectionnez UDP/TCP.
  3. Indiquer le port : entrez le numéro de port 53.
  4. Fournissez les informations relatives au jeu de transport, puis cliquez sur Suivant.

  

Tâche 2.3 : choisir un ensemble de back-ends

Un ensemble de back-ends est un regroupement logique de serveurs back-end vers lesquels l'équilibreur de charge réseau achemine le trafic. Nos serveurs back-end seront DNS principal et DNS secondaire.

• Saisissez les informations suivantes .

  1. Nom d'ensemble de back-ends : entrez un nom d'ensemble de back-ends.
  2. Cliquez sur Ajouter des backends.
  3. Type de back-end : sélectionnez Instances de calcul.
  4. Instances de calcul IPv4 de back-end : choisissez les deux serveurs DNS : DNS principal et DNS secondaire.
  5. Cliquez sur Ajouter des backends.
  6. Vous pouvez voir que les serveurs back-end sont ajoutés à l'ensemble.
  7. Indiquer une stratégie de vérification de l'état : une stratégie de vérification de l'état est utilisée pour vérifier la disponibilité des serveurs back-end en effectuant des demandes ou en tentant des connexions. L'équilibreur de charge réseau effectue ces vérifications de l'état à intervalles réguliers indiqués, en utilisant cette stratégie pour surveiller en permanence le statut des serveurs back-end.
  8. Fournissez les informations relatives au jeu de transport, puis cliquez sur Suivant.

  

  

  

  

Tâche 2.4 : Vérifier et créer

• Vérifiez tous les détails et cliquez sur Créer un équilibreur de charge réseau.

  

• DNS-NLB est créé. Notez l'adresse IP privée telle que nous l'utiliserons dans la tâche 3.

  

Tâche 2.5 : Ajouter une règle de sécurité

Pour éviter l'échec de la vérification de l'état et pour assurer une communication fluide sans interruption du trafic.

• Ajoutez les règles suivantes dans la liste de sécurité DNS-Private-Subnet, ce qui autorise le trafic DNS envoyé à partir de l'équilibreur de charge réseau vers ses back-ends.

  

• L'architecture doit se présenter comme indiqué dans l'image suivante.

  

Tâche 3 : configuration des règles de transfert DNS OCI

Tâche 3.1 : configuration de la règle de transfert Frontend-VCN

• Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Fonctions de réseau.
  2. Cliquez sur Réseaux cloud virtuels.

  

• Cliquez sur Frontend-VCN.

  

• Cliquez sur Résolveur DNS du VCN.

  

• Défiler vers le bas

  1. Cliquez sur Règles.
  2. Cliquez sur Gérer les règles.
  3. Remplacez l'adresse IP de destination de l'adresse IP Primary-DNS par l'adresse IP DNS-NLB (10.0.0.110) créée dans la tâche 2.
  4. Cliquez sur Enregistrer les modifications.
  5. La adresse IP de destination a été modifiée. Toutes les requêtes de FE-VM sont donc transmises à l'adresse IP DNS-NLB, qui les répartit entre les serveurs DNS principal et secondaire.

  

  

  

Tâche 3.2 : configuration de la règle de transfert du back-end VCN

• Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Fonctions de réseau.
  2. Cliquez sur Réseaux cloud virtuels.

  

• Cliquez sur VCN de back-end.

  

• Cliquez sur Résolveur DNS du VCN.

  

• Défiler vers le bas.

  1. Cliquez sur Règles.
  2. Cliquez sur Gérer les règles.
  3. Remplacez l'adresse IP de destination de l'adresse IP Primary-DNS par l'adresse IP DNS-NLB (10.0.0.110) créée dans la tâche 2.
  4. Cliquez sur Enregistrer les modifications.
  5. La adresse IP de destination a été modifiée. Toutes les requêtes de BE-VM sont donc transmises à l'adresse IP DNS-NLB, qui les répartit entre les serveurs DNS principal et secondaire.

  

  

  

Tâche 4 : tester et valider

Prérequis

• Activer les journaux : pour vérifier le flux de trafic, nous activerons les journaux de flux de sous-réseau, ce qui nous permet de surveiller et de suivre le trafic réseau entrant ou sortant d'un sous-réseau spécifique. Ces journaux capturent des détails sur le trafic réseau, tels que les adresses IP source et de destination, les numéros de port et la quantité de données transmises. Pour activer le journal, procédez comme suit :

  1. Accédez au sous-réseau privé DNS-VCN, où résident Primary-DNS, Secondary-DNS et DNS-NLB.
  2. Cliquez sur Journaux.
  3. Sélectionnez Activer le journal.

  

  Pour plus d'informations sur les journaux et leur utilisation dans OCI, reportez-vous à

  • Journaux de flux de réseau cloud virtuel.
  • Détails des journaux de flux VCN - Découvrez comment lire le contenu du journal.
  • Suivre les paquets dans une architecture de routage VCN Hub et Spoke dans OCI - Un tutoriel utile pour savoir comment suivre les paquets réseau dans un environnement OCI à l'aide de plusieurs méthodes, telles que la capture de paquets de pare-feu, les journaux de sous-réseau et TCPdump. Suivez les tâches 6 et 13.
    • Tâche 6 : activer la journalisation (tous les journaux) sur le satellite d'un sous-réseau privé.
    • Tâche 13 : examinez tous les points de journalisation et toutes les captures de paquets et suivez le chemin - Point de journalisation B.

Désormais, tout le trafic entrant et sortant de ce sous-réseau sera journalisé.

Scénario de test 1 : le DNS principal répond aux requêtes FE-VM lorsque le DNS secondaire est arrêté

En cas de panne dans le DNS secondaire, nous devons nous assurer que le DNS principal répond aux requêtes provenant de FE-VM, car le DNS-NLB y dirige le trafic.

• L'image suivante illustre le scénario de test que nous voulons atteindre.

  

• Actuellement, toutes les instances sont en fonctionnement. Commençons par arrêter l'instance Secondary-DNS. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Calculer.
  2. Cliquez sur Instances.

  

  1. Cochez la case en regard de l'instance.
  2. Cliquez sur Actions.
  3. Cliquez sur Arrêter.
  4. Cliquez sur Arrêter.
  5. L'instance est maintenant à l'état Arrêté.

  

  

  

• Accédez à FE-VM et effectuez un test en exécutant une requête. Pour ce faire, nous utiliserons le service OCI Bastion. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Identité et sécurité.
  2. Cliquez sur Bastion.

  

• Cliquez sur FEBastion.

  

• Cliquez sur Créer une session.

  

• Saisissez les informations suivantes .

  1. Type de session : sélectionnez Session SSH gérée.
  2. Nom de session : entrez le nom de la session.
  3. Nom utilisateur : Entrez le nom utilisateur. Pour l'instance Oracle Linux, le nom utilisateur par défaut est opc.
  4. Instance de calcul : sélectionnez l'instance FE-VM.
  5. Collez la même clé publique générée dans le tutoriel 1 : Tâche 2.1 : générer la paire de clés SSH.
  6. Cliquez sur Créer une session.

  

  

• Une fois la session créée, cliquez sur les trois points et sur Copier la commande SSH.

  

  La commande doit se présenter comme suit :

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-mi[e-mail]" -p 22 opc@10.1.0.5
  

• Ouvrez OCI Cloud Shell.

  1. Accédez au répertoire .ssh à l'aide de la commande cd .ssh.
  2. Collez la commande SSH. Veillez à remplacer <privateKey> par le nom de fichier de clé privée id_rsa.
  3. Saisissez yes.

  

• Connexion réussie Exécutez à présent une requête de test de FE-VM vers be.orastage.com à l'aide de la commande host. Vérifiez que la requête a réussi et qu'une réponse a été reçue.

  

• Nous savons qu'il n'existe qu'un seul serveur back-end en bon état pour gérer la demande, à savoir DNS principal. Nous allons donc vérifier le flux de la requête DNS et voir quel serveur a répondu à cette requête à l'aide des journaux de sous-réseau OCI.

  1. Cliquez sur le journal.
  2. La demande est passée de l'adresse de transfert (10.1.0.6) qui est placée dans le même sous-réseau que FE-VM à l'adresse IP NLB (10.0.0.110) dans le DNS-VCN.
  3. Ensuite, à partir de l'adresse IP NLB (10.0.0.110), la demande est envoyée à Primary-DNS (10.0.0.10).

  

  

  Test réussi. Primary-DNS a pu gérer les requêtes DNS en cas de panne de Secondary-DNS.

Scénario de test 2 : le DNS secondaire répond aux requêtes FE-VM lorsque le DNS principal est arrêté

En cas de panne dans le DNS principal, nous devons nous assurer que le DNS secondaire répond aux requêtes provenant de FE-VM, car le DNS-NLB y dirige le trafic.

• L'image suivante illustre le scénario de test que nous voulons atteindre.

  

• Commençons par arrêter l'instance Primary-DNS. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Calculer.
  2. Cliquez sur Instances.

  

  1. Cochez la case en regard de l'instance.
  2. Cliquez sur Actions.
  3. Cliquez sur Arrêter.
  4. Cliquez sur Arrêter.
  5. L'instance est maintenant à l'état Arrêté.

  

  

  

• Démarrez l'instance Secondary-DNS.

  1. Cochez la case en regard de l'instance.
  2. Cliquez sur Actions.
  3. Cliquez sur Démarrer.
  4. Cliquez sur Démarrer.
  5. L'instance est maintenant à l'état En cours d'exécution.

  

  

  

• Ensuite, nous allons accéder à FE-VM et effectuer un test en exécutant une requête. Pour ce faire, nous utiliserons le service OCI Bastion. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Identité et sécurité.
  2. Cliquez sur Bastion.

  

• Cliquez sur FEBastion.

  

• Cliquez sur Créer une session.

  

• Saisissez les informations suivantes .

  1. Type de session : sélectionnez Session SSH gérée.
  2. Nom de session : entrez le nom de la session.
  3. Nom utilisateur : Entrez le nom utilisateur. Pour l'instance Oracle Linux, le nom utilisateur par défaut est opc.
  4. Instance de calcul : sélectionnez l'instance FE-VM.
  5. Collez la même clé publique générée dans le tutoriel 1 : Tâche 2.1 : générer la paire de clés SSH.
  6. Cliquez sur Créer une session.

  

  

• Une fois la session créée, cliquez sur les trois points et sur Copier la commande SSH.

  

  La commande doit se présenter comme suit :

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-[e-mail]" -p 22 opc@10.1.0.5
  

• Ouvrez OCI Cloud Shell.

  1. Accédez au répertoire .ssh à l'aide de la commande cd .ssh.
  2. Collez la commande SSH. Veillez à remplacer <privateKey> par le nom de fichier de clé privée id_rsa.
  3. Saisissez yes.

  

• Connexion réussie Exécutez à présent une requête de test de FE-VM vers be.orastage.com à l'aide de la commande host. Vérifiez que la requête a réussi et qu'une réponse a été reçue.

  

• Nous savons qu'il n'existe qu'un seul serveur back-end en bon état pour gérer la demande, à savoir DNS secondaire. Nous allons donc vérifier le flux de la requête DNS et voir quel serveur a répondu à cette requête à l'aide des journaux de sous-réseau OCI.

  1. Cliquez sur le journal.
  2. La demande est passée de l'adresse de transfert (10.1.0.6) qui est placée dans le même sous-réseau que FE-VM à l'adresse IP NLB (10.0.0.110) dans le DNS-VCN.
  3. Ensuite, à partir de NLB (10.0.0.110), la demande est envoyée à Secondary-DNS (10.0.0.20).

  

  

  Test réussi. Secondary-DNS peut gérer les requêtes DNS au cas où le DNS principal serait arrêté.

Scénario de test 3 : le DNS principal répond aux requêtes BE-VM lorsque le DNS secondaire est arrêté

En cas de panne dans le DNS secondaire, nous devons nous assurer que le DNS principal répond aux requêtes provenant de BE-VM, car le DNS-NLB y dirige le trafic.

• L'image suivante illustre le scénario de test que nous voulons atteindre.

  

• Actuellement, toutes les instances sont en fonctionnement. Commençons par arrêter l'instance Secondary-DNS. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Calculer.
  2. Cliquez sur Instances.

  

  1. Cochez la case en regard de l'instance.
  2. Cliquez sur Actions.
  3. Cliquez sur Arrêter.
  4. Cliquez sur Arrêter.
  5. L'instance est maintenant à l'état Arrêté.

  

  

  

• Ensuite, nous allons accéder à BE-VM et effectuer un test en exécutant une requête. Pour ce faire, nous utiliserons le service OCI Bastion. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Identité et sécurité.
  2. Cliquez sur Bastion.

  

• Cliquez sur BEBastion.

  

• Cliquez sur Créer une session.

  

• Saisissez les informations suivantes .

  1. Type de session : sélectionnez Session SSH gérée.
  2. Nom de session : entrez le nom de la session.
  3. Nom utilisateur : Entrez le nom utilisateur. Pour l'instance Oracle Linux, le nom utilisateur par défaut est opc.
  4. Instance de calcul : sélectionnez l'instance BE-VM.
  5. Collez la même clé publique générée dans le tutoriel 1 : Tâche 2.1 : générer la paire de clés SSH.
  6. Cliquez sur Créer une session.

  

  

• Une fois la session créée, cliquez sur les trois points et sur Copier la commande SSH.

  

  La commande doit se présenter comme suit :

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-[e-mail]" -p 22 opc@10.2.0.5
  

• Ouvrez OCI Cloud Shell.

  1. Accédez au répertoire .ssh à l'aide de la commande cd .ssh.
  2. Collez la commande SSH. Veillez à remplacer <privateKey> par le nom de fichier de clé privée id_rsa.
  3. Saisissez yes.

  

• Connexion réussie Exécutez à présent une requête de test de BE-VM vers fe.orastage.com à l'aide de la commande host. Vérifiez que la requête a réussi et qu'une réponse a été reçue.

  

• Nous savons qu'il n'existe qu'un seul serveur back-end en bon état pour gérer la demande, à savoir DNS principal. Nous allons donc vérifier le flux de la requête DNS et voir quel serveur a répondu à cette requête à l'aide des journaux de sous-réseau OCI.

  1. Cliquez sur le journal.
  2. La demande est passée de l'adresse de transfert (10.2.0.6) qui est placée dans le même sous-réseau que BE-VM à l'adresse IP NLB (10.0.0.110) dans le DNS-VCN.
  3. Ensuite, à partir de NLB (10.0.0.110), la demande est envoyée à Primary-DNS (10.0.0.10).

  

  

  Test réussi. Primary-DNS a pu gérer les requêtes DNS en cas de panne de Secondary-DNS.

Scénario de test 4 : le DNS secondaire répond aux requêtes BE-VM lorsque le DNS principal est arrêté

En cas de panne dans le DNS principal, nous devons nous assurer que le DNS secondaire répond aux requêtes provenant de BE-VM, car le DNS-NLB y dirige le trafic.

• L'image suivante illustre le scénario de test que nous voulons atteindre.

  

• Commençons par arrêter l'instance Primary-DNS. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Calculer.
  2. Cliquez sur Instances.

  

  1. Cochez la case en regard de l'instance.
  2. Cliquez sur Actions.
  3. Cliquez sur Arrêter.
  4. Cliquez sur Arrêter.
  5. L'instance est maintenant à l'état Arrêté.

  

  

  

• Démarrez l'instance Secondary-DNS.

  1. Cochez la case en regard de l'instance.
  2. Cliquez sur Actions.
  3. Cliquez sur Démarrer.
  4. Cliquez sur Démarrer.
  5. L'instance est maintenant à l'état En cours d'exécution.

  

  

  

• Ensuite, nous allons accéder à BE-VM et effectuer un test en exécutant une requête. Pour ce faire, nous utiliserons le service OCI Bastion. Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.

  

  1. Cliquez sur Identité et sécurité.
  2. Cliquez sur Bastion.

  

• Cliquez sur BEBastion.

  

• Cliquez sur Créer une session.

  

• Saisissez les informations suivantes .

  1. Type de session : sélectionnez Session SSH gérée.
  2. Nom de session : entrez le nom de la session.
  3. Nom utilisateur : Entrez le nom utilisateur. Pour l'instance Oracle Linux, le nom utilisateur par défaut est opc.
  4. Instance de calcul : sélectionnez l'instance BE-VM.
  5. Collez la même clé publique générée dans le tutoriel 1 : Tâche 2.1 : générer la paire de clés SSH.
  6. Cliquez sur Créer une session.

  

  

• Une fois la session créée, cliquez sur les trois points et sur Copier la commande SSH.

  

  La commande doit se présenter comme suit :

  ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.e[e-mail]" -p 22 opc@10.2.0.5
  

• Ouvrez OCI Cloud Shell.

  1. Accédez au répertoire .ssh à l'aide de la commande cd .ssh.
  2. Collez la commande SSH. Veillez à remplacer <privateKey> par le nom de fichier de clé privée id_rsa.
  3. Saisissez yes.

  

• Connexion réussie Exécutez à présent une requête de test de BE-VM vers fe.orastage.com à l'aide de la commande host. Vérifiez que la requête a réussi et qu'une réponse a été reçue.

  

• Nous savons qu'il n'existe qu'un seul serveur back-end en bon état pour gérer la demande, à savoir DNS secondaire. Nous allons donc vérifier le flux de la requête DNS et voir quel serveur a répondu à cette requête à l'aide des journaux de sous-réseau OCI.

  1. Cliquez sur le journal.
  2. La demande est passée de l'adresse de transfert (10.2.0.6) qui est placée dans le même sous-réseau que BE-VM à l'adresse IP NLB (10.0.0.110) dans le DNS-VCN.
  3. Ensuite, à partir de NLB (10.0.0.110), la demande est envoyée à Secondary-DNS (10.0.0.20).

  

  

  Test réussi. Secondary-DNS a pu gérer les requêtes DNS en cas de panne de Primary-DNS.

Etapes suivantes

Dans ce tutoriel, nous avons amélioré la configuration d'un DNS BIND9 simple client-serveur dans OCI en intégrant un équilibreur de charge réseau OCI et un serveur DNS secondaire afin de garantir une disponibilité continue du service en cas de panne du serveur principal.

Jusqu'à présent, nous avons développé une architecture DNS fiable et performante spécifiquement pour la gestion des requêtes de domaine orastage.com. Cependant, la société OraStage doit également résoudre les noms de domaine natifs OCI, tels que oraclevcn.com et oraclecloud.com. Pour cela, des étapes supplémentaires sont nécessaires. Dans le tutoriel suivant, Utiliser OCI DNS pour résoudre les domaines natifs, nous allons montrer comment réaliser cette configuration.

Remerciements

• Auteur : Anas abdallah (spécialiste du réseau cloud)

Ressources de formation supplémentaires

Explorez d'autres ateliers sur docs.oracle.com/learn ou accédez à d'autres contenus de formation gratuits sur le canal Oracle Learning YouTube. De plus, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir la documentation produit, consultez le site Oracle Help Center.

---

Informations relatives au titre et au copyright

<

Implement High Availability on BIND9 Domain Name System in Oracle Cloud Infrastructure

G14450-02

Copyright ©2025, Oracle and/or its affiliates.