Internes DNS


Virtual Private Cloud-Netzwerke in Google Cloud haben einen internen DNS-Dienst, über den Instanzen im selben Netzwerk mithilfe interner DNS-Namen aufeinander zugreifen können. Interne A-Einträge für VM-Instanzen werden in einer DNS-Zone für .internal erstellt. PTR-Einträge für VM-Instanzen werden in entsprechenden Reverse-Zonen erstellt. Während Sie Ihre Instanzen verwalten, werden diese DNS-Einträge automatisch von Google Cloud erstellt, aktualisiert und entfernt.

Löschen Sie zum Beispiel eine Instanz, entfernt Google Cloud automatisch die zugehörigen A- und PTR-Einträge für den DNS-Namen .internal. Wenn Sie dann eine Instanz mit demselben Namen anlegen, erstellt Google Cloud einen Eintrag für den Ersatz.

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.

Typen von internen DNS-Namen

Google Cloud verfügt über zwei Arten von internen DNS-Namen. Der standardmäßige interne DNS-Typ wird anhand des Zeitpunktes der Aktivierung der Compute Engine API festgelegt.

Im Allgemeinen empfiehlt Google dringend, zonales DNS zu verwenden, da es eine höhere Zuverlässigkeit garantiert, indem es Ausfälle bei der DNS-Registrierung auf einzelne Zonen isoliert.

Interner DNS-Typ Vollständig qualifizierter Domainname (Fully Qualified Domain Name – FQDN) Standardtyp des Projekts Hinweise
Zonales DNS VM_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. Namen von VM-Instanzen müssen innerhalb der Zone eindeutig sein, können aber zonenübergreifend wiederholt werden. Beispiel: Sie können mehrere Instanzen mit dem Namen instance-1 haben, solange sich die Instanzen in verschiedenen Zonen befinden.
Globales (projektweites) DNS VM_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. VM-Instanznamen müssen im gesamten Projekt eindeutig sein. Sie können Instanznamen nicht wiederholen.

Dabei gilt:

  • VM_NAME: Name der VM für das zonale DNS, dieser Wert muss innerhalb der Zone eindeutig sein, kann aber zonenübergreifend wiederholt werden. Beim globalen DNS muss der Instanzname im gesamten Projekt eindeutig sein.
  • ZONE: Zone, in der sich Ihre Instanz befindet.
  • PROJECT_ID ist das Projekt, zu dem die Instanz gehört.

Wie Sie steuern, welche Art von internem DNS-Namen auf Projekt- oder Instanzebene verwendet wird, erfahren Sie unter DNS-Namen für Ihr Projekt oder Ihre Instanzen konfigurieren.

PTR-Einträge und internes DNS

Der interne DNS-Dienst von Google Cloud erstellt automatisch PTR-Einträge für VMs in den folgenden Reverse-Zonen:

  • 10.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 16.172.in-addr.arpa., 17.172.in-addr.arpa., ... bis 31.172.in-addr.arpa.

Benutzerdefinierte Einträge mit Cloud DNS

Sie können eine private Cloud DNS-Zone verwenden, um benutzerdefinierte DNS-Einträge für Ihre VM-Instanzen zu erstellen. Sie können PTR-Einträge konfigurieren, mit denen Sie die standardmäßige URL für die interne DNS-VM mit der von Ihnen angegebenen benutzerdefinierten URL überschreiben können.

Informationen zum Erstellen von benutzerdefinierten PTR-Einträgen, die die automatisch erstellten Namen interner DNS-PTR-Einträge überschreiben, finden Sie unter PTR-Einträge in privaten Zonen verwenden.

Benutzerdefinierte Hostnamen

Beim Erstellen einer VM können Sie ihr einen benutzerdefinierten Hostnamen geben. Benutzerdefinierte Hostnamen, die auf diese Weise zugewiesen sind, werden nicht vom internen DNS aufgelöst. Bei benutzerdefinierten Hostnamen müssen Sie in der entsprechenden Zone einen entsprechenden DNS-Eintrag erstellen, z. B. mit Cloud DNS. Weitere Informationen finden Sie unter VM-Instanz mit einem benutzerdefinierten Hostnamen erstellen.

Interne DNS-Namen und freigegebene VPC

Sie können einen internen DNS-Namen verwenden, um auf die interne IP-Adresse einer Instanz zu verweisen. Dies ist auch dann möglich, wenn sich diese IP-Adresse in einem freigegebenen VPC-Netzwerk in einem Hostprojekt befindet. Bei einer 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-Instanz ermitteln

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. Verbindung zur VM-Instanz herstellen
  2. Fragen Sie die hostname-Metadaten ab:

    Linux-VMs

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

    Windows-VMs

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

Der Metadatenserver gibt den Hostnamen der VM in einem der folgenden Formate zurück und zeigt den Typ des internen DNS-Namens an, der von der VM verwendet wird:

  • Zonal DNS: VM_NAME.ZONE.c.PROJECT_ID.internal
  • Global DNS: VM_NAME.c.PROJECT_ID.internal

Dabei gilt:

  • VM_NAME: Der Name der VM-Instanz
  • ZONE: die Zone, in der sich die Instanz befindet.
  • PROJECT_ID ist das Projekt, zu dem die Instanz gehört.

Über das interne DNS auf VMs zugreifen

Der Metadatenserver ist auch der Namensserver-Resolver für DNS-Abfragen, die von der VM ausgegeben werden. Der Metadatenserver löst alle DNS-Abfragen auf, sowohl in interne DNS-Namen als auch in externe DNS-Namen. 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 nur, wenn Sie eine Firewallregel erstellt haben, die eingehenden ICMP-Traffic an die Instanz zulässt.

$ 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

Dabei gilt:

  • VM_NAME: Der Name der VM-Instanz
  • ZONE: 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-Freigaben alle 24 Stunden erneuert werden. Bei Instanzen, die für ein zonales DNS aktiviert sind, läuft die DHCP-Freigabe stündlich ab. Durch die DHCP-Erneuerung wird diese Datei überschrieben und alle vorgenommenen Änderungen werden gegebenenfalls rückgängig gemacht. Instanzen mit einem zonalen DNS enthalten in der Datei resolv.conf sowohl zonale als auch globale Einträge.

Bei Linux-Distributionen, die DHCP-Informationen in systemd.resolved.conf speichern, können Sie zonale und globale DNS-Einträge in der Datei /etc/systemd/resolved.conf aufrufen.

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.

Zonales DNS

Beispiel für die zonale Datei 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

Dabei gilt:

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

Beispiel für die zonale Datei 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;
}

Dabei gilt:

  • VM_NAME: Der Name der VM
  • ZONE: Zone, in der sich Ihre VM befindet
  • PROJECT_ID ist das Projekt, zu dem die Instanz gehört.

Globales DNS

Beispiel für die globale Datei 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

Ersetzen Sie PROJECT_ID durch das Projekt, zu dem die Instanz gehört.

Beispiel für die globale Datei 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;
}

Dabei gilt:

  • VM_NAME: Der Name der VM
  • 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 Einträge hinzufügen, sodass dieser insgesamt mehr als sechs Einträge enthält, werden Suchregeln nach dem sechsten Eintrag von Ihrem Betriebssystem nicht angewendet. Dies kann dazu führen, dass die Compute Engine-Funktionen nicht mehr funktionieren, wie beispielsweise der Zugriff auf Instanzen über ihre Instanznamen.
  • Bei manueller Bearbeitung von resolv.conf wird das Standard-DHCP nach Ablauf des 24-Stunden-DHCP-Lease wiederhergestellt. Bei Instanzen mit zonalem DNS läuft das DHCP-Lease jede Stunde ab. Um statische Änderungen in der Datei resolv.conf vorzunehmen, können mehrere Linux-Distributionen zulassen, dass der DHCP-Richtlinie Elemente vorangestellt oder an diese angehängt werden.

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-Adresse Ihres DNS-Servers.

Zonale DNS-Namen

Zonale DNS-Namen umfassen den Namen Ihrer VM, die Zone, in der sich Ihre VM befindet, und das Projekt, zu dem die VM gehört. Globale DNS-Namen umfassen nicht die Zone, in der sich die Instanz befindet. Zonale DNS-Namen an einem Standort funktionieren unabhängig von anderen Standorten, sodass Sie mehr fehlertolerante multiregionale Anwendungen mit verbesserter Verfügbarkeit 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

Aktivieren Sie das zonale DNS und das globale DNS für Ihre Instanzen. Legen Sie hierfür in den Metadaten des Projekts oder der Instanz die Variable VmDnsSetting fest. Wenn Sie die Variable VmDnsSetting für Metadaten einer bestimmten Instanz festlegen, werden alle Variablen vom Typ VmDnsSetting außer Kraft gesetzt, die aus Projektmetadaten für diese Instanz übernommen wurden.

Die Variable VmDnsSetting unterstützt die folgenden Einstellungen:

  • Empfehlung: Legen Sie VmDnsSetting=ZonalOnly fest, damit Ihre Instanzen nur über ihre 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 mit ihren zonalen DNS-Namen, nicht aber mit ihren globalen DNS-Namen oder Suchpfaden adressieren. Dies ist die bevorzugte und zuverlässigere Option, sofern die Anwendungen dies unterstützen können. 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 6. September 2018 aktiviert wurde.
  • Legen Sie VmDnsSetting=ZonalPreferred fest, um zonale DNS-Suchpfade zu aktivieren und gleichzeitig den globalen DNS-Namen beizubehalten. 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. Diese Option kann als Zwischenschritt verwendet werden, um zonale DNS-Namen zu probieren und zu testen.
  • Legen Sie VmDnsSetting=GlobalDefault so fest, dass Instanzen sowohl globale als auch zonale DNS-Namen registrieren, aber nur globale Namen als Standarddomainnamen und Suchpfadeinträge verwenden. 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.

Beachten Sie, dass durch die Migration eines Projekts zu einer anderen Organisation der Standard-DNS-Name des Projekts nicht geändert wird.

Informationen zum Festlegen von Werten für Projekt- oder Instanzmetadaten finden Sie unter Benutzerdefinierte Metadaten festlegen.

Nachdem Sie die Variable VmDnsSetting für eine Instanz konfiguriert haben, aktualisieren Sie die DHCP-Freigabe für die Instanz. Dazu können Sie die Instanz neu starten, auf den Ablauf der Freigabe warten oder einen der folgenden Befehle ausführen:

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

Nachdem Sie die DHCP-Freigabe aktualisiert haben, prüfen Sie, ob Ihre VM für das zonale DNS aktiviert ist.

Vorhandene Anwendungen zu zonalen DNS-Namen migrieren

Globales DNS wurde durch zonales DNS ersetzt. Wenn Ihre vorhandenen Projekte noch globales DNS verwenden, empfiehlt Google dringend, Ihre vorhandenen Instanzen und Anwendungen zu zonalen DNS-Namen zu migrieren. Zonale DNS-Namen verringern das Risiko regionsübergreifender Ausfälle.

Die Migration können Sie im Allgemeinen so vornehmen:

  1. Prü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 bewährte Methode zu verwenden.
    • Anwendungen, die ein bestimmtes globales Format für vollständig qualifizierte Domainnamen annehmen: Die Annahme eines Domainnamensformats stellt im Anwendungsdesign in der Regel ein grundlegendes Problem dar. Google empfiehlt, Ihre Anwendungen so zu gestalten, dass sie unabhängig vom Format des Domainnamens funktionieren.
    • Anwendungen, die keine Änderungen der Domainnamen erwarten: Manche Anwendungen erwarten keine Änderungen der Domainnamen und erfordern einen vollständigen Neustart, bevor die neuen Namen übernommen werden. Aktualisieren Sie Ihre Anwendungen nach Möglichkeit, um Änderungen am Domainnamen der Instanz zu erkennen und zu verwalten.
  2. Sobald Ihre Anwendungen ordnungsgemäß ausgeführt werden und nur zonale Domainnamen verwenden, können Sie globale Namen in diesem VPC-Netzwerk deaktivieren. Konfigurieren Sie Instanzen in Ihrem internen VPC-Netzwerk, um die Einstellung VmDnsSetting=ZonalOnly zu verwenden, die nur die zonalen DNS-Namen nutzt.
    1. Aktivieren Sie VmDnsSetting=ZonalOnly auf einer Instanz. Hierfür legen Sie den Wert in den benutzerdefinierten Metadaten fest.
    2. Aktualisieren Sie die DHCP-Freigabe 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 die DHCP-Freigabe für die verbleibenden Instanzen in Ihrem VPC-Netzwerk zu aktualisieren, bis alle wie erwartet funktionieren und nur die zonalen DNS-Namen verwenden.
  3. Wiederholen Sie diesen Vorgang in jedem Ihrer Virtual Private Cloud-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.

Zonales DNS in einem Projekt oder auf Instanzen deaktivieren

Um ein zonales DNS für eine bestimmte Instanz zu deaktivieren, legen Sie in den Metadaten dieser Instanz VmDnsSetting=GlobalOnly fest. Um ein zonales DNS für das gesamte Projekt zu deaktivieren, legen Sie in den Projektmetadaten VmDnsSetting=GlobalOnly fest und achten Sie darauf, dass keine der Instanzen mit dem Wert VmDnsSetting konfiguriert ist. Informationen zum Festlegen von Werten für Projekt- oder Instanzmetadaten finden Sie unter Benutzerdefinierte Metadaten festlegen.

Starten Sie das Netzwerk der VM-Instanz neu, um die Änderung der DNS-Konfiguration zu erzwingen:

  • 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

Wenn Sie Ihre Anwendung in Containern, in Google Kubernetes Engine oder in einer flexiblen App Engine-Umgebung ausführen, wird die DNS-Konfiguration in Ihren Containereinstellungen möglicherweise erst aktualisiert, wenn Sie die Container neu starten. Wenn Sie das zonale DNS für diese Containeranwendungen deaktivieren möchten, legen Sie für Ihre Projekte und Instanzen VmDnsSetting=GlobalOnly fest und starten Sie die Container neu, damit die DNS-Einstellungen in den ursprünglichen Zustand zurückgesetzt werden.

Nächste Schritte

  • Weitere Informationen zu Google Cloud-VPC-Netzwerken finden Sie in der VPC-Übersicht.
  • Informationen zum Erstellen und Ändern von VPC-Netzwerken finden Sie unter VPC verwenden.