Note :

Ce tutoriel nécessite l'accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, voir Démarrer avec le niveau gratuit d'Oracle Cloud Infrastructure.
Il utilise des exemples de valeurs pour les données d'identification, la location et les compartiments d'Oracle Cloud Infrastructure. À la fin de votre laboratoire, remplacez ces valeurs par celles qui sont propres à votre environnement en nuage.

Utiliser Oracle Cloud Infrastructure DNS pour résoudre les domaines natifs

Présentation

OraStage est une entreprise leader dans le secteur de l'énergie, spécialisée dans les solutions d'énergie renouvelable et les technologies d'énergie innovantes, la société a annoncé une décision stratégique de migrer ses charges de travail vers Oracle Cloud Infrastructure (OCI) afin d'améliorer la performance, l'évolutivité et la sécurité.

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

OraStage Exigences relatives au DNS :

La société dispose de plusieurs domaines et sous-domaines internes. Tous doivent être résolus par leur DNS BIND9 dans OCI, où OraStage gérera toutes les zones et tous les enregistrements connexes. L'un de ces domaines est orastage.com que nous allons utiliser dans ce tutoriel. Ainsi, toute interrogation à orastage.com doit être transmise à BIND9.
Ils doivent toujours résoudre les domaines natifs OCI (oraclevcn.com, oraclecloud.com, etc.) dans certains cas, et cela se fera à l'aide de composants DNS privés OCI : vues privées, transfert de points d'extrémité et de règles, et points d'extrémité d'écoute.
Toutes les interrogations doivent être inspectées par une instance de pare-feu pfSense.
Pour éviter un point de défaillance unique, OraStage prévoit d'utiliser un autre serveur DNS et d'exploiter l'équilibreur de charge OCI pour répartir les interrogations entre le DNS principal et le DNS secondaire.

Cette série de tutoriels vous guidera étape par étape pour atteindre les exigences décrites ci-dessus, en construisant l'ensemble de la solution à partir de zéro. Vous pouvez facilement accéder à chaque tutoriel à partir de la liste ci-dessous :

Tutoriel 1 : Configurer le DNS BIND9 dans OCI. Voyez 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 constitués de serveurs "Frontend" et "Backend", chacun hébergé dans un réseau satellite distinct. Le serveur BIND9 traitera toutes les interrogations DNS dirigées vers orastage.com.
Tutoriel 2 : Mettre en oeuvre la haute disponibilité dans le scénario DNS BIND9 dans OCI. Ce tutoriel porte sur l'ajout d'un serveur BIND9 secondaire et la configuration d'un équilibreur de charge de réseau (NLB) pour répartir le trafic DNS entre les deux serveurs. Les interrogations DNS vers orastage.com seront dirigées vers l'adresse IP de l'équilibreur de charge de réseau, qui permettra d'équilibrer la charge entre les serveurs BIND9 principal et secondaire. Si un serveur devient indisponible, la résolution DNS se poursuivra sans interruption de service.
Tutoriel 3 : Utiliser le DNS OCI pour résoudre les domaines natifs. Se concentrant uniquement sur un cas d'utilisation spécifique, où 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. Le DNS BIND9 n'est pas utilisé dans ce tutoriel.
Tutoriel 4 : Ajout de la sécurité à l'architecture DNS à l'aide du pare-feu pfSense. Mettre l'accent sur l'installation d'un pare-feu pfSense dans le VCN central dans OCI et effectuer la configuration réseau requise pour acheminer tout le trafic Est-Ouest, y compris les interrogations DNS (effectuées dans les précédents tutoriels) au moyen du pare-feu à inspecter.

Aperçu

Dans ce tutoriel, nous allons nous concentrer sur la gestion des domaines natifs OCI tels que oraclevcn.com et oraclecloud.com. Dans cette section, nous allons abandonner la résolution de domaines personnalisés tels que orastage.com à l'aide de BIND9, puis explorer les capacités DNS intégrées d'OCI.

Nous examinerons les composants du service DNS privé d'OCI et les éléments clés impliqués dans le traitement des interrogations, qui jouent un rôle crucial dans la gestion du trafic DNS au sein des réseaux privés OCI. Vous remarquerez que nous les avons déjà utilisés dans certaines parties du tutoriel 1 et du tutoriel 2. Ces groupes de pages sont les suivants :

Zone DNS privée : Contient des données DNS accessibles uniquement à partir d'un réseau VCN, telles que des adresses IP privées. Une zone DNS privée a des capacités similaires à une zone DNS Internet, mais elle fournit des réponses uniquement pour les clients qui peuvent l'atteindre par l'intermédiaire d'un réseau en nuage virtuel. Chaque zone appartient à une seule vue.
Vue DNS privée : Regroupement de zones privées, chaque vue peut être associée à un résolveur pour contrôler la façon dont les interrogations DNS sont résolues. Une vue unique peut être utilisée par plusieurs résolveurs, ce qui permet le partage de données DNS privées entre différents réseaux en nuage virtuels. Chaque zone ne peut faire partie que d'une seule vue.

Par exemple, vous avez créé deux nouveaux réseaux en nuage virtuels : VCN-A et VCN-B. Par défaut, les ressources de VCN-A peuvent se résoudre sans configuration supplémentaire, car leurs enregistrements sont stockés dans la même zone privée, qui se trouve dans une vue privée de VCN-A. Même chose pour VCN-B. Toutefois, si vous voulez que les ressources de VCN-A résolvent les ressources de VCN-B, vous devez associer la vue privée de VCN-B au résolveur VCN-A. Si vous voulez que les ressources de VCN-B résolvent les ressources de VCN-A, vous devez associer la vue privée de VCN-A au résolveur VCN-B.
Résolveur DNS privé : Un résolveur DNS privé dédié au VCN fournit des réponses aux interrogations DNS dans l'ordre suivant : Tout d'abord, il vérifie les zones dans les vues privées attachées, puis dans sa vue par défaut, puis en vérifiant les règles de transfert et, enfin, en utilisant Internet DNS. Il s'agit essentiellement du moteur qui recherche les réponses aux interrogations de votre instance.

Par exemple, la capture d'écran suivante présente une page de résolveur de VCN. La séquence suivie lors de la résolution d'une interrogation à partir d'une instance de ce VCN se présente comme suit :
Transfert de points d'extrémité et de règles : Les points d'extrémité de transfert servent de connecteurs entre votre VCN OCI et les résolveurs DNS externes ou d'autres zones DNS. À l'aide de règles de transfert, vous pouvez diriger des interrogations DNS spécifiques vers des serveurs ou des modules d'écoute externes désignés dans d'autres résolveurs de VCN, ce qui permet d'activer les architectures DNS en nuage hybrides ou la résolution multizone.
Points d'extrémité d'écoute : Ces points d'extrémité sont utilisés pour recevoir des interrogations DNS provenant de sources externes. Ils permettent à votre infrastructure DNS OCI d'écouter les demandes DNS entrantes et d'y répondre, ce qui améliore votre capacité à gérer les interrogations DNS dans diverses configurations réseau.

Ensemble, ces composants fournissent des outils puissants pour gérer et personnaliser le DNS dans votre environnement OCI.

À la fin de ce tutoriel, vous aurez une bonne compréhension de l'utilisation de ces composants DNS OCI pour gérer et résoudre efficacement les interrogations dans votre environnement en nuage.

Objectifs

L'objectif principal de ce tutoriel est d'activer le client FE-VM (fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com) pour interroger BE-VM (be-vm.beprivatesubnet.backendvcn.oraclevcn.com), et vice versa, avec le module d'écoute LSN pour répondre à toutes ces interrogations.

Architecture finale

Note :

Lorsque vous créez initialement un réseau VCN et un sous-réseau, vous pouvez spécifier des étiquettes DNS pour chacune, puis lancer une instance de calcul. Vous pouvez lui affecter un nom d'hôte. À la fin, le nom de domaine complet (FQDN) de l'instance se présente comme suit : <VM-HOSTNAME>.<SUBNET-DNS-Label>.<VCN-DNS-Label>.oraclevcn.com. La spécification de ces étiquettes est facultative. Si vous les laissez vides, ils recevront des noms aléatoires tirés du nom de la ressource, tout comme FE-VM et BE-VM dans ce tutoriel.

Si nous n'avions besoin que de ressources OCI pour nous résoudre, un module d'écoute n'est pas nécessaire ici, car cela peut être fait uniquement à l'aide de vues privées, comme indiqué dans la section Overview (Aperçu). Toutefois, la raison derrière le choix d'utiliser un module d'écoute ici est également de gérer la résolution DNS à partir de tout autre environnement tel que sur place et d'autres nuages, et l'ajout de toutes les vues privées au résolveur de ce module d'écoute sera suffisant. Cette configuration répond à un cas d'utilisation particulier où vous pourriez également avoir besoin d'autres environnements (sur place ou dans d'autres environnements en nuage) pour résoudre les ressources OCI. Toutefois, cela n'est pas inclus dans ce tutoriel.

Toutes les interrogations oraclevcn.com et oraclecloud.com doivent être transmises au même module d'écoute, que l'interrogation provienne d'OCI, d'un réseau sur place ou d'un autre réseau de fournisseur de services infonuagiques, car le résolveur de LSN-VCN traitera toutes ces interrogations à partir de vues privées.

Dans ce tutoriel, nous ne testons pas les interrogations sur place ou Microsoft Azure, mais uniquement à partir d'instances OCI. Le diagramme suivant n'est donc utilisé qu'à des fins d'illustration.

Préalables

Accès à une location OCI et autorisations pour gérer le réseau et les services de calcul requis.
Comprendre de base le routage et la sécurité du réseau OCI et leurs fonctionnalités : réseau en nuage virtuel (VCN), table de routage, passerelle de routage dynamique (DRG), liste de sécurité, hôte bastion et équilibreur de charge de réseau OCI.
Connaissance de base du DNS en général.
Assurez-vous de terminer les deux premiers tutoriels :
1. Configurez le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure.
2. Mettre en oeuvre la haute disponibilité sur le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure.
Un VCN est requis avec un sous-réseau privé et l'attachez à la passerelle DRG existante. Pour plus d'informations, voir Tâche 1.3 : Attacher des réseaux en nuage virtuels à la passerelle DRG.
- LSN-VCN : Hébergera le module d'écoute. Notez que le module d'écoute n'a pas besoin d'être dans un VCN dédié, mais nous avons préféré le faire dans ce tutoriel afin de le séparer des autres ressources.
En fonction des conditions requises, vous avez déjà créé l'architecture suivante.

Tâche 1 : Configurer des composants réseau tels que le routage et la sécurité

Tâche 1.1 : Créer un réseau en nuage virtuel (LSN-VCN)

Assurez-vous que LSN-VCN (10.3.0.0/16) est déjà créé, contenant LSN-Private-Subnet (10.3.0.0/24).

Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Réseau.
2. Cliquez sur Réseaux en nuage virtuels.
Nous pouvons voir le VCN en place, car il n'a actuellement qu'un seul sous-réseau privé, et la table de routage par défaut et la liste de sécurité lui sont attachées.

Tâche 1.2 : Configurer le routage et la sécurité pour LSN-VCN

Cela doit être fait au niveau du sous-réseau. Naviguez jusqu'à la page Réseaux en nuage virtuels et cliquez sur LSN-VCN.
Cliquez sur le sous-réseau privé.
Cliquez sur Table de routage, qui est une table de routage affectée.
Ajoutez les règles suivantes.
- 10.0.0.0/16 - DRG : Achemine le trafic destiné au DNS-VCN vers la passerelle DRG.
- 10.1.0.0/16 - DRG : Achemine le trafic destiné à Frontend-VCN vers la passerelle DRG.
- 10.2.0.0/16 - DRG : Achemine le trafic destiné au réseau dorsal-VCN vers la passerelle DRG.
Faisons maintenant la sécurité. Allez à la page Détails du sous-réseau et cliquez sur la liste de sécurité affectée.
Autoriser le trafic entrant : Trafic DNS (TCP/port 53 et UDP/port 53) depuis DNS-VCN, Frontend-VCN et Backend-VCN.
Autoriser tout le trafic sortant.

Tâche 1.3 : Configurer le routage et la sécurité pour le DNS-VCN

Naviguez jusqu'à la page Réseaux en nuage virtuels et cliquez sur DNS-VCN.
Cliquez sur le sous-réseau privé.
Cliquez sur Table de routage, qui est une table de routage affectée.
Ajoutez les règles suivantes.
- 10.3.0.0/16 - DRG : Achemine le trafic destiné au LSN-VCN vers la passerelle DRG.
Les règles de sécurité nécessaires ont déjà été ajoutées. Pour plus d'informations, voir Tutoriel 1 : Tâche 1.4 - Configurer le routage et la sécurité pour DNS-VCN.

Tâche 1.4 : Configurer le routage et la sécurité pour Frontend-VCN

Répétez les étapes de la tâche 1.3 pour Frontend-VCN.

Tâche 1.5 : Configurer le routage et la sécurité pour le VCN dorsal

Répétez les étapes effectuées dans la tâche 1.3 pour le VCN dorsal.

Tâche 2 : Configurer les composants DNS privés d'OCI

Tâche 2.1 : Ajouter des vues privées au résolveur LSN-VCN

Naviguez jusqu'à LSN-VCN et cliquez sur Résolveur DNS.
1. Faites défiler l'affichage vers le bas et cliquez sur Vues privées associées.
2. Cliquez sur Gérer les vues privées.
3. Sélectionnez les vues privées de DNS-VCN, de Frontend-VCN et de Backend-VCN.
4. Cliquez sur enregistrer les modifications.
5. Les vues privées ont été ajoutées.
Actuellement, le résolveur LSN-VCN est visible sur tous les enregistrements DNS créés dans les autres zones privées. Ainsi, lorsque le module d'écoute reçoit une interrogation pour les noms de domaine complets FE-VM et BE-VM, sa résolution est effectuée directement à l'aide des vues privées associées.

Tâche 2.2 : Configurer le point d'extrémité d'écoute dans le résolveur LSN-VCN

Allez à la console OCI.
1. Dans le même résolveur, cliquez sur Points d'extrémité.
2. Cliquez sur Créer un point d'extrémité.
3. Nom : Entrez un nom pour le point d'extrémité.
4. Sous-réseau : Sélectionnez le sous-réseau privé du LSN-VCN.
5. Type de point d'extrémité : Sélectionnez Écoute.
6. Adresse IP d'écoute : Entrez 10.3.0.6.
7. Cliquez sur Créer un point d'extrémité.
8. Le point d'extrémité d'écoute a été créé.

Tâche 2.3 : Configurer la règle de transmission dans le résolveur de réseau VCN frontal

Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Réseau.
2. Cliquez sur Réseaux en nuage virtuels.
Cliquez sur Frontend-VCN.

Cliquez sur le résolveur DNS du VCN.

Faire défiler vers le bas.
1. Cliquez sur Règles.
2. Cliquez sur Gérer les règles.
3. Ajoutez une autre règle avec les informations suivantes, comme illustré dans la capture d'écran ci-dessus.
4. Cliquez sur enregistrer les modifications.
5. La règle de transfert a été créée.

Tâche 2.4 : Configurer la règle de transfert dans le résolveur de VCN dorsal

Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
1. Cliquez sur Réseau.
2. Cliquez sur Réseaux en nuage virtuels.
Cliquez sur Backend-VCN.
Cliquez sur le résolveur DNS du VCN.
Faire défiler vers le bas.
1. Cliquez sur Règles.
2. Cliquez sur Gérer les règles.
3. Ajoutez une autre règle avec les informations suivantes, comme illustré dans la capture d'écran ci-dessus.
4. Cliquez sur enregistrer les modifications.
5. La règle de transfert a été créée.
L'architecture devrait ressembler à cela.

Tâche 3 : Tester et valider

Scénario de test 1 : FE-VM pour interroger le module d'écoute du domaine natif BE-VM

L'ordinateur client FE-VM doit pouvoir résoudre be-vm.beprivatesubnet.backendvcn.oraclevcn.com. L'image suivante illustre le scénario de test que nous visons à réaliser.
Allez à la console OCI, naviguez jusqu'à l'instance BE-VM et copiez le nom de domaine complet interne pour l'utiliser dans le test.
Accédez à FE-VM et effectuez un test d'interrogation à l'aide du service d'hôte bastion OCI comme dans le tutoriel 2 : Scénario de test 1 - Principal-DNS répond aux interrogations FE-VM lorsque le DNS secondaire est arrêté. Une fois connecté, exécutez les interrogations oraclevcn.com de FE-VM à be-vm.beprivatesubnet.backendvcn.oraclevcn.com et validez la configuration. Vous pouvez utiliser diverses méthodes pour vérifier que la configuration fonctionne correctement.
1. Exécutez la commande host.
2. Exécutez la commande ping.
3. Exécutez la commande dig.

Comme le montre le scénario de test, nous pouvons extraire l'adresse IP du domaine natif BE-VM et le ping fonctionne à l'aide du nom de domaine complet, ce qui signifie que le test a réussi.

Scénario de test 2 : BE-VM pour interroger le module d'écoute du domaine natif FE-VM

L'ordinateur client BE-VM doit pouvoir résoudre fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com. L'image suivante illustre le scénario de test que nous visons à réaliser.
Allez à la console OCI, naviguez jusqu'à l'instance FE-VM et copiez le nom de domaine complet interne pour l'utiliser dans le test.
Accédez à BE-VM et effectuez un test d'interrogation à l'aide du service d'hôte bastion OCI. Une fois connecté, exécutez les interrogations oraclevcn.com de BE-VM à fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com et validez la configuration. Vous pouvez utiliser diverses méthodes pour vérifier que la configuration fonctionne correctement.
1. Exécutez la commande host.
2. Exécutez la commande ping.
3. Exécutez la commande dig.

Comme le montre le scénario de test, nous pouvons extraire l'adresse IP du domaine natif BE-VM et le ping fonctionne à l'aide du nom de domaine complet, ce qui signifie que le test a réussi.

Étapes suivantes

Dans ce tutoriel, nous avons utilisé des vues privées, des points d'extrémité et des règles de transfert OCI et des points d'extrémité d'écoute, qui offrent une gestion DNS flexible et robuste dans un réseau en nuage virtuel. Ensemble, ces composants rationalisent les opérations de DNS, en assurant une résolution de noms efficace et évolutive dans les environnements OCI, en particulier pour un scénario DNS hybride qui comprend des environnements multinuages et sur place intégrés.

Dans le prochain et le dernier tutoriel de cette série, Ajoutez une sécurité à l'architecture DNS à l'aide du pare-feu pfSense, nous renforcerons la sécurité de notre infrastructure DNS en configurant le pare-feu pfSense pour inspecter et contrôler toutes les interrogations DNS, ce qui comprendra la surveillance et le filtrage des demandes pour les domaines OCI internes (oraclevcn.com et oraclecloud.com) et les domaines personnalisés gérés dans BIND9, tels que orastage.com.

Remerciements

Auteur - Anas abdallah (spécialiste du réseau en nuage)

Autres ressources d'apprentissage

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

Pour obtenir la documentation sur le produit, visitez Oracle Help Center.

Informations sur le titre et les droits d'auteur

Use Oracle Cloud Infrastructure DNS to Resolve Native Domains

G16583-02