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.

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

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 des conditions spécifiques décrits par OraStage, l'entreprise a besoin d'une solution hybride de système de noms de domaine (DNS) dans le cloud, et par voie 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

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 et explorer les fonctionnalités DNS intégrées OCI.

Nous allons nous pencher sur les composants d'OCI Private DNS et les éléments clés impliqués dans la gestion des requêtes, 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 des tutoriels 1 et 2. Ces composants sont les suivants :

Zone DNS privée : contient des données DNS accessibles uniquement à partir d'un VCN tel que des adresses IP privées. Une zone DNS privée offre les mêmes fonctionnalités qu'une zone DNS Internet, mais ne fournit des réponses que pour les clients qui peuvent l'atteindre via un réseau cloud virtuel. Chaque zone appartient à une vue unique.
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 requêtes 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 cloud virtuels. Chaque zone ne peut faire partie que d'une seule vue.

Par exemple, vous avez créé deux nouveaux réseaux cloud virtuels : VCN-A et VCN-B. Par défaut, les ressources au sein de VCN-A peuvent se résoudre mutuellement sans configuration supplémentaire, car leurs enregistrements sont stockés dans la même zone privée, qui se trouve dans la vue privée VCN-A. Même chose pour VCN-B. Cependant, si vous voulez que les ressources du VCN-A résolvent les ressources du VCN-B, vous devez associer la vue privée du VCN-B au résolveur VCN-A. Si vous voulez que les ressources du VCN-B résolvent les ressources du VCN-A, vous devez associer la vue privée du 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 requêtes DNS dans l'ordre suivant : il vérifie d'abord 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 le DNS Internet. Il s'agit essentiellement du moteur qui recherche des réponses aux requêtes de votre instance.

Par exemple, la capture d'écran suivante montre une page de résolveur de VCN, la séquence suivie lors de la résolution d'une requête à partir d'une instance de ce VCN se déroulera comme suit :
Transfert des adresses et des règles : les adresses de transfert servent de connecteurs entre votre VCN OCI et les résolveurs DNS externes ou d'autres zones DNS. En utilisant des règles de transfert, vous pouvez diriger des requêtes DNS spécifiques vers des serveurs ou des processus d'écoute externes désignés dans d'autres résolveurs VCN, ce qui permet des architectures DNS cloud hybrides ou une résolution multi-zones.
Adresses d'écoute : ces adresses sont utilisées pour recevoir des requêtes DNS 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 requêtes 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 solide compréhension de l'utilisation de ces composants DNS OCI pour gérer et résoudre efficacement les requêtes dans votre environnement cloud.

Objectifs

L'objectif principal de ce tutoriel est d'autoriser le client FE-VM (fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com) à interroger BE-VM (be-vm.beprivatesubnet.backendvcn.oraclevcn.com), et inversement, avec le processus d'écoute LSN pour répondre à toutes ces requêtes.

Architecture finale

Remarque :

Lorsque vous créez initialement un VCN et un sous-réseau, vous pouvez spécifier des étiquettes DNS pour chacun, puis lancer une instance de calcul, vous pouvez lui attribuer un nom d'hôte. A la fin, le nom de domaine qualifié complet de l'instance ressemblera à ce qui suit : <VM-HOSTNAME>.<SUBNET-DNS-Label>.<VCN-DNS-Label>.oraclevcn.com. La spécification de ces étiquettes est facultative. Si vous les laissez vides, des noms aléatoires provenant du nom de la ressource leur seront attribués, tout comme FE-VM et BE-VM dans ce tutoriel.

Si nous avions uniquement besoin de ressources OCI pour nous résoudre mutuellement, aucun processus d'écoute n'est nécessaire ici, car cela peut être fait en utilisant uniquement des vues privées comme indiqué dans la section Aperçu. Cependant, la raison pour laquelle vous choisissez d'utiliser un processus d'écoute ici est également de gérer la résolution DNS à partir de n'importe quel autre environnement, tel que les clouds sur site et autres. L'ajout de toutes les vues privées au résolveur de ce processus d'écoute suffira. Cette configuration répond à un cas d'utilisation particulier où vous pourriez également avoir besoin d'autres environnements (sur site ou d'autres environnements cloud) pour résoudre les ressources OCI. Cependant, cela n'est pas inclus dans ce tutoriel.

Toutes les requêtes oraclevcn.com et oraclecloud.com doivent être transférées vers le même processus d'écoute, que la requête provienne d'OCI, d'un réseau sur site ou d'un autre réseau de fournisseur cloud, car le résolveur de LSN-VCN traitera toutes ces requêtes à partir de vues privées.

Dans ce tutoriel, nous n'allons pas tester les requêtes à partir d'instances OCI ou sur site ou de Microsoft Azure. Par conséquent, le diagramme suivant n'est fourni qu'à titre d'illustration.

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 DNS en général.
Veillez à suivre les deux premiers tutoriels :
1. Configurez le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure.
2. Implémentez 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 attachez-le au DRG existant. Pour plus d'informations, reportez-vous à Tâche 1.3 : attacher des réseaux cloud virtuels au DRG.
- LSN-VCN : cette option hébergera le processus d'écoute. Notez que le processus 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 prérequis, vous devez avoir 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éation d'un réseau cloud virtuel (LSN-VCN)

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

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.
Nous pouvons voir le VCN en place, actuellement il n'a qu'un seul sous-réseau privé, et la table de routage et la liste de sécurité par défaut attachées à lui.

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

Cette opération doit être effectuée au niveau du sous-réseau. Accédez à la page des réseaux cloud 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 : acheminez le trafic destiné à DNS-VCN vers le DRG.
- 10.1.0.0/16 - DRG : acheminez le trafic destiné à Frontend-VCN vers le DRG.
- 10.2.0.0/16 - DRG : acheminez le trafic vers le DRG vers le VCN de back-end.
Faisons la sécurité maintenant. Accédez à 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) à partir de DNS-VCN, Frontend-VCN et Backend-VCN.
Autorisez tout le trafic sortant.

Tâche 1.3 : configuration du routage et de la sécurité pour DNS-VCN

Accédez à la page des réseaux cloud 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 : acheminez le trafic vers le DRG vers le LSN-VCN.
Les règles de sécurité nécessaires ont déjà été ajoutées. Pour plus d'informations, reportez-vous au Tutoriel 1 : Tâche 1.4 - Configuration du routage et de la sécurité pour DNS-VCN.

Tâche 1.4 : configuration du routage et de la sécurité pour le VCN frontal

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

Tâche 1.5 : configuration du routage et de la sécurité pour le back-end VCN

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

Tâche 2 : configuration des composants DNS privés OCI

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

Accédez à 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, Frontend-VCN et Backend-VCN.
4. Cliquez sur Enregistrer les modifications.
5. Les vues privées ont été ajoutées.
Actuellement, le résolveur LSN-VCN dispose d'une visibilité sur tous les enregistrements DNS créés dans les autres zones privées. Par conséquent, lorsque le processus d'écoute reçoit des requêtes vers des noms de domaine qualifiés complets FE-VM et BE-VM, il les résout directement à l'aide des vues privées associées.

Tâche 2.2 : configurer l'adresse d'écoute dans le résolveur LSN-VCN

Accédez à la console OCI.
1. Dans le même résolveur, cliquez sur Adresses.
2. Cliquez sur Créer une adresse.
3. Nom : entrez le nom de l'adresse.
4. Sous-réseau : sélectionnez le sous-réseau privé du LSN-VCN.
5. Type d'adresse : sélectionnez Ecoute.
6. Adresse IP d'écoute : entrez 10.3.0.6.
7. Cliquez sur Créer une adresse.
8. L'adresse d'écoute a été créée.

Tâche 2.3 : configuration de la règle de transfert dans le résolveur VCN frontal

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. Ajoutez une autre règle avec les informations suivantes, comme illustré dans la capture d'écran.
4. Cliquez sur Enregistrer les modifications.
5. La règle de transfert a été créée.

Tâche 2.4 : configuration de la règle de transfert dans le résolveur VCN back-end

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. Ajoutez une autre règle avec les informations suivantes, comme illustré dans la capture d'écran.
4. Cliquez sur Enregistrer les modifications.
5. La règle de transfert a été créée.
L'architecture devrait ressembler à ceci.

Tâche 3 : tester et valider

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

La machine client FE-VM doit pouvoir résoudre be-vm.beprivatesubnet.backendvcn.oraclevcn.com. L'image suivante illustre le scénario de test que nous voulons atteindre.
Accédez à la console OCI, accédez à l'instance BE-VM et copiez le nom de domaine qualifié complet interne pour l'utiliser dans le test.
Accédez à FE-VM et effectuez un test de requête à l'aide du service OCI Bastion, comme dans le tutoriel 2 : Scénario de test 1 : le DNS principal répond aux requêtes FE-VM lorsque le DNS secondaire est arrêté. Une fois connecté, exécutez les requêtes oraclevcn.com de FE-VM vers be-vm.beprivatesubnet.backendvcn.oraclevcn.com et validez la configuration. Vous pouvez utiliser différentes 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 indiqué dans 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 qualifié complet, ce qui signifie que le test a réussi.

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

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 voulons atteindre.
Accédez à la console OCI, accédez à l'instance FE-VM et copiez le nom de domaine qualifié complet interne pour l'utiliser dans le test.
Accédez à BE-VM et effectuez un test de requête à l'aide du service OCI Bastion. Une fois connecté, exécutez des requêtes oraclevcn.com de BE-VM vers fe-vm.feprivatesubnet.frontendvcn.oraclevcn.com et validez la configuration. Vous pouvez utiliser différentes méthodes pour vérifier que la configuration fonctionne correctement.
1. Exécuter la commande host.
2. Exécutez la commande ping.
3. Exécutez la commande dig.

Etapes suivantes

Dans ce tutoriel, nous avons utilisé les vues privées OCI, le transfert d'adresses et de règles et les adresses d'écoute qui offrent une gestion DNS flexible et robuste au sein d'un réseau cloud virtuel. Ensemble, ces composants rationalisent les opérations DNS, garantissant une résolution de noms efficace et évolutive dans les environnements OCI, en particulier pour un scénario DNS hybride qui inclut des environnements multicloud et sur site intégrés.

Dans le prochain et dernier tutoriel de cette série, Ajouter la sécurité à l'architecture DNS à l'aide du pare-feu pfSense, nous améliorerons la sécurité de notre infrastructure DNS en configurant le pare-feu pfSense pour inspecter et contrôler toutes les requêtes DNS. Cela inclut 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 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

Use Oracle Cloud Infrastructure DNS to Resolve Native Domains

G16584-02