Internes DNS

Wenn Sie Compute Engine-VM-Instanzen erstellen, erstellt das interne DNS automatisch einen DNS-Namen für die VM. Dieser DNS-Name erleichtert die interne VM-zu-VM-Kommunikation durch das Auflösen interner IP-Adressen. Virtual Private Cloud-Netzwerke in Google Cloud verwenden den internen DNS-Dienst, damit VMs 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 VMs verwalten:

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

Wenn Sie zum Beispiel eine VM löschen, entfernt Google Cloud automatisch die zugehörigen A- und PTR-Einträge für den internen DNS-Namen. Wenn Sie dann eine VM mit dem gleichen Namen erstellen, erstellt Google Cloud einen neuen Eintrag für den Ersatz.

Beschränkungen

Interne DNS-Namen haben folgende Spezifikationen:

  • Der interne DNS-Name einer VM 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 VM verwendet werden.

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

  • Interne DNS-Namen können nur von VMs aufgelöst werden, die sich im selben Netzwerk befinden. Diese VMs können sich im selben Projekt wie das Netzwerk oder in Dienstprojekten befinden, die dasselbe freigegebene VPC-Netzwerk verwenden. Zum Auflösen von DNS-Namen von VMs in Dienstprojekten müssen Sie die FQDNs der VMs verwenden. Es ist nicht möglich, internes DNS für den Kontakt mit VMs in einem anderen Netzwerk zu verwenden.

Zonale und globale interne DNS-Namen

Google Cloud verfügt über zwei Arten von internen DNS-Namen:

  • Zonales DNS: VM-Namen müssen innerhalb jeder Zone eindeutig sein, Sie können jedoch VM-Namen zonenübergreifend wiederverwenden. Beispielsweise können Sie mehrere VMs mit dem Namen instance-1 haben, solange sich die VMs in verschiedenen Zonen befinden.
  • Globales DNS: VM-Namen müssen innerhalb jedes Projekts eindeutig sein. Beim globalen DNS können Sie VM-Namen 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 VM-Name muss im gesamten Projekt eindeutig sein. Daher können Sie keine neuen VMs 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.

Interner DNS-Typ Voll qualifizierter Domainname (FQDN)
Zonales DNS VM_NAME.ZONE.c.PROJECT_ID.internal
Globales (projektweites) DNS VM_NAME.c.PROJECT_ID.internal

Ersetzen Sie Folgendes:

  • VM_NAME ist der Name der VM. Bei zonalem DNS muss dieser Wert innerhalb der Zone eindeutig sein, kann sich aber zonenübergreifend wiederholen. Beim globalen DNS muss der VM-Name im gesamten Projekt eindeutig sein.
  • ZONE: Zone, in der sich Ihre Instanz befindet.
  • PROJECT_ID: Projekt, zu dem die VM 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

VMs erhalten interne DNS-Auflösungsinformationen im Rahmen ihrer DHCP-Freigaben. Die Methode der DNS-Auflösung hängt von der Betriebssystemplattform ab:

  • Unter Linux werden die internen DNS-Namen standardmäßig vom DNS-Server der VM (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 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.

Interne DNS-Namen und freigegebene VPC

Sie können einen internen DNS-Namen verwenden, um auf die interne IP-Adresse einer VM zu verweisen. Dies ist auch dann möglich, wenn sich die 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.

Interne DNS-Namen anpassen

Einige Organisationen oder Anwendungen benötigen möglicherweise benutzerdefinierte interne DNS-Namen anstelle der von Google Cloud erstellten 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 VMs zu erstellen. Sie können PTR-Einträge konfigurieren, mit denen Sie die standardmäßige interne DNS-URL für Ihre 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 für RFC 1918-Adressen in privaten Zonen. Informationen zum Erstellen von PTR-Einträgen für VMs finden Sie unter PTR-Eintrag für eine VM-Instanz erstellen.

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.

Internes DNS und DHCP

Compute Engine-VMs sind so konfiguriert, dass DHCP-Freigaben alle 24 Stunden erneuert werden. Bei VMs, die für ein zonales DNS aktiviert sind, läuft die DHCP-Freigabe stündlich ab. VMs 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 VM 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. Verwenden Sie zum Beispiel für Red Hat Enterprise Linux für SAP mit HA und Update Services 8.6 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 th Eintrag von Ihrem Betriebssystem nicht angewendet. Dies kann dazu führen, dass die Compute Engine-Features nicht mehr funktionieren, beispielsweise der Zugriff auf VMs mithilfe ihrer Instanznamen.

  • Bei manueller Bearbeitung von resolv.conf wird das Standard-DHCP nach Ablauf der 24-Stunden-DHCP-Freigabe auf Ihrer VM wiederhergestellt. Bei VMs mit zonalem DNS läuft die DHCP-Freigabe 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.

Zonale DNS-Konfiguration

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

Globale DNS-Konfiguration

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

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