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.
Configuration du 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 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 versorastage.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
etoraclecloud.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 de BIND9
BIND9 (Berkeley Internet Name Domain version 9) est l'un des packages logiciels de serveur DNS (Domain Name System) les plus utilisés et les plus matures au monde. Il est développé et géré par Internet Systems Consortium (ISC). BIND9 sert d'épine dorsale à une grande partie de l'infrastructure DNS d'Internet, fournissant des services DNS robustes et fiables pour les déploiements à petite et à grande échelle.
La flexibilité, la robustesse et l'ensemble complet de fonctionnalités de BIND9 le rendent adapté à un large éventail d'applications DNS, des petits réseaux internes aux plus grands services DNS publics sur Internet.
Principales fonctionnalités de BIND9
-
Prise en charge des protocoles DNS : prend en charge toutes les principales fonctionnalités et protocoles DNS, notamment IPv4 et IPv6, DNSSEC (extensions de sécurité DNS) et TSIG (transaction SIGnature).
-
DNSSEC (extensions de sécurité DNS) : fournit des fonctionnalités de sécurité avancées pour protéger l'intégrité et l'authenticité des données DNS, empêchant ainsi les attaques telles que l'empoisonnement du cache et l'usurpation d'identité.
-
Évolutivité et performances : convient aux déploiements DNS de petite à très grande taille, avec des fonctionnalités permettant de gérer efficacement des charges de requête élevées et des zones volumineuses.
-
Flexibilité et personnalisation :
- Hautement configurable avec des options étendues pour affiner le comportement DNS, la gestion des zones et le traitement des requêtes.
- Prend en charge différents types de zones, notamment les zones maître (principale), esclave (secondaire) et stub.
-
DNS dynamique : prend en charge le DNS dynamique, permettant des mises à jour en temps réel des enregistrements DNS sans redémarrer le serveur.
-
Contrôle d'accès et sécurité :
- Implémente des listes de contrôle d'accès (ACL) pour restreindre l'accès aux services DNS et gérer les personnes pouvant interroger ou mettre à jour les zones.
- Prend en charge les vues pour fournir différentes réponses aux requêtes DNS en fonction de la source de la requête.
-
Journalisation et surveillance :
- Fonctionnalités de journalisation étendues pour le suivi des requêtes, des mises à jour et des performances du serveur.
- Intégration aux outils de surveillance pour garantir une haute disponibilité et un dépannage rapide.
-
Mise en cache : fournit des mécanismes de mise en cache robustes pour améliorer les performances et réduire la charge sur les serveurs DNS faisant autorité en mettant en cache les réponses DNS.
-
Transferts de zone : prend en charge les transferts de zone sécurisés entre les serveurs DNS à l'aide d'AXFR (transfert de zone complet) et d'IXFR (transfert de zone incrémentiel).
Cas d'utilisation courants de BIND9
-
Serveur DNS faisant autorité : héberge les enregistrements DNS pour les domaines, fournissant des réponses faisant autorité aux requêtes DNS.
-
Serveur DNS récursif : permet de résoudre les requêtes DNS pour les clients en interrogeant de manière récursive d'autres serveurs DNS.
-
Transfert du serveur DNS : transfère les requêtes DNS à d'autres serveurs DNS, souvent utilisés conjointement avec la mise en cache.
-
Serveur DNS secondaire (esclave) : conserve des copies des données de zone à partir d'un serveur principal, assurant la redondance et l'équilibrage de charge.
Installation et configuration de BIND9
-
Installation : BIND9 peut être installé sur différents systèmes d'exploitation, notamment Linux, UNIX et Windows. Il est disponible via les gestionnaires de packages sur la plupart des distributions Linux ou peut être compilé à partir d'une source.
-
Configuration : le fichier de configuration principal est
named.conf
, où les administrateurs définissent des zones, des contrôles d'accès, des options de journalisation et d'autres paramètres. Les fichiers de zone contiennent les enregistrements DNS réels pour chaque domaine.
Utiliser BIND9 sur OCI
Certains clients peuvent choisir d'utiliser et de gérer leur propre DNS (par exemple, BIND9) plutôt que d'utiliser les services DNS gérés par Oracle Cloud Infrastructure (OCI) pour plusieurs raisons :
-
Personnalisation et flexibilité :
-
Configurations avancées : les solutions DNS personnalisées telles que BIND9 offrent une configurabilité étendue, ce qui permet aux clients d'adapter leurs paramètres DNS à des exigences spécifiques qui ne sont peut-être pas prises en charge par les services gérés.
-
Fonctionnalités spécialisées : certaines entreprises ont besoin de fonctionnalités avancées telles que la journalisation des requêtes spécifiques, le contrôle d'accès détaillé ou les enregistrements DNS personnalisés que les services gérés peuvent ne pas fournir.
-
-
Considérations relatives aux coûts :
-
Gestion des coûts : le DNS autogéré peut être plus rentable, en particulier pour les entreprises ayant un trafic DNS important, car il permet d'éviter les coûts variables associés aux services gérés.
-
Dépenses prévisibles : l'exploitation de leurs propres serveurs DNS peut entraîner des coûts plus prévisibles, car ils n'ont besoin que de gérer les coûts d'infrastructure plutôt que de payer l'utilisation du DNS géré.
-
-
Contrôle et sécurité :
-
Contrôle total : les entreprises peuvent préférer avoir un contrôle total sur leur infrastructure DNS, y compris la possibilité d'implémenter des stratégies de sécurité personnalisées, une journalisation détaillée et des contrôles d'accès de niveau fin.
-
Confidentialité des données : dans les environnements hautement sensibles ou réglementés, le fait de garder le trafic DNS interne à son propre réseau peut être une exigence de sécurité pour garantir la confidentialité des données et la conformité aux réglementations.
-
-
Performances et fiabilité :
-
Optimisation des performances : le DNS autogéré permet aux entreprises d'optimiser les performances en configurant des réponses DNS propres à la mise en cache, à l'équilibrage de charge et à la géolocalisation, adaptées à leurs besoins.
-
Fiabilité : en gérant leurs propres serveurs DNS, les entreprises peuvent implémenter des configurations de haute disponibilité et des mesures de redondance qui correspondent à leurs exigences de fiabilité spécifiques.
-
-
Intégration à l'infrastructure existante :
-
Systèmes hérités : les entreprises disposant de systèmes hérités peuvent disposer d'une infrastructure DNS existante profondément intégrée à leurs autres systèmes et processus, ce qui facilite la gestion de leur propre DNS.
-
Intégrations personnalisées : le DNS autogéré permet une intégration transparente à d'autres applications personnalisées ou tierces nécessitant des interactions ou des configurations DNS spécifiques.
-
-
Exigences réglementaires et de conformité :
- Nécessités de conformité : Certains secteurs ont des exigences réglementaires strictes qui nécessitent un contrôle sur tous les aspects de leur infrastructure informatique, y compris le DNS, pour se conformer aux normes légales et de conformité.
-
Formation et expertise :
- Développement de compétences : certaines entreprises préfèrent conserver leur expertise et leurs connaissances internes en matière de gestion DNS, ce qui peut s'avérer utile pour le dépannage et l'optimisation de leur infrastructure informatique globale.
-
Evitement de verrouillage du fournisseur :
- Éviter le verrouillage : en gérant leur propre DNS, les entreprises peuvent éviter d'être enfermées dans l'écosystème d'un fournisseur spécifique, ce qui leur donne plus de flexibilité pour changer de fournisseur ou migrer des charges de travail sans reconfiguration significative.
Alors que les services DNS gérés par OCI offrent facilité d'utilisation, évolutivité et frais de gestion réduits, ces facteurs soulignent pourquoi certaines entreprises pourraient choisir de gérer leur propre infrastructure DNS.
Objectifs de configuration de BIND9 dans OCI
-
Introduction à BIND9 et à OCI
- Comprendre ce qu'est BIND9 et son rôle dans la gestion DNS.
- Bénéficiez d'une présentation d'Oracle Cloud Infrastructure (OCI) et de ses composants clés pertinents pour cette configuration.
-
Prérequis et configuration initiale
- Identifier et collecter les prérequis nécessaires au paramétrage.
- Configurez une instance OCI (machine virtuelle) pour héberger le serveur BIND9.
-
Configuration de l'environnement OCI
- Configurez les paramètres réseau de base dans OCI, c'est-à-dire les règles de routage et les passerelles pour établir une communication appropriée entre tous les serveurs et clients associés, ainsi que les listes de sécurité pour autoriser le trafic DNS.
-
Installation de BIND9 sur l'instance OCI
- Accédez à l'instance OCI via SSH.
- Installez les packages et dépendances nécessaires pour BIND9.
-
Configuration de BIND9
- Configurez les principaux fichiers de configuration BIND9 (
named.conf
). - Configurez les fichiers de zone pour les recherches DNS avancées.
- Configurez les principaux fichiers de configuration BIND9 (
-
Démarrage et gestion du service BIND9
- Démarrez le service BIND9 et configurez-le pour qu'il démarre à l'initialisation.
- Vérifiez que le service BIND9 fonctionne correctement.
-
Test du serveur DNS
- Utilisez des outils en ligne de commande (par exemple, dig, host) pour tester la résolution DNS.
- Assurez-vous que les recherches futures sont correctement configurées et opérationnelles.
-
Sécurisation du serveur BIND9
- Implémentez les meilleures pratiques pour sécuriser le serveur BIND9, y compris les contrôles d'accès.
-
Conclusion et ressources supplémentaires
- Résumez ce qui est fait.
- Fournir des ressources et des références supplémentaires pour l'apprentissage ultérieur.
Objectifs
-
A la fin de ce tutoriel, vous disposerez d'un serveur DNS BIND9 fonctionnel exécuté sur Oracle Cloud Infrastructure (OCI). Vous comprendrez les bases du DNS et le fonctionnement de BIND9, ce qui vous permettra de configurer, de gérer et de sécuriser un serveur BIND9 dans un environnement cloud. En outre, vous disposerez des connaissances nécessaires pour dépanner et gérer votre configuration DNS BIND9 dans OCI. Ce tutoriel vous aidera également à améliorer vos compétences en matière d'exploitation de divers composants OCI au sein des services de réseau et de calcul.
-
L'objectif principal de ce tutoriel est de permettre à FE-VM (
fe.orastage.com
) d'interroger BE-VM (be.orastage.com
), et inversement, avec Primary-DNS (primary-dns.orastage.com
) agissant en tant que serveur DNS faisant autorité.
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é et bastion.
-
Compréhension de base d'Ubuntu Linux et DNS en général.
-
Trois réseaux cloud virtuels sont requis avec un sous-réseau privé dans chacun.
- DNS-VCN : ce serveur hébergera le serveur DNS principal. En plus d'un DNS secondaire et d'un équilibreur de charge réseau.
- Frontend-VCN : cet élément hébergera l'un des clients. En plus d'un transitaire DNS OCI.
- VCN de back-end : cette option hébergera l'autre client. En plus d'un transitaire DNS OCI.
Tâche 1 : configurer les composants réseau de routage et de sécurité
Tâche 1.1 : créer des réseaux cloud virtuels
-
Assurez-vous que les réseaux cloud virtuels suivants sont déjà créés.
- DNS-VCN (
10.0.0.0/16
) contenant DNS-Private-Subnet (10.0.0.0/24
). - Frontend-VCN (
10.1.0.0/16
) contenant FE-Private-Subnet (10.1.0.0/24
). - VCN de back-end (
10.2.0.0/16
) contenant BE-Private-Subnet (10.2.0.0/24
).
- DNS-VCN (
-
Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
- Cliquez sur Fonctions de réseau.
- Cliquez sur Réseaux cloud virtuels.
-
Nous pouvons voir les réseaux cloud virtuels en place, chaque VCN n'a qu'un seul sous-réseau privé, ainsi que la table de routage et la liste de sécurité par défaut associées.
Tâche 1.2 : créer une passerelle de routage dynamique (DRG)
DRG est un routeur virtuel qui fournit un chemin pour le trafic privé d'un VCN à un autre, ou entre un VCN et un réseau sur site, ou même un VCN avec d'autres réseaux d'environnement cloud. Il s'agit donc d'un composant puissant et essentiel pour chaque environnement réseau OCI. Dans ce tutoriel, nous allons l'utiliser pour établir la connectivité entre plusieurs réseaux cloud virtuels de la même région.
-
Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
- Cliquez sur Fonctions de réseau.
- Cliquez sur Passerelle de routage dynamique.
-
Cliquez sur Créer une passerelle de routage dynamique.
- Entrez un nom pour DRG.
- Cliquez sur Créer une passerelle de routage dynamique.
-
Le DRG a été créé.
Tâche 1.3 : attacher des réseaux cloud virtuels au DRG
-
Sur la page de détails DRG, créez des attachements de réseau cloud virtuel. Pour créer, cliquez sur Créer un attachement de réseau cloud virtuel.
-
Pièce jointe DNS-VCN :
-
Connexion Frontend-VCN :
-
Pièce jointe Backend-VCN :
-
-
Tous les réseaux cloud virtuels sont attachés. Par défaut, ces attachements utilisent la table de routage DRG générée automatiquement, qui permet à chaque attachement d'apprendre dynamiquement les acheminements vers d'autres réseaux cloud virtuels.
-
Tous les réseaux cloud virtuels doivent pouvoir se connecter les uns aux autres. Nous devons donc faciliter la communication entre eux en utilisant certaines règles de route et de sécurité. Dans la tâche 1.4, la tâche 1.5 et la tâche 1.6, nous allons :
- Autorisez l'accès SSH pour nous permettre de nous connecter aux instances.
- Autorisez le trafic DNS là où il est nécessaire.
- Ping trafic à autoriser là où il est nécessaire.
- Fournissez un accès Internet sortant là où il est nécessaire.
- Assurez-vous que chaque instance de calcul doit pouvoir atteindre l'autre via DRG.
Tâche 1.4 : configuration du routage et de la sécurité pour DNS-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 DNS-VCN.
-
Cliquez sur le sous-réseau privé.
-
Cliquez sur Table de routage, qui est une table de routage affectée.
-
Veillez à ajouter les règles suivantes.
0.0.0.0/0
- Passerelle NAT : pour disposer d'un accès unidirectionnel à Internet, installez les packages/patches si nécessaire. Dans ce tutoriel, nous avons besoin de cet accès pour installer le package BIND9 sur le serveur Primary-DNS.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.
-
Si aucune passerelle NAT n'est créée, suivez les étapes ci-dessus pour en créer une avant d'ajouter la règle de routage.
- Accédez à la page de détails DNS-VCN et cliquez sur Passerelles NAT.
- Cliquez sur Créer une passerelle NAT.
-
Saisissez les informations suivantes .
- Entrez un nom pour une passerelle NAT.
- Sélectionnez Adresse IP publique éphémère.
- Cliquez sur Créer une passerelle NAT.
La passerelle NAT a été créée.
-
Comme nous avons terminé la partie de routage pour le sous-réseau DNS-VCN, assurons-nous la sécurité maintenant. Accédez à la page Détails du sous-réseau et cliquez sur la liste de sécurité affectée.
-
Veillez à autoriser le trafic entrant.
- Trafic SSH depuis n'importe où (port 22).
- Trafic DNS à partir de Frontend-VCN et Backend-VCN (TCP/port 53 et UDP/port 53).
-
Assurez-vous d'autoriser tout le trafic sortant.
Tâche 1.5 : configuration du routage et de la sécurité pour le VCN frontal
-
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 Frontend-VCN.
-
Cliquez sur le sous-réseau privé.
-
Cliquez sur Table de routage, qui est une table de routage affectée.
-
Veillez à ajouter les règles suivantes.
0.0.0.0/0
: passerelle NAT : pour disposer d'un accès unidirectionnel à Internet, nous en avons besoin ici pour que FE-VM** puisse utiliser le service OCI Bastion. L'utilisation d'une passerelle de service peut également effectuer le travail.10.0.0.0/16
- DRG : acheminez le trafic destiné à DNS-VCN vers le DRG.10.2.0.0/16
- DRG : acheminez le trafic vers le DRG vers le VCN de back-end.
-
Si aucune passerelle NAT n'est créée, suivez les étapes de la tâche 1.4 pour en créer une avant d'ajouter la règle de routage à l'étape ci-dessus.
-
Comme nous avons terminé la partie de routage pour Frontend-VCN, assurons-nous la sécurité maintenant. Accédez à la page Détails du sous-réseau et cliquez sur la liste de sécurité affectée.
-
Veillez à autoriser le trafic entrant.
- Trafic SSH depuis n'importe où (port 22).
- Envoyez une commande ping au trafic à partir de Backend-VCN (ICMP, type 8), nous aurons besoin de cette règle lors de la phase de test.
-
Assurez-vous d'autoriser tout le trafic sortant.
Tâche 1.6 : configuration du routage et de la sécurité pour le back-end 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 VCN de back-end.
-
Cliquez sur le sous-réseau privé.
-
Cliquez sur Table de routage, qui est une table de routage affectée.
-
Veillez à ajouter les règles suivantes.
0.0.0.0/0
- Passerelle NAT : pour disposer d'un accès unidirectionnel à Internet, nous en avons besoin ici pour que BE-VM puisse utiliser le service OCI Bastion. L'utilisation d'une passerelle de service peut également effectuer le travail.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.
-
Si aucune passerelle NAT n'est créée, suivez les étapes de la tâche 1.4 pour en créer une avant d'ajouter la règle de routage à l'étape ci-dessus.
-
Comme nous avons terminé la partie de routage pour Backend-VCN, assurons la sécurité maintenant. Accédez à la page Détails du sous-réseau et cliquez sur la liste de sécurité affectée.
-
Veillez à autoriser le trafic entrant.
- Trafic SSH depuis n'importe où (port 22).
- Envoyez une commande ping au trafic à partir de Frontend-VCN (ICMP, type 8), nous aurons besoin de cette règle lors de la phase de test.
-
Assurez-vous d'autoriser tout le trafic sortant.
-
Les composants réseau de base sont désormais prêts (réseaux cloud virtuels, sous-réseaux, tables de routage, DRG et listes de sécurité). Maintenant, l'architecture doit se présenter comme indiqué dans l'image suivante.
Tâche 2 : provisionnement d'une instance OCI Compute
Provisionnez une instance de calcul dans laquelle BIND9 sera configuré.
Tâche 2.1 : génération de la paire de clés SSH
Vous devez effectuer cette opération avant de créer l'instance. Les clés SSH seront utilisées pour l'authentification auprès des instances de calcul Linux. Vous pouvez générer les clés à l'aide de l'outil PuTTYgen sur une machine Windows ou de l'utilitaire ssh-keygen sur n'importe quelle machine. Dans ce tutoriel, nous allons utiliser ssh-keygen dans OCI Cloud Shell.
-
Cliquez sur Cloud Shell.
-
Exécutez la commande
ssh-keygen
pour générer une paire de clés. -
Accédez au répertoire
.ssh
par défaut à l'aide de la commandecd .ssh
et copiez le contenu du fichier de clé publiqueid_rsa.pub
. Nous allons l'utiliser dans la tâche 2.2.
Tâche 2.2 : provisionnement de l'instance de calcul DNS principale
-
Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
- Cliquez sur Calculer.
- Cliquez sur Instances.
-
Cliquez sur Créer une instance.
-
Saisissez un nom pour l'instance.
-
Sélectionnez Ubuntu 20.04 comme système d'exploitation de l'instance.
-
Dans Réseau principal, entrez les informations suivantes.
- Sélectionnez DNS-VCN.
- Sélectionner un sous-réseau privé.
-
Affectez à l'instance une adresse IP privée
10.0.0.10
. -
Collez la clé publique générée dans la tâche 2.1.
-
Faites défiler la page jusqu'à la fin et cliquez sur Afficher les options avancées.
-
Cliquez sur Agent Oracle Cloud.
- Sélectionnez le module d'extension Bastion, car nous utiliserons Bastion ultérieurement pour accéder à l'instance.
- Cliquez sur Créer.
-
L'instance de calcul Primary-DNS a été créée.
-
L'architecture doit se présenter comme indiqué dans l'image suivante.
Dans les tâches ultérieures, nous allons installer et configurer BIND9 dans l'instance Primary-DNS.
Tâche 3 : installer et configurer BIND9
Tâche 3.1 : accéder à l'instance de calcul DNS principale à l'aide de Bastion
-
Tout d'abord, nous devons établir l'accès via SSH à l'instance de calcul pour installer et configurer BIND9. Cependant, comme nous avons créé l'instance dans un sous-réseau privé, nous ne pouvons pas y accéder directement à partir de n'importe où car elle ne dispose pas d'adresse IP publique. Pour cela, nous utiliserons un autre service OCI.
OCI Bastion est un service géré qui agit en tant qu'intermédiaire, permettant un accès sécurisé aux ressources au sein d'un réseau privé. Il est particulièrement utile pour une utilisation administrative nécessitant un accès à des ressources qui ne sont pas exposées au réseau Internet public. Vous pouvez le considérer comme Jump Server as a Service.
- Cliquez sur Identité et sécurité.
- Cliquez sur Bastion.
-
Cliquez sur Créer un bastion.
-
Saisissez les informations suivantes .
- Entrez un nom de bastion.
- Sélectionnez le VCN (DNS-VCN) et son sous-réseau.
- La liste d'autorisation de bloc CIDR est la plage d'adresses IP autorisées à partir de laquelle nous devons nous connecter au bastion. Ici, nous avons utilisé
0.0.0.0/0
pour cette implémentation. Pour être plus précis, nous pouvons choisir l'adresse IP publique à partir de laquelle nous sommes connectés. - Cliquez sur Créer un bastion.
-
Le bastion est créé. Nous devons créer une session qui nous permet de nous connecter à une ressource cible (DNS principal) pendant une durée spécifique (la valeur par défaut est de 3 heures).
-
Saisissez les informations suivantes .
- Type de session : sélectionnez Session SSH gérée.
- Nom de session : entrez le nom de la session.
- Nom utilisateur : Entrez le nom utilisateur. Pour l'instance Ubuntu Linux, le nom utilisateur par défaut est ubuntu.
- Instance de calcul : sélectionnez l'instance DNS principal créée dans la tâche 2.2.
- Collez la même clé publique que celle générée dans la tâche 2.1.
- 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-1.amaaaaaaldij5aiaa6buxxxxxxxxxxxxxxxxxxrlnywmo3n2pty5wpf7fq@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 ubuntu@10.0.0.10
-
Ouvrez OCI Cloud Shell.
- Accédez au répertoire
.ssh
à l'aide de la commandecd .ssh
. - Collez la commande SSH. Veillez à remplacer
<privateKey>
par le nom de fichier de clé privéeid_rsa
.
- Accédez au répertoire
-
Connexion réussie
Tâche 3.2 : installer BIND9
Une fois l'instance accédée, nous allons installer BIND9 et nous assurer qu'elle est en cours d'exécution.
-
Exécutez les commandes suivantes .
sudo apt update sudo apt install bind9 bind9utils bind9-doc bind9-host
-
Exécutez la commande
sudo systemctl status named
pour vérifier le statut du service BIND9. Il est actif (en cours d'exécution). -
Exécutez la commande
sudo systemctl enable named
pour activer le service afin qu'il démarre automatiquement après le redémarrage.
Tâche 3.3 : modification du nom de domaine qualifié complet de l'instance
-
Pour modifier le nom de domaine qualifié complet de l'instance, accédez au fichier hosts à l'aide de la commande
sudo vi /etc/hosts
et ajoutez la ligne suivante.10.0.0.10 primary-dns.orastage.com primary-dns
-
Pour vérifier la modification, exécutez la commande
hostname -f
pour afficher le nouveau nom de domaine qualifié complet.
Tâche 3.4 : configurer le fichier named.conf.options
-
Ajoutez la configuration.
-
Ajoutez les lignes suivantes à la fin du fichier
/etc/bind/named.conf.options
et enregistrez le fichier.recursion yes; notify yes; allow-query { any; }; allow-query-cache { any; }; allow-recursion { any; }; forwarders { 8.8.8.8; }; auth-nxdomain no; # conform to RFC1035 listen-on { localhost; any; }; allow-transfer { any; };
-
Redémarrez le service BIND9.
-
Vérifiez le statut du service.
-
Tâche 3. 5 : utilisez netstat
pour afficher le statut des ports TCP/UDP
net-tools est un ensemble d'utilitaires de ligne de commande qui fournissent un ensemble d'outils réseau essentiels pour le système d'exploitation Linux.
-
Exécutez la commande
sudo apt install net-tools
pour installer net-tools. Cette opération est nécessaire pour pouvoir utiliser la commandenetstat
. -
Exécutez la commande
sudo netstat -antu
pour vérifier les ports/protocoles que l'instance écoute. Comme vous pouvez le voir dans l'image suivante, pour l'adresse IP10.0.0.10
, TCP/port 53 et UDP/port 53 doivent être ouverts.
Tâche 3.6 : configurer le fichier named.conf.local
-
Ajoutez les lignes suivantes à la fin du fichier
/etc/bind/named.conf.local
.zone "orastage.com" { type master; allow-transfer { any; }; file "/var/lib/bind/db.orastage.com"; };
Tâche 3.7 : configurer le fichier db.orastage.com
-
Le fichier
db.orastage.com
n'existe pas encore. Pour créer, exécutez la commandesudo vi /var/lib/bind/db.orastage.com
et ajoutez le contenu suivant au fichier.$TTL 1D @ IN SOA primary-dns.orastage.com. admin.orastage.com. ( 329 ; serial 604800 ; refresh (1 week) 86400 ; retry (1 day) 2419200 ; expire (4 weeks) 604800 ; minimum (1 week) ) IN NS primary-dns.orastage.com. primary-dns IN A 10.0.0.10 fe IN A 10.1.0.5 be IN A 10.2.0.5
Tâche 3.8 : configuration du fichier 50-cloud-init.yaml
-
Accédez au fichier
/etc/netplan/50-cloud-init.yaml
et ajoutez les lignes suivantes.nameservers: addresses: [10.0.0.10] search: [orastage.com]
-
Exécutez la commande
sudo netplan apply
pour que les modifications prennent effet.
Tâche 3.9 : désactiver le pare-feu iptables
-
Nous allons désactiver iptables temporairement uniquement pour ce tutoriel afin d'éviter tout type de problème de connectivité pendant la phase de test.
-
Exécutez la commande
sudo su
pour passer à l'utilisateur root. -
Pour enregistrer une sauvegarde des règles de pare-feu existantes, exécutez la commande
iptables-save > /root/firewall_rules.backup
. -
Exécutez la commande suivante pour effacer toutes les règles et autoriser tout le trafic via le pare-feu.
iptables -F iptables -X iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT
-
Une fois la tâche 6 terminée, exécutez la commande
iptables-restore < /root/firewall_rules.backup
pour restaurer les règles de pare-feu. -
Après avoir effacé les règles, nous devons nous assurer que cette modification sera persistante après la réinitialisation. Exécutez donc la commande
apt install iptables-persistent
pour installer le package. -
Exécutez la commande
iptables-save > /etc/iptables/rules.v4
. -
Pour voir les règles iptables, exécutez la commande
iptables -L
. Elle doit être vide.
-
Tâche 3.10 : redémarrer BIND9
-
Exécutez la commande suivante pour redémarrer le service.
sudo systemctl restart named
Tâche 3.11 : Test
-
Effectuez plusieurs tests pour interroger les noms de domaine que nous avons ajoutés au fichier
db.orastage.com
et voir s'il répond à la requête localement.-
Domaine
orastage.com
:host -a orastage.com
. -
Domaine
Primary-DNS
:host -a primary-dns.orastage.com
. -
Domaine
FE-VM
:host -a fe.orastage.com
. -
Domaine
BE-VM
:host -a be.orastage.com
.
-
Tâche 4 : configuration des adresses et des règles de transfert OCI
Chaque VCN OCI dispose d'un résolveur par défaut qui peut être utilisé pour résoudre les noms d'hôte dans le même VCN, différents réseaux cloud virtuels, réseaux sur site ou même des noms d'hôte publiés publiquement sur Internet. Dans cette tâche, nous allons utiliser deux composants dans le résolveur pour répondre à notre exigence de transmission de requêtes à l'instance BIND9 Primary-DNS, à savoir :
- Adresse de transfert : permet au résolveur DNS d'interroger un DNS distant tel que défini dans les règles de transfert.
- Règle de transfert : permet de contrôler la façon dont les requêtes DNS sont gérées lorsque les vues privées du résolveur ne répondent pas à la requête. Sur quel serveur DNS distant les requêtes vers
orastage.com
seront-elles transférées vers et à l'aide de quelle adresse de transfert ?
Tâche 4.1 : configuration de l'adresse et de la règle de transfert pour le VCN frontal
Créez une règle et une adresse de transfert dans Frontend-VCN, pour pointer les requêtes orastage.com
de FE-VM vers l'instance Primary-DNS.
-
Accédez au VCN frontal et cliquez sur Résolveur DNS.
-
Cliquez sur Créer une adresse.
-
Saisissez les informations suivantes .
- Nom : entrez le nom de l'adresse.
- Sous-réseau : sélectionnez le sous-réseau privé du VCN.
- Type d'adresse : sélectionnez Transfert.
- Adresse IP de transfert : entrez
10.1.0.6
. - Cliquez sur Créer une adresse.
-
L'adresse de transfert (FWD) a été créée.
-
Cliquez sur Règles et sur Gérer les règles.
-
Saisissez les informations suivantes .
- Condition de règle : sélectionnez Domaines.
- Domaines : entrez le domaine
orastage.com
. - Adresse source : sélectionnez l'adresse de transfert.
- Adresse IP de destination : entrez l'adresse IP de l'instance BIND9
10.0.0.10
.
-
La règle de transfert a été créée.
Tâche 4.2 : configuration de l'adresse et de la règle de transfert pour le back-end VCN
Créez une règle et une adresse de transfert dans Backend-VCN, pour pointer les requêtes orastage.com
de BE-VM vers l'instance Primary-DNS.
- Accédez au VCN de back-end et cliquez sur Résolveur DNS.
-
Cliquez sur Créer une adresse.
-
Saisissez les informations suivantes .
- Nom : entrez le nom de l'adresse.
- Sous-réseau : sélectionnez le sous-réseau privé du VCN.
- Type d'adresse : sélectionnez Transfert.
- Adresse IP de transfert : entrez
10.2.0.6
. - Cliquez sur Créer une adresse.
-
L'adresse de transfert (FWD) a été créée.
-
Cliquez sur Règles et sur Gérer les règles.
-
Saisissez les informations suivantes .
- Condition de règle : sélectionnez Domaines.
- Domaines : entrez le domaine
orastage.com
. - Adresse source : sélectionnez l'adresse de transfert.
- Adresse IP de destination : entrez l'adresse IP de l'instance BIND9
10.0.0.10
.
-
La règle de transfert a été créée.
-
L'architecture doit se présenter comme indiqué dans l'image suivante.
Tâche 5 : provisionnement des instances client pour exécuter des requêtes DNS
Tâche 5.1 : créer une instance de calcul FE-VM
-
Cliquez sur le menu hamburger (≡) dans le coin supérieur gauche.
- Cliquez sur Calculer.
- Cliquez sur Instances.
-
Cliquez sur Créer une instance.
-
Saisissez un nom pour l'instance.
-
Sélectionnez Oracle Linux 8 comme système d'exploitation de l'instance.
-
Dans Réseau principal, entrez les informations suivantes.
- Sélectionnez Frontend-VCN.
- Sélectionnez le sous-réseau privé.
-
Affectez à l'instance une adresse IP privée
10.1.0.5
. -
Collez la clé publique générée dans la tâche 2.1.
-
Faites défiler la page jusqu'à la fin et cliquez sur Afficher les options avancées.
-
Cliquez sur Agent Oracle Cloud.
-
Sélectionnez le module d'extension Bastion, car nous allons utiliser Bastion pour accéder à l'instance et cliquer sur Créer.
-
L'instance de calcul FE-VM a été créée.
Tâche 5.2 : créer une instance de calcul BE-VM
-
Cliquez sur Instance et sur Créer une instance.
-
Saisissez un nom pour l'instance.
-
Sélectionnez Oracle Linux 8 comme système d'exploitation de l'instance.
-
Dans Réseau principal, entrez les informations suivantes.
- Sélectionnez VCN de back-end.
- Sélectionnez le sous-réseau privé.
-
Affectez à l'instance une adresse IP privée
10.2.0.5
. -
Collez la clé publique générée dans la tâche 2.1.
-
Faites défiler la page jusqu'à la fin et cliquez sur Afficher les options avancées.
-
Cliquez sur Agent Oracle Cloud.
-
Sélectionnez le module d'extension Bastion, car nous allons utiliser Bastion pour accéder à l'instance et cliquer sur Créer.
-
L'instance de calcul BE-VM a été créée.
-
L'architecture est terminée.
Remarque : dans les tâches suivantes, nous testerons plusieurs scénarios et vérifierons que la configuration fonctionne comme prévu.
Tâche 6 : tester et valider
Tâche 6.1 : accéder à l'instance de calcul FE-VM à l'aide du bastion et du test
-
La machine client FE-VM doit pouvoir résoudre
be.orastage.com
.- Cliquez sur Identité et sécurité.
- Cliquez sur Bastion.
-
Cliquez sur Créer un bastion.
-
Saisissez les informations suivantes .
- Nom du bastion : entrez le nom du bastion.
- Configurer la mise en réseau : sélectionnez le VCN (Frontend-VCN) et son sous-réseau.
- La liste d'autorisation de bloc CIDR est la plage d'adresses IP autorisées à partir de laquelle nous devons nous connecter au bastion. Ici, nous avons utilisé
0.0.0.0/0
pour cette implémentation. Pour être plus précis, nous pouvons choisir l'adresse IP publique à partir de laquelle nous sommes connectés. - Cliquez sur Créer un bastion.
-
Le bastion est créé. Nous devons créer une session pour nous connecter à une ressource cible (FE-VM) pendant une durée spécifique (la valeur par défaut est de 3 heures).
-
Saisissez les informations suivantes .
- Type de session : sélectionnez Session SSH gérée.
- Nom de session : Entrez un nom.
- Nom utilisateur : Entrez le nom utilisateur. Pour l'instance Oracle Linux, l'utilisateur par défaut est
opc
. - Instance de calcul : sélectionnez l'instance FE-VM créée dans la tâche 5.
- Collez la même clé publique générée dans la tâche 2.1.
- 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-1.amaaaaaaldij5aiaskfyan4yj7yx3bmm57rckmvvawikppba5mxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5
- Open the cloud shell, and navigate to the
.ssh
directory usingcd .ssh
command. - Collez la commande SSH et veillez à remplacer
<privateKey>
par le nom de fichier de clé privéeid_rsa
. - Saisissez yes et cliquez sur Enter.
- Open the cloud shell, and navigate to the
-
Testez les requêtes
orastage.com
de FE-VM àbe.orastage.com
. Vous pouvez valider la configuration à l'aide de différentes méthodes.- Exécuter la commande
host
. - Exécutez la commande
ping
. - Exécutez la commande
dig
.
- Exécuter la commande
Comme indiqué dans le test ci-dessus, nous pouvons récupérer l'adresse IP du domaine BE-VM et le ping fonctionne à l'aide du nom d'hôte, ce qui signifie que le test réussit.
Tâche 6.2 : accéder à l'instance de calcul BE-VM à l'aide du bastion et du test
-
L'ordinateur client BE-VM doit pouvoir résoudre
fe.orastage.com
.- Cliquez sur Identité et sécurité.
- Cliquez sur Bastion.
-
Cliquez sur Créer un bastion.
-
Saisissez les informations suivantes .
- Nom du bastion : entrez le nom du bastion.
- Configurer la mise en réseau : sélectionnez le VCN (VCN back-end) et son sous-réseau.
- La liste d'autorisation de bloc CIDR est la plage d'adresses IP autorisées à partir de laquelle nous devons nous connecter au bastion. Ici, nous avons utilisé
0.0.0.0/0
pour cette implémentation. Pour être plus précis, nous pouvons choisir l'adresse IP publique à partir de laquelle nous sommes connectés. - Cliquez sur Créer un bastion.
-
Le bastion est créé. Nous devons créer une session pour nous connecter à une ressource cible (BE-VM) pendant une durée spécifique (la valeur par défaut est de 3 heures).
-
Saisissez les informations suivantes .
- Type de session : sélectionnez Session SSH gérée.
- Nom de session : Entrez un nom.
- Nom utilisateur : Entrez le nom utilisateur. Pour l'instance Oracle Linux, l'utilisateur par défaut est
opc
. - Instance de calcul : sélectionnez l'instance BE-VM créée à l'étape 06.
- Collez la même clé publique générée dans la tâche 2.1.
- 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-1.amaaaaaaldij5aia73xclnp6h6i2mjnpsuer2bnz4cblejfemnr6uk7pafla@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5
- Open the cloud shell, and navigate to the
.ssh
directory using thecd .ssh
command. - Collez la commande SSH et veillez à remplacer
<privateKey>
par le nom de fichier de clé privéeid_rsa
. - Saisissez yes et cliquez sur Enter.
- Open the cloud shell, and navigate to the
-
Testez les requêtes
orastage.com
de BE-VM àfe.orastage.com
. Vous pouvez valider la configuration à l'aide de différentes méthodes.- Exécuter la commande
host
. - Exécutez la commande
ping
. - Exécutez la commande
dig
.
- Exécuter la commande
Comme indiqué dans le test ci-dessus, nous pouvons récupérer l'adresse IP du domaine FE-VM et le ping fonctionne à l'aide du nom d'hôte, ce qui signifie que le test réussit.
Etapes suivantes
Dans ce tutoriel, nous avons mis en place une petite architecture DNS BIND9 avec des composants de base : configuration de serveur et de client dans Oracle Cloud Infrastructure. Tout au long de ce segment, vous avez pu obtenir des informations sur le routage et la sécurité du réseau OCI, en traitant différents composants tels que les tables de routage, le DRG, les listes de sécurité, le bastion, etc. Vous avez également appris à installer et configurer un DNS BIND9 fonctionnel dans un environnement OCI.
Dans le tutoriel suivant : Tutoriel 2 : Implémentation de la haute disponibilité sur le système de noms de domaine BIND9 dans Oracle Cloud Infrastructure, nous améliorerons cette configuration en intégrant la couche de haute disponibilité à notre architecture, ce qui est crucial pour réduire les temps d'arrêt et améliorer l'expérience utilisateur.
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.
Configure BIND9 Domain Name System in Oracle Cloud Infrastructure
G13018-03
Copyright ©2025, Oracle and/or its affiliates.