Documentation Oracle Cloud Infrastructure

DNS privé

Créez et gérez des zones DNS privées.

Utilisez des zones de service de noms de domaine privé (DNS) pour créer des zones privées avec des noms de domaine que vous spécifiez. Vous pouvez gérer entièrement les zones et les enregistrements afin de fournir une résolution de nom d'hôte pour les applications exécutées dans et entre les réseaux cloud virtuels (Réseaux cloud virtuels ) et les réseaux sur site ou autres réseaux privés. Traffic Management est disponible uniquement pour les DNS publics et n'est pas pris en charge sur les DNS privés.

Le DNS privé fournit également une résolution DNS sur plusieurs réseaux (par exemple, sur un autre réseau cloud virtuel au sein de la même région, dans une autre région ou sur un réseau externe). Le DNS privé peut être géré dans la console et l'API DNS d'OCI.

Ressources utilisées dans le DNS privé

Ressources DNS
  • Zones DNS privées : les zones DNS privées contiennent des données DNS accessibles uniquement à partir d'un réseau cloud virtuel (VCN) tel que des adresses IP privées. Une zone de DNS privée offre les mêmes fonctionnalités qu'une zone DNS Internet, mais fournit des réponses uniquement aux clients qui peuvent l'atteindre via un réseau cloud virtuel. Chaque zone appartient à une vue unique.
  • Enregistrements de zone DNS privée : différents types d'enregistrement sont pris en charge pour les DNS globaux et privés. Reportez-vous à Enregistrements de ressource pris en charge.
  • Vues DNS privées : une vue DNS privée est un ensemble de zones privées. Un même nom de zone peut être utilisé dans de nombreuses vues, mais les noms de zone d'une même vue doivent être uniques.

  • Résolveur DNS privé : un résolveur DNS privé dédié au VCN contient la configuration qui sert les réponses aux requêtes DNS dans le VCN. Les vues sur le résolveur déterminent la zone et les données d'enregistrement applicables à la résolution. Les adresses du résolveur fournissent une autre entrée et une autre sortie en plus de l'entrée par défaut sur 169.254.169.254. Pour plus d'informations, reportez-vous à Résolveurs DNS privés.

  • Adresse de résolveur DNS privé : utilisez des ressources d'adresse de résolveur pour configurer l'entrée et la sortie dans le VCN. Les adresses de résolveur utilisent les adresses IP du sous-réseau dans lequel elles sont créées. Une carte d'interface réseau virtuelle correspondante est créée pour chaque adresse de résolveur.
Ressources VCN :
  • VCN : lorsque vous créez un VCN, un résolveur dédié est également créé automatiquement.
  • Sous-réseau : un sous-réseau dans un VCN est utilisé lors de la création d'adresses de résolveur. Les adresses IP du sous-réseau sont utilisées pour l'écoute et la transmission d'adresses.
  • Groupe de sécurité réseau : vous pouvez éventuellement configurer la liste des groupes de sécurité réseau pour les adresses de résolution. Les groupes de sécurité réseau contrôlent le trafic entrant et sortant vers et depuis l'adresse de résolveur.

Pour plus d'informations sur les ressources VCN, reportez-vous à Résolveurs DNS privés dans la documentation Networking.

Ressources protégées

Certaines ressources de DNS privé, telles que les zones et les vues, sont protégées. Les ressources protégées sont gérées automatiquement par Oracle. Vous pouvez visualiser les ressources protégées, mais la modification est limitée. Les ressources protégées ne sont pas prises en compte dans les limites de service ou les quotas.
  • Tous les résolveurs dédiés au VCN
  • Vues par défaut : chaque résolveur dédié au VCN dispose d'une vue par défaut protégée. Vous pouvez ajouter d'autres zones à la vue par défaut, mais des restrictions s'appliquent aux noms de zone pour éviter les conflits avec des zones protégées. Si un résolveur est supprimé et que sa vue par défaut contient des zones non protégées, la vue par défaut est convertie en vue non protégée au lieu d'être supprimée. Vous pouvez créer et attacher une vue à un résolveur en plus de la vue par défaut afin que leurs zones puissent être résolues dans le VCN.

Configuration et résolution

DNS

Vous pouvez créer une arborescence de domaine complète ou partielle. Une vue peut être utilisée par n'importe quel nombre de résolveurs et peut partager des données de DNS privé dans les réseaux cloud virtuels au sein d'une même région. Vous pouvez utiliser ces zones pour le DNS fractionné car un même nom de zone peut être utilisé sur une zone privée et une zone Internet. Différentes réponses peuvent être fournies pour les requêtes publiques et privées à partir d'un VCN.

Le résolveur écoute sur 169.254.169.254 par défaut. Vous pouvez décider de définir des adresses de résolveur pour plus d'entrées et de sorties. Une adresse de résolveur d'écoute utilise une adresse IP pour l'écoute dans le sous-réseau spécifié. Une adresse de résolveur de transfert consomme deux adresses IP, une adresse n'est pas utilisée et la deuxième adresse est utilisée pour le transfert. Avant de créer une adresse de résolveur, assurez-vous que suffisamment d'adresses IP sont disponibles dans le sous-réseau.
Important

Le sous-réseau des adresses DNS privées doit être IPv4 uniquement. Echec de la demande de création d'une adresse DNS privée dans un sous-réseau compatible IPv6.

Ajoutez des règles pour définir la logique de réponse aux requêtes. Le seul type de règle pris en charge est FORWARD. Cette règle transmet conditionnellement une requête à une adresse IP de destination en fonction de l'adresse IP client ou du QNAME cible. L'adresse IP de destination peut être pour une configuration sur site, un réseau privé ou une adresse de résolveur d'écoute dans un autre VCN. La règle de résolveur qnameCoverConditions couvre les correspondances exactes ainsi que les sous-domaines.

Les réponses DNS dans un réseau cloud virtuel sont évaluées à l'aide de la configuration du résolveur dédié dans un ordre spécifique :
  1. Chaque vue attachée est évaluée dans l'ordre. La vue par défaut est évaluée en dernier, si elle n'est pas explicitement incluse dans la liste.
  2. Les règles de résolveur sont évaluées dans l'ordre. La première règle de résolveur qui correspond à la vue est appliquée. Toute règle située plus loin dans la liste avec des conditions en double (y compris aucune condition) par rapport à une précédente n'est jamais évaluée. Un exemple de règle inaccessible est une règle qnameCoverCondition ou clientAddressConditions plus spécifique après une règle plus générale. Si la règle plus générale est une correspondance, la règle plus spécifique n'est jamais évaluée.
  3. La requête est résolue sur Internet.
Le premier élément dans l'ordre pouvant fournir une réponse le fait. Une fois qu'une réponse est fournie, aucun autre élément n'est évalué, même si la réponse est négative.

Par exemple, si un nom de requête est inclus par une zone dans une vue privée et qu'il n'existe pas dans la zone, cette dernière renvoie une réponse NXDOMAIN faisant autorité.

Réseau cloud virtuel

L'entrée et la sortie entre les réseaux cloud virtuels ou entre les réseaux cloud virtuels et les réseaux sur site nécessitent une connectivité. L'établissement d'une connexion peut nécessiter une passerelle d'appairage local ou une passerelle d'appairage à distance entre les réseaux cloud virtuels. La connexion entre un VCN et des réseaux sur site nécessite FastConnect ou un tunnel IPSec (VPN IPSec).

Les listes de sécurité de réseau cloud virtuel et tous les groupes de sécurité réseau référencés doivent autoriser le trafic requis. DHCP sur la liste de sécurité doit être activé pour l'entrée et la sortie, et inclure l'adresse IP de l'adresse de résolveur correspondante. Les règles de sécurité pour les adresses d'écoute doivent autoriser l'entrée UDP sans connexion sur le port de destination 53, la sortie UDP sans connexion sur le port source 53 et l'entrée TCP sur le port de destination 53. Les règles de sécurité pour les adresses de transmission doivent autoriser la sortie UDP sans connexion sur le port de destination 53, l'entrée UDP sans connexion sur le port source 53 et la sortie TCP sur le port de destination 53.

Pour plus d'informations et de tutoriels, reportez-vous aux pages suivantes :

Cas d'emploi

Zones DNS personnalisées dans un réseau cloud virtuel

Les zones DNS privées sont regroupées dans des vues . Tous les résolveurs dédiés à un réseau cloud virtuel disposent d'une vue par défaut qui est créée automatiquement. Pour créer une zone DNS personnalisée qui est résolue dans un réseau cloud virtuel, créez la zone privée dans la vue par défaut du résolveur dédié, ou créez la zone dans une nouvelle vue et ajoutez cette dernière à la liste des vues attachées du résolveur dédié. Pour obtenir un guide détaillé sur cette configuration, reportez-vous à Centre d'aide - Configuration de résolveurs et de vues de zones DNS privés.

Fractionnement

Créez des zones privées portant le même nom que les noms publics sur Internet. Ensuite, ajoutez les zones à l'une des vues du résolveur de réseau cloud virtuel . Dans le réseau cloud virtuel, les noms sont résolus en fonction de la configuration du DNS privé. Les mêmes noms donnent des réponses différentes en fonction de l'origine de la demande.

Zones DNS privées partagées dans une région

Les réseaux cloud virtuels d'une même région peuvent résoudre mutuellement les demandes de leurs vues privées. Par exemple, supposons que vous vouliez implémenter cette solution avec les réseaux cloud virtuels A et B. Ajoutez la vue par défaut du résolveur dédié du réseau cloud virtuel A aux vues attachées du résolveur dédié du réseau cloud virtuel B. Ensuite, ajoutez la vue par défaut du résolveur dédié du réseau cloud virtuel B aux vues attachées du résolveur dédié du réseau cloud virtuel A.

Vous pouvez réutiliser la même zone privée ou le même ensemble de zones privées dans plusieurs réseaux cloud virtuels. Cette solution peut réduire la duplication de la configuration du DNS. Créez une vue et ajoutez-lui des zones privées. Pour chaque réseau cloud virtuel, ajoutez la nouvelle vue à la liste des vues attachées du résolveur dédié du réseau cloud virtuel. Pour obtenir un guide détaillé sur cette configuration, reportez-vous à Centre d'aide - Configuration de résolveurs et de vues de zones DNS privés.

Résolution DNS entre des réseaux cloud virtuels

Envoyez des demandes entre des réseaux cloud virtuels à l'aide d'adresses de résolveur. Les réseaux cloud virtuels peuvent exister dans différentes régions. Cette solution nécessite une passerelle d'appairage local ou une passerelle d'appairage à distance . Pour envoyer le trafic du réseau cloud virtuel A au réseau cloud virtuel B, ajoutez une adresse d'écoute au résolveur du réseau cloud virtuel B. Ensuite, ajoutez une adresse de transmission au résolveur dédié du réseau cloud virtuel A. Créez une règle sur le résolveur dédié du réseau cloud virtuel A qui transmet le trafic vers l'adresse de l'adresse d'écoute du réseau cloud virtuel B via l'adresse de transmission du réseau cloud virtuel A. Pour envoyer le trafic dans les deux directions entre les réseaux cloud virtuels, ajoutez une adresse de résolveur de transmission et d'écoute à chaque résolveur dédié, et ajoutez une règle sur chaque résolveur dédié. Pour obtenir un guide détaillé sur cette configuration, reportez-vous à Chroniques de l'A-Team - Implémentation du DNS privé.

Connectivité entre un réseau cloud virtuel et des serveurs de noms sur site

Vous pouvez envoyer des demandes entre un réseau cloud virtuel et des serveurs de noms sur site dans les deux directions. Cette solution nécessite une connectivité entre le VCN et le réseau sur site à l'aide de FastConnect ou d'un tunnel IPSec (VPN IPSec). Pour envoyer du trafic vers un réseau cloud virtuel, ajoutez une adresse d'écoute à son résolveur dédié et envoyez le trafic à son adresse. Pour envoyer du trafic à partir d'un réseau cloud virtuel, ajoutez une adresse de transmission à son résolveur dédié ainsi qu'une règle qui transmet le trafic à l'adresse du serveur de noms sur site via l'adresse. Pour obtenir un guide détaillé sur cette configuration, reportez-vous à Chroniques de l'A-Team - Implémentation du DNS privé.

Cas d'emploi avancés

Les réseaux cloud virtuels peuvent être configurés pour plusieurs cas d'emploi. Un seul réseau cloud virtuel peut être à la fois appairé avec un autre réseau cloud virtuel et configuré pour se connecter à un serveur de noms sur site. Le transfert peut également être chaîné entre de nombreux réseaux cloud virtuels.

Enregistrements de ressource pris en charge

Le service Oracle Cloud Infrastructure DNS prend en charge de nombreux types d'enregistrement de ressource. La liste suivante fournit une brève explication de l'objectif de chaque type d'enregistrement pris en charge pour le DNS privé. Pour le DNS public, reportez-vous à Enregistrements de ressource pris en charge pour le DNS public. Evitez de saisir des informations confidentielles lorsque vous renseignez des données d'enregistrement. Les liens RFC vous permettent d'accéder à des informations supplémentaires sur les types d'enregistrement et sur leur structure de données.

Remarque sur les données RDATA

OCI normalise toutes les données au format le plus lisible par la machine. La présentation renvoyée de RDATA peut différer de son entrée initiale.

Exemple :

Les données RDATA des types d'enregistrement CNAME, DNAME et MX peuvent contenir des noms de domaine absolus. Si les données RDATA spécifiées pour l'un de ces types d'enregistrement ne se terminent pas par un point représentant la racine, un point est ajouté.

www.example.com --> www.example.com.

Vous pouvez utiliser différentes bibliothèques DNS pour normaliser les données d'enregistrement avant la saisie.

Langage de programmation Bibliothèque
Go Bibliothèque DNS en Go
Java dnsjava
Python dnspython

Types d'enregistrement de ressource de DNS privé

A
Enregistrement d'adresse utilisé pour faire pointer un nom d'hôte vers une adresse IPv4. Pour plus d'informations sur les enregistrements A, reportez-vous à la norme RFC 1035.
AAAA
Enregistrement d'adresse permettant de faire pointer un nom d'hôte vers une adresse IPv6. Pour plus d'informations sur les enregistrements AAAA, reportez-vous à la norme RFC 3596.
CAA
Un enregistrement d'autorisation d'autorité de certification est utilisé par un titulaire de nom de domaine pour spécifier des autorités de certification autorisées à émettre des certificats pour ce domaine. Pour plus d'informations sur les enregistrements CAA, reportez-vous à la norme RFC 6844.
CNAME
Un enregistrement CNAME (nom canonique) identifie le nom canonique d'un domaine. Pour plus d'informations sur les enregistrements CNAME, reportez-vous à la norme RFC 1035.
DNAME
Un enregistrement DNAME présente un comportement similaire à celui d'un enregistrement CNAME, mais met en correspondance l'ensemble de la sous-arborescence d'un libellé avec un autre domaine. Pour plus d'informations sur les enregistrements DNAME, reportez-vous à la norme RFC 6672.
MX
Un enregistrement MX (échangeur de courriels) définit le serveur de messagerie acceptant les courriels d'un domaine. Les enregistrements MX doivent pointer vers un nom d'hôte. Les enregistrements MX ne doivent pas pointer vers un CNAME ou une adresse IP Pour plus d'informations sur les enregistrements MX, reportez-vous à la norme RFC 1035.
PTR
Un enregistrement PTR (pointeur) met en correspondance une adresse IP avec un nom d'hôte. Il s'agit du comportement inverse d'un enregistrement A qui met en correspondance un nom d'hôte avec une adresse IP. Les enregistrements PTR sont courants dans les zones DNS inverses. Pour plus d'informations sur les enregistrements PTR, reportez-vous à la norme RFC 1035.
SRV
Un enregistrement SRV (localisateur de service) permet aux administrateurs d'utiliser plusieurs serveurs pour un même domaine. Pour plus d'informations sur les enregistrements SRV, reportez-vous à la norme RFC 2782.
TXT
Un enregistrement TXT contient un texte descriptif lisible à l'oeil. Il peut également inclure un contenu non lisible à l'oeil pour des utilisations spécifiques. Ce type d'enregistrement est couramment utilisé pour les enregistrements SPF et DKIM qui nécessitent des éléments texte non lisibles à l'oeil. Pour plus d'informations sur les enregistrements TXT, reportez-vous à la norme RFC 1035.

Stratégies IAM requises

Pour utiliser le DNS privé, un utilisateur a besoin d'une autorité suffisante (par le biais d'une stratégie IAM). Les utilisateurs du groupe Administrateurs disposent de l'autorité requise. Si un utilisateur ne fait pas partie du groupe Administrateurs, une stratégie telle que celle-ci permet à un groupe spécifique de gérer le DNS privé :

Allow group <GroupName> to manage dns in tenancy where target.dns.scope = 'private'

Si vous ne connaissez pas les stratégies, reportez-vous à Introduction aux stratégies et à Stratégies courantes. Pour plus de détails sur les stratégies pour le DNS privé, reportez-vous à Référence de stratégie DNS.

Tâches DNS privées

Configuration d'un DNS privé

Pour configurer un DNS privé, procédez comme suit :

Tâches DNS privées

Pour plus d'informations sur la gestion des ressources DNS privées, reportez-vous aux sections suivantes :

Tâches VCN

Pour créer un VCN avec un résolveur DNS dédié, reportez-vous à Présentation des réseaux cloud virtuels et des sous-réseaux et à DNS dans votre réseau cloud virtuel pour plus d'informations.