Internes DNS

Virtual Private Cloud-Netzwerke in der GCP verfügen über einen internen DNS-Dienst, mit dem Instanzen im selben Netzwerk über interne DNS-Namen aufeinander zugreifen können. Interne DNS-Einträge werden in der Zone .internal erstellt. Wenn Sie VM-Instanzen verwalten, werden die internen DNS-Einträge von der GCP automatisch erstellt, aktualisiert und entfernt.

Löschen Sie eine VM-Instanz beispielsweise, wird ihr interner DNS-Eintrag automatisch von der GCP entfernt. Wenn Sie eine neue VM mit demselben Namen erstellen, erzeugt die GCP einen neuen Datensatz.

Informationen zum internen DNS

Interne DNS-Namen haben folgende Spezifikationen:

  • Der interne DNS-Name einer VM-Instanz wird nur in die primäre interne IP-Adresse aufgelöst. Interne DNS-Namen können nicht für die Verbindung mit den externen IP-Adressen einer Instanz verwendet werden.

  • Interne DNS-Namen können nicht für die Auflösung in sekundäre Alias-IPs konfiguriert werden.

  • Interne DNS-Namen können nur von anderen VMs aufgelöst werden, die sich in demselben Projekt befinden und dieselbe VPC oder ein Legacy-Netzwerk verwenden. Es ist nicht möglich, internes DNS für den Kontakt mit Instanzen in anderen VPC-Netzwerken zu verwenden, auch wenn sie sich im selben Projekt befinden.

Interne DNS, Cloud DNS und benutzerdefinierte Hostnamen

Interne DNS und Cloud DNS sind unterschiedliche Angebote. Interne DNS-Namen werden von der GCP automatisch erstellt. Wenn Sie benutzerdefinierte DNS-Namen für Ihre VMs erstellen möchten, können Sie eine private Cloud DNS-Zone verwenden.

Außerdem können Sie bei der Erstellung einen benutzerdefinierten Hostnamen für eine VM angeben. Benutzerdefinierte Hostnamen, die auf diese Weise zugewiesen wurden, werden nicht durch das interne DNS aufgelöst. Sie müssen jedoch weiterhin einen entsprechenden DNS-Eintrag in der entsprechenden Zone erstellen (z. B. mithilfe von Cloud DNS). Weitere Informationen finden Sie unter VM-Instanz mit einem benutzerdefinierten Hostnamen erstellen.

Typen von internen DNS-Namen

Es gibt in der GCP zwei Typen von internen DNS-Namen. Der standardmäßige interne DNS-Typ wird anhand des Zeitpunktes der Aktivierung der Compute Engine API festgelegt.

Interner DNS-Typ Vollständig qualifizierter Domainname (Fully Qualified Domain Name – FQDN) Standardtyp des Projekts
Zonales DNS [INSTANCE_NAME].[ZONE].c.[PROJECT_ID].internal Standardeinstellung für alle Organisationen oder eigenständigen Projekte, bei denen die Compute Engine API nach dem 06. September 2018 aktiviert wurde.
Globales (projektweites) DNS [INSTANCE_NAME].c.[PROJECT_ID].internal Standardeinstellung für alle Organisationen oder eigenständigen Projekte, bei denen die Compute Engine API vor dem 6. September 2018 aktiviert wurde.

Dabei gilt:

  • [INSTANCE_NAME] ist der Name der Instanz.
  • [ZONE] ist die Zone, in der sich Ihre Instanz befindet.
  • [PROJECT_ID] ist das Projekt, zu dem die Instanz gehört.

Sie können steuern, welcher Typ des internen DNS-Namens auf Projekt- bzw. Instanzebene verwendet wird. Weitere Informationen hierzu finden Sie unter DNS-Namen für Projekte oder Instanzen konfigurieren.

Interne DNS-Namen und freigegebene VPC

Sie können einen internen DNS-Namen verwenden, um auf eine interne IP-Adresse einer VM zu verweisen, selbst wenn sich die IP-Adresse in einem freigegebenen VPC-Netzwerk in einem Hostprojekt befindet. Bei freigegebenen VPC ist der Projekt-ID-Teil des zonalen oder eines globalen (projektweiten) internen DNS-Namens die ID des Dienstprojekts.

Internen DNS-Namen für eine VM bestimmen

Mit dem folgenden Verfahren können Sie den einer VM zugewiesenen internen DNS-Namen auslesen. Als gültige Datenquelle für den internen DNS-Namen fungiert der Metadatenserver.

  1. Stellen Sie eine Verbindung zur Instanz her.
  2. Rufen Sie den Hostnamen über die Metadaten der Instanz auf:

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

Das Format des Hostnamens gibt den Typ des internen DNS-Namens an, der von der VM verwendet wird.

Über das interne DNS auf VMs zugreifen

Der Metadatenserver ist zugleich der Nameserver-Resolver für DNS-Abfragen von der VM. Der Metadatenserver löst alle DNS-Abfragen sowohl für interne als auch externe DNS-Namen auf. Bei externen DNS-Abfragen leitet der Metadatenserver Anfragen an die öffentlichen Nameserver von Google weiter.

Im folgenden Beispiel wird mit ping eine Instanz kontaktiert, die ein zonales DNS verwendet. Diese Methode funktioniert, sofern Sie eine Firewallregel erstellt haben, die eingehenden ICMP-Traffic für die Instanz zulässt.

$ 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

Dabei gilt:

  • [INSTANCE_NAME] ist der Name der Instanz.
  • [ZONE] ist die Zone, in der sich die Instanz befindet.
  • [PROJECT_ID] ist das Projekt, zu dem die Instanz gehört.

Internes DNS und resolv.conf

Standardmäßig speichern die meisten Linux-Distributionen DHCP-Informationen in resolv.conf. Compute Engine-Instanzen sind so konfiguriert, dass DHCP-Leases alle 24 Stunden erneuert werden. Bei Instanzen, die für zonales DNS aktiviert sind, läuft das DHCP-Lease stündlich ab. Durch die DHCP-Erneuerung wird diese Datei überschrieben und alle vorgenommenen Änderungen werden gegebenenfalls rückgängig gemacht. Instanzen, die zonales DNS verwenden, enthalten sowohl zonale als auch globale Einträge in der Datei resolv.conf.

Zonales DNS

Beispiel für eine zonale resolv.conf-Datei:

# 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

Dabei gilt:

  • [ZONE] ist die Zone, in der sich Ihre Instanz befindet.
  • [PROJECT_ID] ist das Projekt, zu dem die Instanz gehört.

Beispiel für eine zonale dhcp.lease-Datei:

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

Dabei gilt:

  • [INSTANCE_NAME] ist der Name der Instanz.
  • [ZONE] ist die Zone, in der sich Ihre Instanz befindet.
  • [PROJECT_ID] ist das Projekt, zu dem die Instanz gehört.

Globales DNS

Beispiel für eine globale resolv.conf-Datei:

# 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

wobei [PROJECT_ID] das Projekt ist, zu dem die Instanz gehört.

Beispiel für eine globale dhcp.lease-Datei:

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

Dabei gilt:

  • [INSTANCE_NAME] ist der Name der Instanz.
  • [PROJECT_ID] ist das Projekt, zu dem die Instanz gehört.

Diese Dateien sind mit folgenden Einschränkungen verbunden:

  • Der Suchpfad kann nur sechs Einträge verarbeiten, von denen drei standardmäßig von Compute Engine bereitgestellt werden. Wenn Sie dem Suchpfad mehr als sechs Einträge hinzufügen, werden Suchregeln nach dem sechsten Eintrag von Ihrem Betriebssystem nicht angewendet Dies kann dazu führen, dass Compute Engine-Funktionen wie der Zugriff auf Instanzen über ihre Instanznamen nicht mehr verfügbar sind.
  • Wenn resolv.conf manuell bearbeitet wird, wird das Standard-DHCP nach Ablauf des 24-Stunden-DHCP-Leases wiederhergestellt. Bei Instanzen mit zonalem DNS läuft das DHCP-Lease jede Stunde ab. Damit statische Änderungen an der Datei resolv.conf vorgenommen werden können, ist es bei verschiedenen Linux-Distributionen möglich, der DHCP-Richtlinie Elemente voranzustellen oder anzuhängen.

Debian 9

Beispieldatei /etc/dhcp/dhclient.conf:

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

Dabei ist mydomain.com die neue Suchdomain und 172.16.1.1 die IP Ihres DNS-Servers.

Zonale DNS-Namen

Zonale DNS-Namen umfassen den Namen der Instanz, die Zone, in der sich die Instanz befindet, und das Projekt, zu dem die Instanz gehört. Globale DNS-Namen umfassen nicht die Zone, in der sich die Instanz befindet. Zonale DNS-Namen an einem bestimmten Standort funktionieren unabhängig von anderen Standorten, sodass Sie fehlertolerantere Anwendungen mit mehreren Regionen und besseren Verfügbarkeitsmerkmalen erstellen können.

Bestehende Projekte und Organisationen können zwar weiterhin globale DNS-Namen verwenden. Es wird jedoch empfohlen, zu zonalen DNS-Namen zu migrieren.

DNS-Namen für Projekte oder Instanzen konfigurieren

Zonale DNS- und/oder globale DNS-Suchpfade auf Instanzen können Sie aktivieren, indem Sie die Variable VmDnsSetting in den Metadaten entweder eines Projekts oder einer Instanz festlegen. Wenn Sie die Variable VmDnsSetting in den Metadaten einer bestimmten Instanz festlegen, werden alle aus Projektmetadaten dieser Instanz übernommenen VmDnsSetting-Variablen überschrieben.

  • Legen Sie VmDnsSetting=ZonalOnly fest, damit die Instanzen nur anhand ihrer zonalen DNS-Namen adressierbar sind. Die Instanzen behalten weiterhin sowohl den zonalen als auch den globalen Suchpfad bei, ihre globalen DNS-Namen funktionieren jedoch nicht mehr. Andere Instanzen können Instanzen mit dieser Einstellung nur anhand ihrer zonalen DNS-Namen adressieren. Sie können diese Instanzen nicht anhand ihrer globalen DNS-Namen oder Suchpfade adressieren. Dies ist die bevorzugte Option, sofern sie von Ihren Anwendungen unterstützt wird. Dies ist die Standardeinstellung für Instanzen in eigenständigen Projekten und in einer Organisation erstellten Projekten, bei denen die Compute Engine API nach dem 06. September 2018 aktiviert wurde. Bei der Migration eines Projektes in eine Organisation ändert sich sein Standard-DNS-Name nicht.
  • Legen Sie VmDnsSetting=ZonalPreferred fest, damit zonale DNS-Suchpfade aktiviert werden, der globale DNS-Name jedoch beibehalten wird. Instanzen mit dieser Einstellung können sich gegenseitig entweder anhand ihrer zonalen oder globalen DNS-Namen adressieren. Sie können auch weiterhin Instanzen adressieren, die nur für globale DNS-Namen konfiguriert sind.
  • Legen Sie VmDnsSetting=GlobalOnly fest, damit Instanzen nur globale Namen als Domainnamen und Suchpfadeinträge verwenden. Verwenden Sie diesen Wert, um Instanzen aus einer projektübergreifenden zonalen DNS-Einstellung auszuschließen oder um Instanzen so wiederherzustellen, dass nur globale DNS-Namen verwendet werden. Dies ist die Standardeinstellung für Instanzen in eigenständigen Projekten und in einer Organisation erstellten Projekten, bei denen die Compute Engine API vor dem 06. September 2018 aktiviert wurde. Bei der Migration eines Projektes in eine Organisation ändert sich sein Standard-DNS-Name nicht.

Lesen Sie Benutzerdefinierte Metadaten einrichten, um weitere Informationen zum Festlegen der Werte für Projektmetadaten oder Instanzmetadaten zu erhalten.

Nachdem Sie die Variable VmDnsSetting für eine Instanz konfiguriert haben, aktualisieren Sie das DHCP-Lease für die Instanz. Dies können Sie folgendermaßen tun: Starten Sie die Instanz neu, warten Sie auf den Ablauf des Lease oder führen Sie einen der folgenden Befehle aus:

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

Vorhandene Anwendungen in zonale DNS-Namen migrieren

Vorhandene Projekte können zwar weiterhin globale DNS-Namen verwenden, es wird jedoch empfohlen, die vorhandenen Instanzen und Anwendungen auf zonale DNS-Namen zu migrieren und damit von den Vorteilen des zonalen DNS-Systems zu profitieren. Die Migration können Sie im Allgemeinen so vornehmen:

  1. Überprüfen Sie Ihre Anwendungen und aktualisieren Sie sie, um Kompatibilitätsprobleme bei ausschließlich zonalen Einstellungen zu beheben:
    • Anwendungen, die Instanzen über den Instanznamen oder globale vollständig qualifizierte Domainnamen adressieren: Instanznamen und globale Instanznamen werden in einer ausschließlich zonalen Umgebung nicht immer aufgelöst. Aktualisieren Sie diese Namen, um vollständig qualifizierte zonale Domainnamen als Best Practice zu verwenden.
    • Anwendungen, die ein bestimmtes globales Format für vollständig qualifizierte Domainnamen annehmen: Die Annahme eines Domainnamen-Formats stellt ein grundlegendes Problem im Anwendungsdesign dar. Google empfiehlt, Ihre Anwendungen so zu gestalten, dass sie unabhängig vom Format des Domainnamens funktionieren.
    • Anwendungen, die keine Änderungen am Domainnamen erwarten: Einige Anwendungen erwarten möglicherweise keine Änderungen am Domainnamen und erfordern einen vollständigen Neustart, um die neuen Namen abzurufen. Wenn möglich, aktualisieren Sie Ihre Anwendungen, um Änderungen am Domainnamen der Instanz zu erkennen und zu bearbeiten.
  2. Konfigurieren Sie Instanzen in Ihrem internen VPC-Netzwerk, um die Einstellung VmDnsSetting=ZonalPreferred zu verwenden, die sowohl globale als auch zonale DNS-Namen nutzt. In dieser Übergangsphase können Instanzen weiterhin globale Namen verwenden, bis Ihre Anwendungen in der Lage sind, nur zonale Namen zu verwenden:
    1. Aktivieren Sie VmDnsSetting=ZonalPreferred auf einer Instanz, indem Sie diesen Wert in den benutzerdefinierten Metadaten einstellen.
    2. Aktualisieren Sie das DHCP-Lease für diese Instanz, damit sie zonale DNS-Namen verwendet:
      • Linux-Instanzen: sudo dhclient -v -r
      • Windows Server-Instanzen: ipconfig /renew
    3. Testen Sie die Anwendungen auf der Instanz, um zu prüfen, ob sie wie erwartet funktionieren. Einige Anwendungen, die keine Änderungen am Domainnamen erwarten, erfordern unter Umständen einen vollständigen Neustart, um die neuen Namen abzurufen.
    4. Wiederholen Sie diesen Vorgang, um VmDnsSetting=ZonalPreferred zu aktivieren und das DHCP-Lease für die verbleibenden Instanzen in Ihrem VPC-Netzwerk zu aktualisieren, bis alle wie erwartet funktionieren und nur die zonalen DNS-Namen verwenden. Alternativ können Sie VmDnsSetting=ZonalPreferred in den Projektmetadaten festlegen, um jede Instanz im Projekt für die Verwendung zonaler DNS-Namen zu konfigurieren.
  3. Sobald Ihre Anwendungen ordnungsgemäß ausgeführt werden und nur zonale Domainnamen mit der Einstellung VmDnsSetting=ZonalPreferred verwenden, können Sie globale Namen in diesem VPC-Netzwerk deaktivieren. Konfigurieren Sie Instanzen in Ihrem internen VPC-Netzwerk für die Verwendung der Einstellung VmDnsSetting=ZonalOnly, die nur die zonalen DNS-Namen verwendet:
    1. Aktivieren Sie VmDnsSetting=ZonalOnly auf einer Instanz, indem Sie diesen Wert in den benutzerdefinierten Metadaten einstellen.
    2. Aktualisieren Sie das DHCP-Lease für diese Instanz, damit sie zonale DNS-Namen verwendet:
      • Linux-Instanzen: sudo dhclient -v -r
      • Windows Server-Instanzen: ipconfig /renew
    3. Testen Sie die Anwendungen für diese Instanz, um sicherzustellen, dass sie wie erwartet funktionieren.
    4. Wiederholen Sie diesen Vorgang, um VmDnsSetting=ZonalOnly zu aktivieren und das DHCP-Lease für die verbleibenden Instanzen in Ihrem VPC-Netzwerk zu aktualisieren, bis alle wie erwartet funktionieren und nur die zonalen DNS-Namen verwenden.
  4. Wiederholen Sie diesen Vorgang in jedem Ihrer VPC-Netzwerke, bis alle Instanzen in Ihrem Projekt die Einstellung VmDnsSetting=ZonalOnly verwenden. Sie können VmDnsSetting=ZonalOnly in den Metadaten auf Projektebene festlegen, damit diese Einstellung automatisch auf alle in diesem Projekt erstellten Instanzen angewendet wird. Alternativ können Sie in den Projektmetadaten VmDnsSetting=ZonalOnly festlegen, um jede Instanz in Ihrem Projekt für die Verwendung zonaler DNS-Namen zu konfigurieren.

Zonales DNS in einem Projekt oder auf Instanzen deaktivieren

Um zonales DNS für eine bestimmte Instanz zu deaktivieren, legen Sie VmDnsSetting=GlobalOnly in den Metadaten dieser Instanz fest. Um zonales DNS für das gesamte Projekt zu deaktivieren, legen Sie VmDnsSetting=GlobalOnly in den Projektmetadaten fest und achten Sie darauf, dass keine der Instanzen mit dem Wert VmDnsSetting konfiguriert ist. Lesen Sie Benutzerdefinierte Metadaten einrichten, um weitere Informationen zum Festlegen der Werte für Projektmetadaten oder Instanzmetadaten zu erhalten.

Wenn Sie die sofortige Aktualisierung des DHCP-Lease erzwingen müssen, verwenden Sie einen der folgenden Befehle:

  • Container-Optimized OS (Google Kubernetes Engine): sudo systemctl restart systemd-networkd
  • Debian/Google App Engine Flex-Instanzen: sudo dhclient -r -v eth0 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v eth0
  • Ubuntu 15.04 und höher: sudo dhclient -r -v ens4 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v ens4
  • Ubuntu niedriger als 15.04: sudo dhclient -r -v eth0 && sudo rm /var/lib/dhcp/dhclient.* ; sudo dhclient -v eth0
  • Windows: ipconfig /renew

Einige Betriebssysteme ändern ihre DNS-Konfigurationen nicht vollständig, selbst nachdem das DHCP-Lease erneuert wurde. Starten Sie in diesem Fall das Netzwerk der VM-Instanz neu, um die DNS-Konfigurationsänderung zu erzwingen:

  • Ubuntu: sudo ifdown --exclude=lo -a && sudo ifup --exclude=lo -a
  • CentOS: sudo /etc/init.d/network restart
  • CoreOS: sudo systemctl restart systemd-networkd
  • Containeroptimiertes Betriebssystem: sudo systemctl restart systemd-networkd

Wenn Sie Ihre Anwendung in Containern, in Kubernetes Engine oder in einer flexiblen App Engine-Umgebung ausführen, wird die DNS-Konfiguration in den Containereinstellungen möglicherweise erst automatisch aktualisiert, nachdem Sie die Container neu gestartet haben. Um zonales DNS für diese Containeranwendungen zu deaktivieren, müssen Sie VmDnsSetting=GlobalOnly für Ihre Projekte und Instanzen einstellen und die Container neu starten, damit die DNS-Einstellungen in den ursprünglichen Zustand zurückversetzt werden.

Weitere Informationen

  • Informationen zu GCP-VPC-Netzwerken finden Sie in der VPC-Übersicht.
  • Anleitungen zum Erstellen und Ändern von VPC-Netzwerken finden Sie unter VPC verwenden
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine-Dokumentation