DNS internes

Les réseaux de cloud privé virtuel (VPC) sur GCP disposent d'un service DNS interne permettant aux instances du même réseau d'accéder les unes aux autres en utilisant des noms DNS internes. Les enregistrements internes A pour les instances de machine virtuelle (VM) sont créés dans une zone DNS pour .internal. Les enregistrements PTR pour les VM sont créés dans les zones inversées correspondantes. Lorsque vous gérez vos instances de VM, GCP crée, met à jour et supprime automatiquement ces enregistrements DNS.

Par exemple, si vous supprimez une VM, GCP supprime automatiquement les enregistrements A et PTR associés à son nom DNS .internal. Si vous créez une VM portant le même nom, GCP crée alors un enregistrement pour la VM de remplacement.

À propos du DNS interne

Les noms DNS internes ont les spécifications suivantes :

  • Le nom DNS interne d'une instance de VM ne résout que son adresse IP interne principale. Les noms DNS internes ne peuvent pas servir à se connecter aux adresses IP externes d'une instance.

  • Les noms DNS internes ne peuvent pas être configurés pour résoudre les adresses IP d'alias secondaires.

  • Les noms DNS internes ne peuvent être résolus qu'à partir d'autres VM appartenant au même projet et utilisant le même réseau VPC ou un ancien réseau. Vous ne pouvez pas utiliser un DNS interne pour contacter des instances se trouvant dans d'autres réseaux VPC, même si elles font partie du même projet.

Enregistrements PTR et DNS internes

Les DNS internes de GCP créent automatiquement des enregistrements PTR pour les VM 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. , ... à 31.172.in-addr.arpa.

DNS internes et Cloud DNS

DNS internes et Cloud DNS constituent des offres différentes. Les noms DNS internes sont créés automatiquement par GCP. Si vous devez créer des noms DNS personnalisés pour vos VM, utilisez une zone privée Cloud DNS.

Si vous devez créer des enregistrements PTR personnalisés qui remplacent les enregistrements PTR des DNS internes créés automatiquement, reportez-vous à la section utiliser les enregistrements PTR dans les zones privées de la documentation Cloud DNS.

Noms d'hôtes personnalisés

Vous pouvez spécifier un nom d’hôte personnalisé pour une VM 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). Reportez-vous à la section Créer une instance de VM avec un nom d'hôte personnalisé pour plus d'informations.

Types de noms DNS internes

GCP a deux types de noms DNS internes. Le type DNS interne par défaut est défini en fonction du moment où l'API Compute Engine a été activée.

Type de DNS interne Nom de domaine complet Type par défaut du projet
DNS zonal [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal Valeur par défaut pour toutes les organisations ou tous les projets autonomes ayant activé l'API Compute Engine après le 6 septembre 2018.
DNS global (à l'échelle du projet) [INSTANCE_NAME].c.[PROJECT_ID].internal Valeur par défaut pour toutes les organisations ou tous les projets autonomes ayant activé l'API Compute Engine avant le 6 septembre 2018.

Où :

  • [INSTANCE_NAME] est le nom de l'instance.
  • [ZONE] est la zone où se trouve votre instance ;
  • [PROJECT_ID] est le projet auquel l'instance appartient.

Vous pouvez contrôler le type de nom DNS interne utilisé au niveau du projet ou au niveau de l'instance. Consultez la section Configurer des noms DNS pour votre projet ou vos instances.

Noms DNS internes et VPC partagé

Vous pouvez utiliser un nom DNS interne pour faire référence à l'adresse IP interne d'une VM, même si cette adresse IP est située sur un réseau VPC partagé dans un projet hôte. Avec un VPC partagé, l'ID de projet du nom DNS interne zonal ou global (à l'échelle du projet) correspond à l'identifiant du projet de service.

Déterminer un nom DNS interne pour une machine virtuelle

Utilisez la procédure suivante pour afficher le nom DNS interne attribué à une machine virtuelle. La source d'information pour un nom DNS interne est son serveur de métadonnées.

  1. Connectez-vous à l'instance.
  2. Affichez le nom d'hôte depuis les métadonnées de l'instance :

    curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \
    -H "Metadata-Flavor: Google"
    

Le format du nom d'hôte indique le type de nom DNS interne utilisé par la machine virtuelle.

Accéder aux machines virtuelles par DNS interne

Le serveur de métadonnées est également le résolveur de serveur DNS pour les requêtes DNS émises par la machine virtuelle. Il résout toutes les requêtes DNS, à la fois en noms DNS internes et en noms DNS externes. Pour les requêtes DNS externes, le serveur de métadonnées transmet les requêtes aux serveurs de noms publics de Google.

Dans l'exemple suivant, la commande ping sert à contacter une instance utilisant le DNS zonal. Cette méthode fonctionne à condition que vous ayez créé une règle de pare-feu autorisant le trafic ICMP entrant sur l'instance.

$ ping [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal -c 1

PING [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal (10.240.0.17) 56(84) bytes of data.
64 bytes from [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal (10.240.0.17): icmp_seq=1 ttl=64 time=0.136 ms

où :

  • [INSTANCE_NAME] est le nom de l'instance ;
  • [ZONE] correspond à la zone où se trouve l'instance ;
  • [PROJECT_ID] est le projet auquel l'instance appartient.

DNS interne et resolv.conf

Par défaut, la plupart des distributions Linux stockent les informations DHCP dans le fichier resolv.conf. 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. Le renouvellement du DHCP remplace ce fichier, annulant toutes les modifications que vous avez pu y apporter. Les instances utilisant des DNS zonaux ont des entrées zonales et globales dans le fichier resolv.conf.

DNS zonal

Exemple de fichier resolv.conf :

# 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

Où :

  • [ZONE] est la zone où se trouve votre instance ;
  • [PROJECT_ID] est le projet auquel l'instance appartient.

Exemple de fichier zonal dhcp.lease :

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 VM 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;
}

Où :

  • [INSTANCE_NAME] est le nom de l'instance.
  • [ZONE] est la zone où se trouve votre instance ;
  • [PROJECT_ID] est le projet auquel l'instance appartient.

DNS global

Exemple de fichier resolv.conf global :

# 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

[PROJECT_ID] est le projet auquel l'instance appartient.

Exemple de fichier dhcp.lease global :

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 VM 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;
}

où :

  • [INSTANCE_NAME] est le nom de l'instance ;
  • [PROJECT_ID] est le projet auquel l'instance appartient.

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 à six, les règles de recherche après la sixième entrée ne seront 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 via leur nom d'instance.
  • Si vous modifiez manuellement resolv.conf, le DHCP par défaut sera rétabli chaque fois que le bail DHCP de 24 heures expirera 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.

Debian 9

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;

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

Noms DNS zonaux

Les noms DNS zonaux incluent le nom de l'instance, la zone dans laquelle elle se trouve et le projet auquel elle appartient. Les noms DNS globaux n'incluent pas la zone dans laquelle se trouve l'instance. Les noms DNS zonaux situés dans une zone fonctionnent indépendamment des autres zones, ce qui vous permet de créer des applications multirégionales plus tolérantes aux pannes avec de meilleures caractéristiques de disponibilité.

Les projets et organisations existants peuvent continuer à utiliser des noms DNS globaux, mais sont encouragés à migrer vers des noms DNS zonaux.

Configurer des noms DNS pour votre projet ou vos instances

Activez les chemins de recherche DNS zonaux et/ou globaux sur vos instances en définissant la variable VmDnsSetting dans les métadonnées de projet ou d'instance. Si vous définissez la variable VmDnsSetting sur les métadonnées d'une instance spécifique, elle remplacera toutes les variables VmDnsSetting héritées des métadonnées du projet pour cette instance.

  • Définissez VmDnsSetting=ZonalOnly pour que vos instances ne puissent être adressables que par leur nom DNS zonal. Les instances conservent les chemins de recherche zonal et global, mais leur nom DNS global ne fonctionne plus. D'autres instances peuvent adresser les instances comportant ce paramètre en n'utilisant que leur nom DNS zonal, mais elles ne peuvent pas les adresser avec leur nom DNS ou leur chemin de recherche global. C'est l'option à privilégier à condition que vos applications soient compatibles. Il s'agit du paramètre par défaut pour les instances de projets autonomes et de projets créés par des organisations ayant activé l'API Compute Engine après le 6 septembre 2018. Notez que si un projet est migré vers une organisation, le nom DNS par défaut de ce projet ne change pas.
  • Définissez VmDnsSetting=ZonalPreferred pour activer les chemins de recherche DNS zonaux tout en conservant le nom DNS global. Les instances disposant de ce paramètre peuvent s'adresser entre elles à l'aide de noms DNS zonaux ou globaux, et peuvent continuer à adresser des instances configurées uniquement pour les noms DNS globaux.
  • Définissez VmDnsSetting=GlobalOnly pour que les instances n'utilisent que les noms globaux comme noms de domaine et entrées de chemin de recherche. Utilisez cette valeur pour exclure des instances d'un paramètre DNS zonal à l'échelle du projet ou pour restaurer vos instances afin qu'elles n'utilisent que des noms DNS globaux. Il s'agit du paramètre par défaut pour les instances de projets autonomes et de projets créés par des organisations ayant activé l'API Compute Engine avant le 6 septembre 2018. Veuillez prendre en compte que si un projet est migré vers une organisation, le nom DNS par défaut de ce projet ne change pas.

Consultez la section Définir des métadonnées personnalisées pour en savoir plus sur la définition des valeurs de métadonnées d'un projet ou d'une instance.

Après avoir configuré la variable VmDnsSetting pour une instance, actualisez le bail DHCP sur l'instance. Vous pouvez actualiser le bail en redémarrant l'instance, en attendant son expiration ou en exécutant l'une des commandes suivantes :

  • Instances Linux : sudo dhclient -v -r
  • Instances Windows Server : ipconfig /renew

Migrer des applications existantes vers des noms DNS zonaux

Bien que vos projets existants puissent continuer à utiliser des noms DNS globaux, vous êtes invité à migrer vos instances et applications existantes pour utiliser des noms DNS zonaux et ainsi bénéficier des avantages du système DNS zonal. De manière générale, vous pouvez utiliser le processus de migration suivant :

  1. Vérifiez vos applications et mettez-les à jour pour résoudre les problèmes de compatibilité avec les paramètres uniquement zonaux :
    • Les applications qui adressent des instances par leur nom ou par des noms de domaine complets globaux : les noms d'instance et les noms d'instance globaux ne seront pas toujours résolus dans un environnement uniquement zonal. Nous vous conseillons de mettre à jour ces noms pour utiliser les noms de domaine complets zonaux.
    • Les applications qui adoptent un format de nom de domaine complet global spécifique : l'adoption d'un format de nom de domaine représente généralement un problème fondamental dans la conception des applications. Nous vous recommandons de concevoir vos applications pour qu'elles fonctionnent indépendamment du format du nom de domaine.
    • Les applications qui n'anticipent pas les changements de nom de domaine : certaines applications ne sont éventuellement pas préparées pour une modification des noms de domaine et peuvent nécessiter un redémarrage complet pour récupérer les nouveaux noms. Si possible, mettez à jour vos applications pour identifier et gérer les modifications du nom de domaine de votre instance.
  2. Configurez des instances sur votre réseau VPC interne pour utiliser le paramètre VmDnsSetting=ZonalPreferred, qui utilise des noms DNS globaux et zonaux. Cette phase de transition permet aux instances de continuer à utiliser des noms globaux jusqu'à ce que les applications soient prêtes à utiliser uniquement des noms zonaux :
    1. Activez VmDnsSetting=ZonalPreferred sur une instance en définissant cette valeur dans des métadonnées personnalisées.
    2. Actualisez le bail DHCP sur cette instance pour qu'elle commence à utiliser des noms DNS zonaux :
      • Instances Linux : sudo dhclient -v -r
      • Instances Windows Server : ipconfig /renew
    3. Testez les applications sur cette instance pour vous assurer qu'elles fonctionnent comme prévu. Certaines applications ne sont éventuellement pas préparées pour une modification des noms de domaine et peuvent nécessiter un redémarrage complet pour récupérer les nouveaux noms.
    4. Répétez ce processus pour activer VmDnsSetting=ZonalPreferred et actualiser le bail DHCP sur les instances restantes de votre réseau VPC jusqu'à ce qu'elles fonctionnent toutes comme prévu en n'utilisant que les noms DNS zonaux. Vous pouvez également définir VmDnsSetting=ZonalPreferred dans les métadonnées du projet pour configurer chaque instance de votre projet afin qu'elle utilise des noms DNS zonaux.
  3. Une fois que vos applications s'exécutent correctement en n'utilisant que des noms de domaine zonaux avec le paramètre VmDnsSetting=ZonalPreferred, vous pouvez désactiver les noms globaux sur ce réseau VPC. Configurez des instances sur votre réseau VPC interne pour utiliser le paramètre VmDnsSetting=ZonalOnly, qui n'utilise que des noms DNS zonaux :
    1. Activez VmDnsSetting=ZonalOnly sur une instance en définissant cette valeur dans des métadonnées personnalisées.
    2. Actualisez le bail DHCP sur cette instance pour qu'elle commence à utiliser des noms DNS zonaux :
      • Instances Linux : sudo dhclient -v -r
      • Instances Windows Server : ipconfig /renew
    3. Testez les applications sur cette instance pour vous assurer qu'elles fonctionnent comme prévu.
    4. Répétez ce processus pour activer VmDnsSetting=ZonalOnly et actualiser le bail DHCP sur les instances restantes de votre réseau VPC jusqu'à ce qu'elles fonctionnent toutes comme prévu en n'utilisant que les noms DNS zonaux.
  4. Répétez ce processus sur chacun de vos réseaux VPC jusqu'à ce que toutes les instances de votre projet utilisent le paramètre VmDnsSetting=ZonalOnly. Vous pouvez définir VmDnsSetting=ZonalOnly dans les métadonnées au niveau du projet pour que ce paramètre s'applique automatiquement à toutes les instances que vous créez dans ce projet. Vous pouvez également définir VmDnsSetting=ZonalOnly dans les métadonnées du projet pour configurer chaque instance du projet afin qu'elle utilise des noms DNS zonaux.

Désactiver le DNS zonal sur votre projet ou vos instances

Pour désactiver le DNS zonal sur une instance spécifique, définissez VmDnsSetting=GlobalOnly dans les métadonnées de cette instance. Pour désactiver le DNS zonal dans un projet, définissez VmDnsSetting=GlobalOnly dans les métadonnées du projet et assurez-vous qu'aucune de vos instances n'est configurée individuellement avec une valeur VmDnsSetting. Consultez la section Définir des métadonnées personnalisées pour en savoir plus sur la définition des valeurs de métadonnées d'un projet ou d'une instance.

Si vous devez forcer l'actualisation immédiate du bail DHCP, vous pouvez utiliser l'une des commandes suivantes :

  • Système d'exploitation optimisé pour les conteneurs (Google Kubernetes Engine) : sudo systemctl restart systemd-networkd
  • Instances Debian/Google App Engine Flex : sudo dhclient -r -v eth0 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v eth0
  • Ubuntu 15.04 ou version ultérieure : sudo dhclient -r -v ens4 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v ens4
  • Version d'Ubuntu antérieure à 15.04 : sudo dhclient -r -v eth0 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v eth0
  • Windows : ipconfig /renew

Certains systèmes d'exploitation ne modifient pas complètement leur configuration DNS même après le renouvellement du bail DHCP. Dans ce cas, redémarrez le réseau de l'instance de VM pour forcer la modification de la configuration DNS :

  • Ubuntu : sudo ifdown --exclude=lo -a && sudo ifup --exclude=lo -a
  • CentOS : sudo /etc/init.d/network restart
  • CoreOS : sudo systemctl restart systemd-networkd
  • Système d'exploitation optimisé pour les conteneurs : sudo systemctl restart systemd-networkd

Si vous exécutez votre application dans des conteneurs, sur Kubernetes Engine ou sur un environnement flexible App Engine, la configuration DNS de vos paramètres de conteneur risque de ne pas se mettre à jour automatiquement tant que vous ne redémarrez pas les conteneurs. Pour désactiver le DNS zonal sur ces applications de conteneur, vous devez définir VmDnsSetting=GlobalOnly sur vos projets et instances, et redémarrer les conteneurs afin que leurs paramètres DNS reviennent à leur état d'origine.

Étapes suivantes

  • Consultez la présentation du VPC pour en savoir plus sur les réseaux VPC de GCP.
  • Consultez la page Utiliser VPC pour savoir comment créer et modifier des réseaux VPC.
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine