DNS interne


Les réseaux de cloud privés virtuel sur Google Cloud 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 instances de VM sont créés dans les zones inversées correspondantes. Lorsque vous gérez vos instances, Google Cloud crée, met à jour et supprime automatiquement ces enregistrements DNS.

Par exemple, lorsque vous supprimez une instance, Google Cloud supprime automatiquement les enregistrements A et PTR associés à son nom DNS .internal. Si vous créez ensuite une instance portant le même nom, Google Cloud crée un enregistrement pour l'instance 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 de VM situées sur le même réseau. Ces VM peuvent se trouver dans le même projet que le réseau ou dans des projets de service utilisant le même réseau VPC partagé. Pour résoudre les noms DNS des VM dans les projets de service, vous devez utiliser les noms de domaine complets des VM. Vous ne pouvez pas utiliser un DNS interne pour contacter des VM appartenant à un autre réseau.

Types de noms DNS internes

Google Cloud possède 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.

En général, Google recommande fortement d'utiliser le DNS zonal, car il offre des garanties de fiabilité plus élevées en isolant les défaillances de l'enregistrement DNS aux zones individuelles.

Type de DNS interne Nom de domaine complet Type par défaut du projet Remarques
DNS zonal VM_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. Les noms d'instances de VM doivent être uniques dans la zone, mais peuvent être répétés entre les 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 (à l'échelle du projet) VM_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. Les noms d'instance de VM doivent être uniques dans l'ensemble du projet. Vous ne pouvez pas répéter les noms d'instances.

Remplacez l'élément suivant :

  • VM_NAME : nom de la VM. 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.

Enregistrements PTR et DNS internes

Les DNS internes de Google Cloud 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., ... jusqu'à 31.172.in-addr.arpa.

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 de VM. Vous pouvez configurer des enregistrements PTR qui vous permettent de remplacer l'URL de VM du DNS interne par défaut 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.

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). Pour en savoir plus, consultez la page Créer une instance de VM avec un nom d'hôte personnalisé.

Noms DNS internes et VPC partagé

Vous pouvez utiliser un nom DNS interne pour faire référence à l'adresse IP interne d'une instance, 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 le nom DNS interne d'une instance de VM

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. vous connecter à l'instance de VM ;
  2. Interrogez les métadonnées hostname :

    VM Linux

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

    VM Windows

    Invoke-RestMethod `
      -Headers @{"Metadata-Flavor" = "Google"} `
      -Uri "http://metadata.google.internal/computeMetadata/v1/instance/hostname"
    

Le serveur de métadonnées renvoie le nom d'hôte de la VM dans l'un des formats suivants et affiche le type de nom DNS interne utilisé par la machine virtuelle :

  • DNS zonal : VM_NAME.ZONE.c.PROJECT_ID.internal
  • DNS global : VM_NAME.c.PROJECT_ID.internal

Dans le résultat :

  • VM_NAME : nom de l'instance de VM
  • ZONE : zone où se trouve l'instance
  • PROJECT_ID : projet auquel l'instance appartient

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 permet de 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 VM_NAME.ZONE.c.PROJECT_ID.internal -c 1

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

Remplacez l'élément suivant :

  • VM_NAME : nom de l'instance de VM
  • ZONE : zone où se trouve l'instance
  • PROJECT_ID : 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.

Sur les distributions Linux qui stockent des informations DHCP dans systemd.resolved.conf, vous pouvez consulter les entrées DNS régionales et globales dans le fichier /etc/systemd/resolved.conf.

Note: VPC networks have a default maximum transmission unit (MTU) of 1460 bytes. However, the network MTU can be set to 1500 bytes. See Maximum transmission unit for background on network MTUs.

DNS zonal

Exemple de fichier zonal 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

Remplacez l'élément suivant :

  • ZONE : zone où se trouve votre instance
  • PROJECT_ID : 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 "VM_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;
}

Remplacez l'élément suivant :

  • VM_NAME : nom de la VM
  • ZONE : zone où se trouve votre VM.
  • PROJECT_ID : projet auquel appartient la VM.

DNS global

Exemple de fichier global resolv.conf :

# 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

Remplacez PROJECT_ID par le projet auquel l'instance appartient.

Exemple de fichier global dhcp.lease :

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 "VM_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;
}

Remplacez l'élément suivant :

  • VM_NAME : nom de la VM
  • PROJECT_ID : projet auquel appartient la VM.

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 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 via leur nom d'instance.
  • Si vous modifiez manuellement 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.

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 votre VM, 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 la VM. 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 DNS zonaux et globaux pour 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 dans 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.

La variable VmDnsSetting accepte les paramètres suivants :

  • Recommandation : 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. Cette option est à privilégier et plus fiable à 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.
  • 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. Cette option peut être utilisée comme étape intermédiaire pour tester des noms DNS zonaux.
  • Définissez VmDnsSetting=GlobalDefault pour que les instances enregistrent à la fois les noms DNS globaux et zonaux, mais n'utilisez que des noms globaux comme noms de domaine par défaut et entrées de chemin de recherche. 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.

Notez que la migration d'un projet vers une autre organisation ne modifie pas le nom DNS par défaut du projet.

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

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

Après avoir actualisé le bail DHCP, vérifiez si votre VM est activée pour le DNS zonal.

Migrer des applications existantes vers des noms DNS zonaux

Le DNS global a été remplacé par le DNS zonal. Si vos projets existants utilisent toujours un DNS global, Google vous recommande vivement de migrer vos instances et applications existantes pour utiliser des noms DNS zonaux. Les noms DNS zonaux réduisent les risques de pannes interrégionales.

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 désignent 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 avant de 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. Une fois que vos applications s'exécutent correctement en n'utilisant que des noms de domaine zonaux, vous pouvez désactiver les noms globaux sur ce réseau VPC. Configurez des instances sur votre réseau cloud privé virtuel 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 les 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.
  3. Répétez ce processus sur chacun de vos réseaux cloud privés virtuels 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.

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. Pour en savoir plus sur la définition des valeurs de métadonnées d'un projet ou d'une instance, consultez la section Définir des métadonnées personnalisées.

Pour forcer la modification de la configuration DNS, redémarrez le réseau de l'instance de VM :

  • Container-optimized OS/Ubuntu : sudo systemctl restart systemd-networkd
  • CentOS/RHEL/Fedora CoreOS/Rocky Linux : sudo systemctl restart network
  • Debian : sudo systemctl restart networking
  • Windows : ipconfig /renew

Si vous exécutez votre application dans des conteneurs, sur Google 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.

Étape suivante

  • Pour en savoir plus sur les réseaux VPC Google Cloud, 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.