Présentation du DNS interne

Linux Windows

Lorsque vous créez des instances de machine virtuelle (VM) Compute Engine, le DNS interne crée automatiquement un nom DNS pour la VM. Ce nom DNS facilite la communication interne entre VM en résolvant les adresses IP internes. Les réseaux de cloud privés virtuels sur Google Cloud utilisent le service DNS interne pour permettre aux VM 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 VM :

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

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

Limites

Les noms DNS internes ont les spécifications suivantes :

Le nom DNS interne d'une 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 VM.
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.

Noms DNS internes zonaux et globaux

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

DNS zonal : les noms de VM doivent être uniques dans chaque zone, mais vous pouvez les réutiliser dans plusieurs zones. Par exemple, vous pouvez avoir plusieurs VM nommées instance-1 tant que les VM se trouvent dans des zones différentes.
DNS global : les noms de VM doivent être uniques dans chaque projet. Avec le DNS global, vous ne pouvez pas réutiliser les noms des VM 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 la VM doit être unique dans l'ensemble du projet. Par conséquent, vous ne pouvez créer de VM 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.

Type de DNS interne	Nom de domaine complet
DNS zonal	`VM_NAME.ZONE.c.PROJECT_ID.internal`
DNS global (à l'échelle du projet)	`VM_NAME.c.PROJECT_ID.internal`

Remplacez les éléments suivants :

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 de VM doit être unique dans le projet.
ZONE : zone où se trouve votre instance.
PROJECT_ID : projet auquel appartient la VM.

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 VM 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 la VM 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

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.

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.

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.

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 VM. Vous pouvez configurer des enregistrements PTR qui vous permettent de remplacer l'URL DNS interne par défaut de votre VM 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 VM, consultez la page Créer un enregistrement PTR pour une instance de VM.

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é.

DNS interne et DHCP

Les VM Compute Engine sont configurées pour renouveler les baux DHCP toutes les 24 heures. Pour les VM activées pour des DNS zonaux, le bail DHCP expire toutes les heures. Les VM 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 resolv.conf, le DHCP par défaut est rétabli chaque fois que le bail DHCP expire sur votre VM. 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 de Linux que vous utilisez. Par exemple, Red Hat Enterprise Linux et Debian utilisent le fichier de configuration /etc/dhcp/dhcpd.conf. Sur CentOS, vous devez utiliser l'utilitaire de ligne de commande Network Manager nmcli.

Reportez-vous à la documentation de votre système d'exploitation pour savoir comment configurer les paramètres réseau personnalisés DHCP et DNS.

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 VM à 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 VM. Sur les VM 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.

Configuration DNS zonale

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 les éléments suivants :

ZONE : zone où se trouve votre VM.
PROJECT_ID : projet auquel appartient la VM.

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.

Configuration DNS globale

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 appartient la VM.

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