DNS-Serverrichtlinien

Mit einer DNS-Serverrichtlinie können Sie konfigurieren, welche DNS-Server bei der Auflösung von Domainnamen für Ihre Google Cloud Ressourcen verwendet werden sollen. Mit DNS-Serverrichtlinien können Sie die DNS-Auflösung in einem bestimmten VPC-Netzwerk (Virtual Private Cloud) steuern. Eine DNS-Serverrichtlinie gibt die eingehende DNS-Weiterleitung, die ausgehende DNS-Weiterleitung oder beides an. Eine Richtlinie für eingehenden DNS-Traffic erlaubt die eingehende DNS-Weiterleitung, während eine Richtlinie für ausgehenden DNS-Traffic eine Möglichkeit zur Implementierung der ausgehenden DNS-Weiterleitung ist.

Sie können auch DNS64 (Vorabversion) konfigurieren, um es reinen IPv6-VM-Instanzen (Vorabversion) zu ermöglichen, mit reinen IPv4-Zielen zu kommunizieren.

Nur-IPv6-VPC-Subnetze (Vorabversion) unterstützen keine Richtlinien für eingehende DNS-Server. Sie können jedoch ausgehende DNS-Serverrichtlinien für Ihre reinen IPv6-VM-Instanzen konfigurieren (Vorabversion).

Serverrichtlinien für eingehenden Traffic

Jedes VPC-Netzwerk stellt Cloud DNS-Namensauflösungsdienste für VM-Instanzen bereit, die eine Netzwerkschnittstelle (vNIC) haben, die mit dem VPC-Netzwerk verbunden ist. Wenn eine VM ihren Metadatenserver 169.254.169.254 als Nameserver verwendet, Google Cloud sucht sie nach Cloud DNS-Ressourcen gemäß der Reihenfolge der VPC-Namensauflösung.

Wenn Sie die Namensauflösungsdienste eines VPC-Netzwerks für lokale Netzwerke verfügbar machen möchten, die über Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliances mit dem VPC-Netzwerk verbunden sind, können Sie eine eingehende Serverrichtlinie verwenden.

Wenn Sie eine Richtlinie für eingehenden Server erstellen, erstellt Cloud DNS Einstiegspunkte für die Richtlinie für eingehenden Traffic im VPC-Netzwerk, auf das die Richtlinie angewendet wird. Die Einstiegspunkte der Server-Richtlinie für eingehenden Traffic sind interne IPv4-Adressen aus dem primären IPv4-Adressbereich jedes Subnetzes im entsprechenden VPC-Netzwerk, mit Ausnahme von Subnetzen mit bestimmten --purpose-Daten, z. B. Subnetze mit reinen Proxys für bestimmte Load Balancer und Subnetze, die von Cloud NAT für Private NAT verwendet werden.

Wenn Sie beispielsweise ein VPC-Netzwerk haben, das zwei Subnetze in derselben Region und ein drittes Subnetz in einer anderen Region enthält, und Sie eine Serverrichtlinie für eingehenden Traffic für das VPC-Netzwerk konfigurieren, verwendet Cloud DNS insgesamt drei IPv4-Adressen als Einstiegspunkte für die Serverrichtlinie für eingehenden Traffic, eine pro Subnetz.

Informationen zum Erstellen einer Richtlinie für eingehende Server für eine VPC finden Sie unter Richtlinie für eingehende Server erstellen.

Netzwerk und Region für eingehende Abfragen

Zur Verarbeitung von DNS-Abfragen, die an Einstiegspunkte für Serverrichtlinien für eingehenden Traffic gesendet werden, verknüpft Cloud DNS die Abfrage mit einem VPC-Netzwerk und einer Region:

  • Das zugehörige VPC-Netzwerk für eine DNS-Abfrage ist das VPC-Netzwerk, das den Cloud VPN-Tunnel, den Cloud Interconnect-VLAN-Anhang oder die Netzwerkschnittstelle der Router-Appliance enthält, die die Pakete für die DNS-Abfrage empfängt.

    • Google empfiehlt, eine Serverrichtlinie für eingehenden Traffic im VPC-Netzwerk zu erstellen, das mit Ihrem lokalen Netzwerk verbunden ist. So befinden sich die Einstiegspunkte für die eingehenden Serverrichtlinien im selben VPC-Netzwerk wie die Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliances, die mit dem lokalen Netzwerk verbunden sind.

    • Ein lokales Netzwerk kann Abfragen an Eingangspunkte für eingehende Serverrichtlinien in einem anderen VPC-Netzwerk senden. Das ist beispielsweise der Fall, wenn das VPC-Netzwerk mit den Cloud VPN-Tunneln, Cloud Interconnect-VLAN-Anhängen oder Router-Appliances, die eine Verbindung zum lokalen Netzwerk herstellen, auch über VPC-Netzwerk-Peering mit einem anderen VPC-Netzwerk verbunden ist. Wir empfehlen jedoch, diese Konfiguration nicht zu verwenden, da das zugehörige VPC-Netzwerk für DNS-Abfragen nicht mit dem VPC-Netzwerk übereinstimmt, das die Einstiegspunkte der Richtlinie für eingehenden Traffic enthält. Das bedeutet, dass DNS-Abfragen nicht mithilfe von privaten Cloud DNS-Zonen und Antwortrichtlinien im VPC-Netzwerk mit der Richtlinie für eingehenden Traffic aufgelöst werden. Wir empfehlen stattdessen die folgenden Konfigurationsschritte:

      1. Erstellen Sie eine Serverrichtlinie für eingehenden Traffic im VPC-Netzwerk, die eine Verbindung zum lokalen Netzwerk über Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliances herstellt.
      2. Konfigurieren Sie lokale Systeme so, dass sie DNS-Anfragen an die im vorherigen Schritt konfigurierten Einstiegspunkte der Serverrichtlinie für eingehenden Traffic senden.

      3. Konfigurieren Sie Cloud DNS-Ressourcen, die für das VPC-Netzwerk autorisiert sind, das mit dem lokalen Netzwerk verbunden ist. Verwende eine oder mehrere der folgenden Methoden:

        • Fügen Sie das VPC-Netzwerk, das mit dem lokalen Netzwerk verbunden ist, der Liste der autorisierten Netzwerke für die privaten Cloud DNS-Zonen hinzu, die für das andere VPC-Netzwerk autorisiert sind: Wenn sich eine private Cloud DNS-Zone und das VPC-Netzwerk, das mit dem lokalen Netzwerk verbunden ist, in verschiedenen Projekten derselben Organisation befinden, verwenden Sie beim Autorisieren des Netzwerks die vollständige Netzwerk-URL. Weitere Informationen finden Sie unter Projektübergreifende Bindung einrichten.
        • Cloud DNS-Peering-Zonen, die für das VPC-Netzwerk autorisiert sind, das mit dem lokalen Netzwerk verbunden ist: Legen Sie das Zielnetzwerk der Peering-Zone auf das andere VPC-Netzwerk fest. Es spielt keine Rolle, ob das VPC-Netzwerk, das mit dem lokalen Netzwerk verbunden ist, über VPC-Netzwerk-Peering mit dem Ziel-VPC-Netzwerk der Peering-Zone verbunden ist, da Cloud DNS-Peering-Zonen für die Netzwerkverbindung nicht auf VPC-Netzwerk-Peering angewiesen sind.

  • Die zugehörige Region für eine DNS-Abfrage ist immer die Region, die den Cloud VPN-Tunnel, den Cloud Interconnect-VLAN-Anhang oder die Netzwerkschnittstelle der Router-Appliance enthält, die die Pakete für die DNS-Abfrage empfängt. Nicht die Region des Subnetzes, die den Einstiegspunkt für Serverrichtlinien für eingehenden Traffic enthält.

    • Wenn die Pakete für eine DNS-Abfrage beispielsweise über einen Cloud VPN-Tunnel in der Region us-east1 in ein VPC-Netzwerk gelangen und an einen Einstiegspunkt für Serverrichtlinien für eingehenden Traffic in der Region us-west1 gesendet werden, ist us-east1 die zugehörige Region für die DNS-Abfrage.
    • Als Best Practice sollten Sie DNS-Abfragen an die IPv4-Adresse eines Einstiegspunkts für Serverrichtlinien für eingehenden Traffic in derselben Region wie der Cloud VPN-Tunnel, der Cloud Interconnect-VLAN-Anhang oder die Router-Appliance senden.
    • Die zugewiesene Region für eine DNS-Abfrage ist wichtig, wenn Sie Routingrichtlinien für die Standortbestimmung verwenden. Weitere Informationen finden Sie unter DNS-Routingrichtlinien und Systemdiagnosen verwalten.

Routen-Anzeigen für Einstiegspunkte für Richtlinien für eingehende Server

Da die IP-Adressen des Einstiegspunkts der Richtlinie für eingehenden Traffic aus den primären IPv4-Adressbereichen von Subnetzen stammen, geben Cloud Router diese IP-Adressen an, wenn die BGP-Sitzung (Border Gateway Protocol) für einen Cloud VPN-Tunnel, einen Cloud Interconnect-VLAN-Anhang oder eine Router-Appliance so konfiguriert ist, dass der Standard-Anzeigenmodus des Cloud Routers verwendet wird. Sie können auch eine BGP-Sitzung so konfigurieren, dass sie IP-Adressen von Eintragspunkten für die Richtlinie für den eingehenden Server anbietet, wenn Sie den benutzerdefinierten Advertisement-Modus von Cloud Router auf eine der folgenden Arten verwenden:

  • Sie bewerben Subnetz-IP-Adressbereiche zusätzlich zu Ihren benutzerdefinierten Präfixen.
  • Sie fügen Ihrem benutzerdefinierten Präfix-Anzeigen-Eintrag die IP-Adressen der Einstiegspunkte für Richtlinien für eingehende Server hinzu.

Serverrichtlinien für ausgehenden Traffic

Sie können die Reihenfolge der Cloud DNS-Namensauflösung eines VPC-Netzwerks ändern. Dazu erstellen Sie eine Serverrichtlinie für ausgehenden Traffic, die eine Liste von alternativen Nameservern angibt. Wenn eine VM ihren Metadatenserver 169.254.169.254 als Nameserver verwendet und Sie alternative Nameserver für ein VPC-Netzwerk angegeben haben, sendet Cloud DNS alle Abfragen an die alternativen Nameserver, es sei denn, die Abfragen werden durch eine Antwortrichtlinie auf Clusterebene der Google Kubernetes Engine oder eine private Zone auf Clusterebene der GKE abgeglichen.

Wenn in einer ausgehenden Serverrichtlinie zwei oder mehr alternative Nameserver vorhanden sind, ordnet Cloud DNS die alternativen Nameserver zu und fragt sie wie im ersten Schritt der Reihenfolge der VPC-Namensauflösung beschrieben ab. Wichtig: Lesen Sie sich die Reihenfolge der Auflösung von VPC-Netzwerken sorgfältig durch. Die Verwendung alternativer Nameserver deaktiviert die Auflösung vieler Cloud DNS-Funktionen und kann sich je nach Konfiguration der alternativen Nameserver auch auf die Auflösung öffentlicher DNS-Abfragen auswirken. Weitere Informationen zu anderen Strategien für die ausgehende DNS-Weiterleitung finden Sie in der Cloud DNS-Übersicht unter DNS-Weiterleitungsmethoden. Informationen zum Erstellen von Serverrichtlinien für ausgehenden Traffic finden Sie unter Serverrichtlinie für ausgehenden Traffic erstellen.

Typen, Routingmethoden und Adressen alternativer Nameserver

Cloud DNS unterstützt drei Typen von alternativen Nameservern und bietet standardmäßige oder private Routingmethoden für die Verbindung.

Alternativer Nameserver-Typ Standardrouting wird unterstützt Privates Routing unterstützt Quelladressbereich abfragen

Nameserver 1

Eine interne IP-Adresse einer Google Cloud -VM in demselben VPC-Netzwerk, in dem die Serverrichtlinie für ausgehenden Traffic definiert ist.

 Nur RFC 1918-IP-Adressen – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. Jede interne IP-Adresse, z. B. eine private RFC 1918-Adresse, eine private IP-Adresse außerhalb RFC 1918 oder eine privat wiederverwendete externe IP-Adresse, mit Ausnahme einer unzulässigen IP-Adresse eines alternativen Nameservers – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. 35.199.192.0/19

Nameserver 2

Eine IP-Adresse eines lokalen Systems, das mit dem VPC-Netzwerk mit der Serverrichtlinie für ausgehenden Traffic über Cloud VPN oder Cloud Interconnect verbunden ist

 Nur RFC 1918-IP-Adressen – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. Jede interne IP-Adresse, z. B. eine private RFC 1918-Adresse, eine private IP-Adresse außerhalb RFC 1918 oder eine privat wiederverwendete externe IP-Adresse, mit Ausnahme einer unzulässigen IP-Adresse eines alternativen Nameservers – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. 35.199.192.0/19

Nameserver 3

Eine externe IP-Adresse eines DNS-Nameservers, auf die über das Internet zugegriffen werden kann oder die externe IP-Adresse einer Google Cloud -Ressource, z. B. die externe IP-Adresse einer VM in einem anderen VPC-Netzwerk.

 Nur externe, routingfähige IP-Adressen: Der Traffic wird immer an das Internet oder an die externe IP-Adresse einer Google Cloud Ressource weitergeleitet. Privates Routing wird nicht unterstützt Google Public DNS-Quellbereiche

Cloud DNS bietet zwei Routingmethoden für die Abfrage alternativer Nameserver:

  • Standard-Routing Cloud DNS bestimmt den Typ des alternativen Nameservers anhand seiner IP-Adresse und verwendet dann entweder privates oder öffentliches Routing:

    • Wenn der alternative Nameserver eine RFC-1918-IP-Adresse ist, klassifiziert Cloud DNS den Nameserver entweder als Nameserver vom Typ 1 oder Typ 2 und leitet Abfragen über ein autorisiertes VPC-Netzwerk (privates Routing) weiter.
    • Wenn der alternative Nameserver keine RFC-1918-IP-Adresse ist, klassifiziert Cloud DNS den Nameserver als Typ 3 und erwartet, dass der alternative Nameserver über das Internet zugänglich ist. Cloud DNS leitet Abfragen über das Internet weiter (öffentliches Routing).

  • Privates Routing Cloud DNS behandelt den alternativen Nameserver entweder als Typ 1 oder Typ 2. Cloud DNS leitet Traffic immer über ein autorisiertes VPC-Netzwerk weiter, unabhängig von der IP-Adresse des alternativen Nameservers (RFC 1918 oder nicht).

Verbotene IP-Adressen für alternative Nameserver

Die folgenden IP-Adressen können nicht für alternative Cloud DNS-Nameserver verwendet werden:

  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.88.99.0/24
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/4
  • 240.0.0.0/4
  • ::1/128
  • ::/128
  • 2001:db8::/32
  • fe80::/10
  • fec0::/10
  • ff00::/8

Netzwerkanforderungen an alternative Nameserver

Die Netzwerkanforderungen für alternative Nameserver variieren je nach Typ des alternativen Nameservers. Informationen zum Typ eines alternativen Nameservers finden Sie unter Arten, Routingmethoden und Adressen alternativer Nameserver. Lesen Sie dann in einem der folgenden Abschnitte die Netzwerkanforderungen.

Netzwerkanforderungen für alternative Nameserver vom Typ 1

Cloud DNS sendet Pakete, deren Quelladressen aus dem IP-Adressbereich von 35.199.192.0/19 stammen, an die IP-Adresse des alternativen Nameservers vom Typ 1.Google Cloud leitet Pakete für Abfragen mithilfe lokaler Subnetz-Routen im VPC-Netzwerk weiter. Achten Sie darauf, dass Sie keine richtlinienbasierten Routen erstellt haben, deren Ziele IP-Adressen von alternativen Nameservern vom Typ 1 enthalten.

Wenn Sie eingehende Pakete auf VMs mit alternativen Nameservern zulassen möchten, müssen Sie VPC-Firewallregeln zum Zulassen von eingehendem Traffic oder Regeln in Firewallrichtlinien mit den folgenden Eigenschaften erstellen:

  • Ziele: Muss die VMs des alternativen Nameservers enthalten
  • Quellen: 35.199.192.0/19
  • Protokolle: TCP und UDP
  • Port: 53

Für Cloud DNS muss jeder alternative Nameserver Antwortpakete an die Cloud DNS-IP-Adresse in 35.199.192.0/19 zurücksenden, von der die Abfrage stammt. Die Quellen für Antwortpakete müssen mit der IP-Adresse des alternativen Nameservers übereinstimmen, an den Cloud DNS die ursprüngliche Abfrage sendet. Cloud DNS ignoriert Antworten, die von einer unerwarteten IP‑Adresse stammen, z. B. von der IP‑Adresse eines anderen Nameservers, an den ein alternativer Nameserver eine Abfrage weiterleiten könnte.

Wenn ein alternativer Nameserver vom Typ 1 Antwortpakete an 35.199.192.0/19 sendet, verwendet er einen besonderen Routingpfad.

Netzwerkanforderungen für alternative Nameserver vom Typ 2

Cloud DNS sendet Pakete, deren Quellen aus dem IP-Adressbereich 35.199.192.0/19 stammen, an alternative Nameserver vom Typ 2. Cloud DNS verwendet die folgenden Arten von Routen innerhalb des VPC-Netzwerks, auf das die ausgehende Serverrichtlinie angewendet wird:

Wenn Sie eingehende Pakete auf alternativen Nameservern vom Typ 2 zulassen möchten, müssen Sie Firewallregeln für zulässigen eingehenden Traffic konfigurieren, die für die alternativen Nameserver und alle relevanten lokalen Netzwerkgeräte mit Firewallfunktionen gelten. Die effektive Firewallkonfiguration muss sowohl TCP- als auch UDP-Protokolle mit dem Zielport 53 und den Quellen 35.199.192.0/19 zulassen.

Für Cloud DNS muss jeder alternative Nameserver Antwortpakete an die Cloud DNS-IP-Adresse in 35.199.192.0/19 zurücksenden, von der die Abfrage stammt. Die Quellen für Antwortpakete müssen mit der IP-Adresse des alternativen Nameservers übereinstimmen, an den Cloud DNS die ursprüngliche Abfrage sendet. Cloud DNS ignoriert Antworten, die von einer unerwarteten IP‑Adresse stammen, z. B. von der IP‑Adresse eines anderen Nameservers, an den ein alternativer Nameserver eine Abfrage weiterleiten könnte.

Ihr lokales Netzwerk muss Routen für das Ziel 35.199.192.0/19 haben, deren nächste Hops Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Cloud-Router sind, die sich im selben VPC-Netzwerk und in derselben Region befinden, aus der Cloud DNS die Abfrage sendet. Solange die nächsten Hops diese Netzwerk- und Regionsanforderungen erfüllen,ist für Google Cloud kein symmetrischer Rückgabepfad erforderlich. Antworten von alternativen Typ-2-Nameservern können nicht über die folgenden nächsten Hops weitergeleitet werden:

  • Nächste Hops im Internet
  • Nächste Hops in einem anderen VPC-Netzwerk als dem VPC-Netzwerk, in dem die Abfragen stammen
  • Nächste Hops im selben VPC-Netzwerk, aber in einer anderen Region als der Region, aus der die Abfragen stammen

Verwenden Sie zum Konfigurieren der 35.199.192.0/19-Routen in Ihrem lokalen Netzwerk den Modus für benutzerdefiniertes Cloud Router-Advertisement und geben Sie 35.199.192.0/19 als benutzerdefiniertes Präfix in den BGP-Sitzungen der entsprechenden Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Cloud Router ein, die Ihr VPC-Netzwerk mit dem lokalen Netzwerk verbinden, das den alternativen Namenserver vom Typ 2 enthält. Alternativ können Sie entsprechende statische Routen in Ihrem lokalen Netzwerk konfigurieren.

Netzwerkanforderungen für alternative Nameserver vom Typ 3

Cloud DNS sendet Pakete, deren Quellen mit den Quellbereichen von Google Public DNS übereinstimmen, an alternative Nameserver vom Typ 3. Cloud DNS verwendet öffentliches Routing und nicht Routen innerhalb des VPC-Netzwerks, auf das die ausgehende Serverrichtlinie angewendet wird.

Damit eingehende Pakete auf alternativen Nameservern vom Typ 3 zugelassen werden, muss die effektive Firewallkonfiguration, die für den alternativen Nameserver gilt, Pakete aus den Quellbereichen von Google Public DNS zulassen.

Nächste Schritte