Présentation du DNS interne

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Lorsque vous créez des instances Compute Engine, le DNS interne crée automatiquement un nom DNS pour l'instance. Ce nom DNS facilite la communication interne entre instances en résolvant les adresses IP internes. Les réseaux cloud privés virtuels sur Google Cloud utilisent le service DNS interne pour permettre aux instances Compute Engine d'un même réseau d'accéder les unes aux autres en utilisant des noms DNS internes.

Google Cloud crée, met à jour et supprime automatiquement les types d'enregistrements DNS suivants lorsque vous gérez vos instances:

• Les enregistrements d'adresse DNS, ou enregistrements A, sont créés pour les instances dans une zone DNS pour .internal.
• Les enregistrements PTR pour les instances, utilisés pour la résolution DNS inverse, sont créés dans les zones inversées correspondantes.

Par exemple, lorsque vous supprimez une instance, Google Cloud supprime automatiquement les enregistrements A et PTR associés à son nom DNS interne. Si vous créez ensuite une instance portant le même nom, Google Cloud crée des enregistrements pour l'instance de remplacement.

Limites

• Compute Engine ne crée des enregistrements de nom DNS A et PTR internes que pour l'adresse IPv4 interne principale de l'interface réseau nic0 d'une instance. Par conséquent, le type de pile de l'interface réseau nic0 doit être IPv4 uniquement ou double pile. Le DNS interne n'est pas compatible avec les interfaces réseau IPv6 uniquement (Preview).

• Compute Engine ne crée pas d'enregistrements DNS internes pour les éléments suivants:

  • Adresse IPv4 interne principale d'une interface réseau différente de nic0.
  • Adresse IPv4 externe de n'importe quelle interface réseau.
  • Adresse IPv4 interne d'une plage d'adresses IP d'alias de n'importe quelle interface réseau.
  • Plage d'adresses IPv6 interne ou externe de n'importe quelle interface réseau.

• Pour résoudre les noms DNS internes, la VM cliente et la VM associée à l'enregistrement DNS interne doivent toutes deux:

  • Sur le même réseau VPC.
  • Dans le même projet (sauf dans certains scénarios de VPC partagés).

  Pour en savoir plus sur les scénarios de VPC partagé, consultez la section Noms DNS internes et VPC partagé.

Noms DNS internes zonaux et globaux

Google Cloud possède deux types de noms DNS internes:

• DNS zonal: les noms d'instance doivent être uniques dans chaque zone, mais vous pouvez les réutiliser dans plusieurs zones. Par exemple, vous pouvez avoir plusieurs instances nommées instance-1 tant que les instances se trouvent dans des zones différentes.
• DNS global: les noms d'instance doivent être uniques dans chaque projet. Avec le DNS global, vous ne pouvez pas réutiliser les noms d'instance dans le projet.

En général, Google recommande fortement d'utiliser le DNS zonal, car il offre une fiabilité plus élevée en isolant les défaillances de l'enregistrement DNS aux zones individuelles. En cas de panne, le DNS global présente les problèmes suivants :

• Le nom de l'instance doit être unique dans l'ensemble du projet. Par conséquent, vous ne pouvez créer d'instances dans aucune région en cas de défaillance du plan de contrôle où vous disposez ou aviez déjà des ressources de projet. Google Cloud ne peut pas valider les noms DNS de ressources existants dans la région indisponible.
• Certaines fonctionnalités de Compute Engine ne sont pas disponibles, comme l'autoscaling des groupes d'instances gérés (MIG). Par conséquent, vos applications qui utilisent l'autoscaling pour gérer normalement les augmentations de charge de travail ne peuvent pas évoluer à la hausse.

Le type DNS interne par défaut est défini lorsque vous activez l'API Compute Engine.

• Le type DNS interne par défaut est le DNS zonal.
• Si votre organisation ou votre projet autonome a activé l'API Compute Engine avant le 6 septembre 2018, le type de DNS interne par défaut est défini sur le DNS global.

Les noms de domaine complets pour les noms DNS internes sont décrits dans le tableau suivant.

Remplacez les éléments suivants :

• INSTANCE_NAME : nom de l'instance. Pour le DNS zonal, cette valeur doit être unique dans la zone, mais peut être répétée dans plusieurs zones. Pour le DNS global, le nom d'instance doit être unique dans le projet.
• ZONE : zone où se trouve votre instance.
• PROJECT_ID : projet auquel l'instance appartient.

Pour savoir comment contrôler le type de nom DNS interne utilisé au niveau du projet ou de l'instance, reportez-vous à la section Configurer des noms DNS pour votre projet ou vos instances.

Résolution de nom DNS

Les instances reçoivent des informations de résolution de DNS internes dans le cadre de leurs baux DHCP. La méthode de résolution DNS dépend de la plate-forme du système d'exploitation :

• Sous Linux, le serveur DNS (169.254.169.254:53) de l'instance résout les noms DNS internes par défaut.
• Sous Windows, la passerelle par défaut du sous-réseau résout les noms DNS internes.

Zones inversées pour les enregistrements PTR

Le service DNS interne deGoogle Cloudcrée automatiquement des enregistrements PTR pour les instances dans les zones inversées suivantes:

• 10.in-addr.arpa.
• 168.192.in-addr.arpa.
• 16.172.in-addr.arpa., 17.172.in-addr.arpa., ... jusqu'à 31.172.in-addr.arpa.

Noms DNS internes et VPC partagé

La VM cliente et la VM associée à l'enregistrement DNS interne peuvent se trouver dans des projets distincts, mais elles doivent utiliser le même réseau VPC partagé. Par exemple, le client peut se trouver dans un projet de service, et la VM associée à l'enregistrement DNS interne peut se trouver dans un autre projet de service ou dans le projet hôte.

Les clients doivent émettre des requêtes de nom de domaine complet (FQDN) pour les enregistrements DNS internes au lieu de s'appuyer sur des requêtes partielles et des domaines de recherche DNS. Les domaines de recherche DNS sont différents dans chaque projet pour des raisons telles que les suivantes:

• La partie du nom de domaine de chaque enregistrement A DNS interne contient l'ID du projet qui contient la VM. Pour une VM dans un projet de service dont l'interface réseau nic0 utilise un réseau VPC partagé, le projet de la VM est différent du projet contenant le réseau.

• L'utilisation de noms DNS internes zonaux ou globaux (à l'échelle du projet) dépend de la configuration du projet contenant la VM.

Pour en savoir plus sur le VPC partagé, consultez les ressources suivantes:

• Présentation du VPC partagé
• Provisionner un VPC partagé

Personnaliser les noms DNS internes

Certaines organisations ou applications peuvent nécessiter des noms DNS internes personnalisés au lieu des noms DNS internes par défaut créés par Google Cloud.

Zones privées et enregistrements personnalisés avec Cloud DNS

Vous pouvez utiliser une zone privée Cloud DNS pour créer des entrées DNS personnalisées pour vos instances. Vous pouvez configurer des enregistrements PTR qui vous permettent de remplacer l'URL DNS interne par défaut de votre instance par l'URL personnalisée que vous fournissez.

Pour créer des enregistrements PTR personnalisés qui remplacent les noms PTR des DNS internes créés automatiquement, consultez la section Enregistrements PTR pour les adresses RFC 1918 dans les zones privées. Pour en savoir plus sur la création d'enregistrements PTR pour les instances, consultez la page Créer un enregistrement PTR pour une instance.

Noms d'hôtes personnalisés

Vous pouvez spécifier un nom d'hôte personnalisé pour une instance lors de sa création. Les noms d'hôte personnalisés attribués de cette manière ne sont pas résolus par les DNS internes. Avec les noms d'hôte personnalisés, vous devez toujours créer un enregistrement DNS correspondant dans la zone appropriée (par exemple, en utilisant Cloud DNS). Pour en savoir plus, consultez la section Créer une instance avec un nom d'hôte personnalisé.

DNS interne et DHCP

Les instances Compute Engine sont configurées pour renouveler les baux DHCP toutes les 24 heures. Pour les instances activées pour des DNS zonaux, le bail DHCP expire toutes les heures. Les instances utilisant des DNS zonaux ont des entrées zonales et globales dans le fichier de configuration DHCP.

Par défaut, la plupart des distributions Linux stockent les informations DHCP dans le fichier resolv.conf. Si vous modifiez manuellement les résultats de resolv.conf, le DHCP par défaut est rétabli chaque fois que le bail DHCP de 24 heures expire sur votre instance. Pour effectuer des modifications statiques dans le fichier resolv.conf, plusieurs distributions Linux permettent d'ajouter des éléments à la stratégie DHCP, au début ou à la fin.

La manière dont vous modifiez la stratégie ou le fichier de configuration DHCP dépend de la distribution Linux que vous utilisez. Par exemple, Red Hat Enterprise Linux et Debian utilisent le fichier de configuration /etc/dhcp/dhcpd.conf. Sous CentOS, vous utilisez l'utilitaire de ligne de commande Network Manager, nmcli.

Reportez-vous à la documentation de votre système d'exploitation pour obtenir des informations sur la configuration des paramètres réseau DHCP et DNS personnalisés. Par exemple, pour Red Hat Enterprise Linux pour SAP avec HA et Update Services 8.6, utilisez le lien suivant : Configurer manuellement le fichier /etc/resolv.conf.

Fichier resolv.conf d'exemple

Par défaut, la plupart des distributions Linux stockent les informations DHCP dans le fichier resolv.conf. Le service systemd-resolved fournit également des services de résolveur pour le DNS. Vous pouvez configurer ce service en modifiant le fichier /etc/systemd/resolved.conf et d'autres fichiers *.conf dans le répertoire /etc/systemd/resolved.conf.d/. Sur les distributions Linux qui stockent des informations DHCP dans resolved.conf, vous pouvez consulter les entrées DNS régionales et globales dans le fichier /etc/systemd/resolved.conf.

Ces fichiers comportent les restrictions suivantes :

• Le chemin de recherche ne peut gérer que six enregistrements, dont trois sont fournis par Compute Engine. Si vous ajoutez des entrées au chemin de recherche de telle sorte que le nombre total d'entrées soit supérieur à 6, les règles de recherche après la 6^e entrée ne sont pas appliquées par votre système d'exploitation. Cela peut entraîner le dysfonctionnement des fonctionnalités Compute Engine, telles que l'accès aux instances à l'aide de leurs noms d'instance.

• Si vous modifiez manuellement les résultats de resolv.conf, le DHCP par défaut est rétabli chaque fois que le bail DHCP de 24 heures expire sur votre instance. Sur les instances utilisant des DNS zonaux, le bail DHCP expire toutes les heures. Pour effectuer des modifications statiques dans le fichier resolv.conf, plusieurs distributions Linux permettent d'ajouter des éléments à la stratégie DHCP, au début ou à la fin.

# Local domain name. Computed from your project name.
domain ZONE.c.PROJECT_ID.internal
# Search list for hostname lookup. Starting with entries that represent
# your project and ending with google.internal to facilitate metadata server requests.
search ZONE.c.PROJECT_ID.internal. c.PROJECT_ID.internal. google.internal.
# Address of the DNS server to resolve project specific, and global domain names.
nameserver 169.254.169.254

lease {
  # What interface we are using for the network
  interface "eth0";
  fixed-address 10.128.0.9;
  option subnet-mask 255.255.255.255;
  option routers 10.128.0.1;
  # Lease timeout, older instances will have this value set to infinite.
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 169.254.169.254;
  option dhcp-server-identifier 169.254.169.254;
  option interface-mtu 1460;
  # Search path options that are copied into the resolv.conf
  option domain-search "ZONE.c.PROJECT_ID.internal.", "c.PROJECT_ID.internal.", "google.internal.";
  option ntp-servers 169.254.169.254;
  option rfc3442-classless-static-routes 32,10,128,0,1,0,0,0,0,0,10,128,0,1;
  option host-name "INSTANCE_NAME.ZONE.c.PROJECT_ID.internal";
  option domain-name "ZONE.c.PROJECT_ID.internal";
  renew 4 2017/11/16 02:15:52;
  rebind 4 2017/11/16 02:43:59;
  expire 4 2017/11/16 02:51:29;
}

# Local domain name. Computed from your project name.
domain c.PROJECT_ID.internal
# Search list for hostname lookup. Starting with entries that represent
# your project and ending with google.internal to facilitate metadata server requests.
search c.PROJECT_ID.internal google.internal.
# Address of the DNS server to resolve project specific, and global domain names.
nameserver 169.254.169.254

lease {
  # What interface we are using for the network
  interface "eth0";
  fixed-address 10.128.0.8;
  option subnet-mask 255.255.255.255;
  option routers 10.128.0.1;
  # Lease timeout, older instances will have this value set to infinite.
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option domain-name-servers 169.254.169.254;
  option dhcp-server-identifier 169.254.169.254;
  option interface-mtu 1460;
  # Search path options that are copied into the resolv.conf
  option domain-search "c.PROJECT_ID.internal.", "google.internal.";
  option ntp-servers 169.254.169.254;
  option rfc3442-classless-static-routes 32,10,128,0,1,0,0,0,0,0,10,128,0,1;
  option host-name "INSTANCE_NAME.c.PROJECT_ID.internal";
  option domain-name "c.PROJECT_ID.internal";
  renew 4 2017/11/16 12:07:00;
  rebind 4 2017/11/16 22:44:53;
  expire 5 2017/11/17 01:44:53;
}

Fichier dhclient.conf d'exemple

Certains systèmes d'exploitation, tels que Debian 9, utilisent le fichier dhclient.conf au lieu du fichier resolv.conf.

Exemple de fichier /etc/dhcp/dhclient.conf :

# Configuration file for /sbin/dhclient.
#
...
append domain-search "mydomain.com";
prepend domain-name-servers 172.16.1.1;

Dans cet exemple, mydomain.com est le nouveau domaine de recherche et 172.16.1.1 est l'adresse IP du serveur DNS.

Étape suivante

• Pour en savoir plus sur les Google Cloud réseaux VPC, consultez la présentation du VPC.
• Pour en savoir plus sur la création et la modification des réseaux VPC, consultez la section Utiliser VPC.
• Migrez votre organisation et vos projets pour utiliser le DNS zonal au lieu du DNS global.