Internes DNS

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Wenn Sie Compute Engine-Instanzen erstellen, wird automatisch ein DNS-Name für die Instanz erstellt. Dieser DNS-Name erleichtert die interne Instanz-zu-Instanz-Kommunikation durch das Auflösen interner IP-Adressen. Virtual Private Cloud-Netzwerke in Google Cloud verwenden den internen DNS-Dienst, damit Compute-Instanzen im selben Netzwerk mithilfe interner DNS-Namen aufeinander zugreifen können.

Google Cloud erstellt, aktualisiert und entfernt automatisch die folgenden DNS-Eintragstypen, wenn Sie Ihre Instanzen verwalten:

• DNS-Adresseinträge (A-Einträge) werden für Instanzen in einer DNS-Zone für .internal erstellt.
• PTR-Einträge für Instanzen, die für den umgekehrten DNS-Lookup verwendet werden, werden in entsprechenden Reverse-Zonen erstellt.

Wenn Sie beispielsweise eine Instanz löschen, werden die zugehörigen A- und PTR-Einträge für den internen DNS-Namen automatisch entfernt. Google Cloud Wenn Sie dann eine Instanz mit demselben Namen erstellen,erstellt Google Cloud neue Einträge für den Ersatz.

Beschränkungen

• Die Compute Engine erstellt interne DNS-Namen A und PTR-Einträge nur für die primäre interne IPv4-Adresse der nic0-Netzwerkschnittstelle einer Instanz. Daher muss der Stacktyp der nic0-Netzwerkschnittstelle entweder nur IPv4 oder Dual-Stack sein. Internes DNS unterstützt keine reinen IPv6-Netzwerkschnittstellen (Vorabversion).

• Die Compute Engine erstellt keine internen DNS-Einträge für Folgendes:

  • Die primäre interne IPv4-Adresse einer Netzwerkschnittstelle, die sich von nic0 unterscheidet.
  • Eine externe IPv4-Adresse einer beliebigen Netzwerkschnittstelle.
  • Eine interne IPv4-Adresse aus einem Alias-IP-Bereich einer beliebigen Netzwerkschnittstelle.
  • Ein interner oder externer IPv6-Adressbereich einer beliebigen Netzwerkschnittstelle.

• Für die Auflösung interner DNS-Namen müssen die Client-VM und die VM, die mit dem internen DNS-Eintrag verknüpft ist, folgende Voraussetzungen erfüllen:

  • im selben VPC-Netzwerk.
  • Im selben Projekt (außer in bestimmten Szenarien mit freigegebenen VPCs)

  Weitere Informationen zu Szenarien mit freigegebenen VPCs finden Sie unter Interne DNS-Namen und freigegebene VPCs.

Zonale und globale interne DNS-Namen

Google Cloud unterstützt zwei Arten von internen DNS-Namen:

• Zonales DNS: Instanznamen müssen innerhalb jeder Zone eindeutig sein, Sie können jedoch Instanznamen zonenübergreifend wiederverwenden. Beispiel: Sie können mehrere Instanzen mit dem Namen instance-1 haben, solange sich die Instanzen in verschiedenen Zonen befinden.
• Globales DNS: Instanznamen müssen innerhalb jedes Projekts eindeutig sein. Beim globalen DNS können Sie Instanznamen innerhalb des Projekts nicht wiederverwenden.

Google empfiehlt dringend, zonales DNS zu verwenden, da es eine höhere Zuverlässigkeit bietet, indem es Ausfälle bei der DNS-Registrierung in einzelnen Zonen isoliert. Bei einem Ausfall hat das globale DNS die folgenden Probleme:

• Der Instanzname muss im gesamten Projekt eindeutig sein. Daher können Sie keine neuen Instanzen in Regionen erstellen, in denen Fehler auf der Steuerungsebene auftreten und in denen Sie Projektressourcen haben oder hatten. Google Cloud kann die vorhandenen Ressourcen-DNS-Namen in der nicht verfügbaren Region nicht prüfen.
• Bestimmte Features von Compute Engine sind nicht verfügbar, z. B. das Autoscaling verwalteter Instanzgruppen (MIGs). Daher können Ihre Anwendungen, die Autoscaling verwenden, um Arbeitslastanstiege ordnungsgemäß zu bewältigen, nicht hochskalieren.

Der standardmäßige interne DNS-Typ wird festgelegt, wenn Sie die Compute Engine API aktivieren.

• Der standardmäßige interne DNS-Typ ist zonales DNS.
• Wenn Ihre Organisation oder Ihr eigenständiges Projekt die Compute Engine API vor dem 6. September 2018 aktiviert hat, wird der interne DNS-Standardtyp auf globales DNS festgelegt.

Die voll qualifizierten Domainnamen für interne DNS-Namen werden in der folgenden Tabelle beschrieben.

Ersetzen Sie Folgendes:

• INSTANCE_NAME: der Name der Instanz. Bei zonalem DNS muss dieser Wert innerhalb der Zone eindeutig sein, kann sich aber zonenübergreifend wiederholen. 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.

DNS-Namensauflösung

Instanzen erhalten Informationen zur internen DNS-Auflösung im Rahmen ihrer DHCP-Leases. Die Methode der DNS-Auflösung hängt von der Betriebssystemplattform ab:

• Linux: Standardmäßig werden die internen DNS-Namen vom DNS-Server der Instanz (169.254.169.254:53) aufgelöst.
• Unter Windows löst standardmäßig das Standard-Gateway des Subnetzes interne DNS-Namen auf.

Reverse-Zonen für PTR-Einträge

Der interne DNS-Dienst vonGoogle Clouderstellt automatisch PTR-Einträge für Instanzen 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.

Interne DNS-Namen und freigegebene VPC

Die Client-VM und die VM, die mit dem internen DNS-Eintrag verknüpft ist, können sich in separaten Projekten befinden, müssen aber dasselbe freigegebene VPC-Netzwerk verwenden. Der Client kann sich beispielsweise in einem Dienstprojekt befinden und die mit dem internen DNS-Eintrag verknüpfte VM in einem anderen Dienstprojekt oder im Hostprojekt.

Clients müssen FQDN-Abfragen (Fully Qualified Domain Name) für interne DNS-Einträge stellen, anstatt sich auf Teilabfragen und DNS-Suchdomains zu verlassen. DNS-Suchdomains sind in jedem Projekt aus folgenden Gründen unterschiedlich:

• Der Domainname jedes internen DNS-A-Eintrags enthält die Projekt-ID des Projekts, das die VM enthält. Bei einer VM in einem Dienstprojekt, deren nic0-Netzwerkschnittstelle ein freigegebenes VPC-Netzwerk verwendet, unterscheidet sich das Projekt der VM vom Projekt, das das Netzwerk enthält.

• Ob zonale oder globale (projektweite) interne DNS-Namen verwendet werden, hängt von der Konfiguration des Projekts ab, das die VM enthält.

Weitere Informationen zu Shared VPC finden Sie unter:

• Freigegebene VPC – Übersicht
• Freigegebene VPC bereitstellen

Interne DNS-Namen anpassen

Einige Organisationen oder Anwendungen benötigen möglicherweise benutzerdefinierte interne DNS-Namen anstelle der von Google Clouderstellten standardmäßigen internen DNS-Namen.

Private Zonen und benutzerdefinierte Einträge mit Cloud DNS

Sie können eine private Cloud DNS-Zone verwenden, um benutzerdefinierte DNS-Einträge für Ihre Instanzen zu erstellen. Sie können PTR-Einträge konfigurieren, mit denen Sie die standardmäßige interne DNS-URL für Ihre Instanz 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 für RFC 1918-Adressen in privaten Zonen. Informationen zum Erstellen von PTR-Einträgen für Instanzen finden Sie unter PTR-Eintrag für eine Instanz erstellen.

Benutzerdefinierte Hostnamen

Beim Erstellen einer Instanz 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 Instanz mit benutzerdefiniertem Hostnamen erstellen.

Internes DNS und DHCP

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. Instanzen mit zonalem DNS enthalten in der DHCP-Konfigurationsdatei sowohl zonale als auch globale Einträge.

Standardmäßig speichern die meisten Linux-Distributionen DHCP-Informationen in resolv.conf. Bei manueller Bearbeitung von resolv.conf wird jedes Mal das Standard-DHCP wiederhergestellt, wenn die DHCP-Freigabe auf Ihrer Instanz abläuft. 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.

Wie Sie die DHCP-Richtlinie oder Konfigurationsdatei ändern, hängt von der verwendeten Linux-Distribution ab. Red Hat Enterprise Linux und Debian verwenden beispielsweise die Konfigurationsdatei /etc/dhcp/dhcpd.conf. Unter CentOS verwenden Sie das Network Manager-Befehlszeilentool, nmcli.

Informationen zum Konfigurieren benutzerdefinierter DHCP- und DNS-Netzwerkeinstellungen finden Sie in der Dokumentation Ihres Betriebssystems. Für Red Hat Enterprise Linux for SAP mit HA und Update Services 8.6 verwenden Sie beispielsweise den folgenden Link: Datei „/etc/resolv.conf“ manuell konfigurieren

resolv.conf-Beispieldatei

Standardmäßig speichern die meisten Linux-Distributionen DHCP-Informationen in resolv.conf. Der systemd-resolved-Dienst stellt auch Resolver-Dienste für DNS bereit. Sie können diesen Dienst konfigurieren, indem Sie die Datei /etc/systemd/resolved.conf und andere *.conf-Dateien im Verzeichnis /etc/systemd/resolved.conf.d/ bearbeiten. Bei Linux-Distributionen, die DHCP-Informationen in resolved.conf speichern, können Sie zonale und globale DNS-Einträge in der Datei /etc/systemd/resolved.conf aufrufen.

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-Features nicht mehr funktionieren, beispielsweise der Zugriff auf Instanzen mithilfe ihrer Instanznamen.

• Bei manueller Bearbeitung von resolv.conf wird das Standard-DHCP nach Ablauf der 24-Stunden-DHCP-Freigabe auf Ihrer Instanz 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.

# 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

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

# 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

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

dhclient.conf-Beispieldatei

Einige Betriebssysteme wie Debian 9 verwenden die Datei dhclient.conf anstelle der Datei resolv.conf.

Beispieldatei /etc/dhcp/dhclient.conf:

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

In diesem Beispiel ist mydomain.com die neue Suchdomain und 172.16.1.1 die IP-Adresse Ihres DNS-Servers.

Nächste Schritte

• 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.
• Migrieren Sie Ihre Organisation und Projekte so, dass zonales DNS anstelle von globalem DNS verwendet wird.