DNS-Serverrichtlinien

Mit einer DNS-Serverrichtlinie können Sie konfigurieren, welche DNS-Server zum Auflösen 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 DNS-Serverrichtlinie für eingehenden Traffic ermöglicht die eingehende DNS-Weiterleitung, während eine DNS-Serverrichtlinie für ausgehenden Traffic eine Möglichkeit zur Implementierung der ausgehenden DNS-Weiterleitung ist.

Sie können auch DNS64 konfigurieren (Vorschau), damit reine IPv6-VM-Instanzen (Vorschau) mit reinen IPv4-Zielen kommunizieren können.

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

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,sucht Google Cloud gemäß der Reihenfolge der VPC-Netzwerk-Namensauflösung nach Cloud DNS-Ressourcen.

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 Serverrichtlinie für eingehenden Traffic erstellen, erstellt Cloud DNS Einstiegspunkte für Serverrichtlinien für eingehenden Traffic im VPC-Netzwerk, auf das die Serverrichtlinie angewendet wird. Einstiegspunkte für Richtlinien für eingehenden Server 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. Proxy-only-Subnetze für bestimmte Load Balancer und Subnetze, die von Cloud NAT für Private NAT verwendet werden.

Wenn Sie beispielsweise ein VPC-Netzwerk mit zwei Subnetzen in derselben Region und einem dritten Subnetz in einer anderen Region haben und 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 Anfragen

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

  • 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 in dem VPC-Netzwerk zu erstellen, das mit Ihrem lokalen Netzwerk verbunden ist. So befinden sich die Einstiegspunkte für die eingehende Serverrichtlinie im selben VPC-Netzwerk wie die Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliances, die eine Verbindung zum lokalen Netzwerk herstellen.

    • Es ist möglich, dass ein lokales Netzwerk Anfragen an die Einstiegspunkte für eingehende Serverrichtlinien in einem anderen VPC-Netzwerk sendet. Das ist beispielsweise der Fall, wenn das VPC-Netzwerk, das die Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliances enthält, die eine Verbindung zum lokalen Netzwerk herstellen, auch über VPC-Netzwerk-Peering mit einem anderen VPC-Netzwerk verbunden ist. Wir empfehlen jedoch nicht, diese Konfiguration zu verwenden, da das zugehörige VPC-Netzwerk für DNS-Abfragen nicht mit dem VPC-Netzwerk übereinstimmt, das die Einstiegspunkte für die Serverrichtlinie für eingehenden Traffic enthält. Das bedeutet, dass DNS-Abfragen nicht mit privaten Cloud DNS-Zonen und Antwortrichtlinien im VPC-Netzwerk aufgelöst werden, das die Serverrichtlinie für eingehenden Traffic enthält. Um Verwirrung zu vermeiden, empfehlen wir stattdessen die folgenden Konfigurationsschritte:

      1. Erstellen Sie eine Serverrichtlinie für eingehenden Traffic im VPC-Netzwerk, das über Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliances mit dem lokalen Netzwerk verbunden ist.
      2. Konfigurieren Sie lokale Systeme so, dass DNS-Anfragen an die im vorherigen Schritt konfigurierten Einstiegspunkte für Serverrichtlinien für eingehenden Traffic gesendet werden.

      3. Konfigurieren Sie Cloud DNS-Ressourcen, die für das VPC-Netzwerk autorisiert sind, das eine Verbindung zum lokalen Netzwerk herstellt. Wenden Sie eine oder mehrere der folgenden Methoden an:

        • VPC-Netzwerk, das mit dem lokalen Netzwerk verbunden ist, der Liste der autorisierten Netzwerke für die privaten Cloud DNS-Zonen hinzufügen, 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 die vollständige Netzwerk-URL, wenn Sie das Netzwerk autorisieren. 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 nicht auf VPC-Netzwerk-Peering für die Netzwerkverbindung angewiesen sind.

    • Wenn ein lokales Netzwerk Abfragen über VPC Network Peering an eine eingehende Serverrichtlinie sendet, muss das Netzwerk mit der eingehenden Serverrichtlinie eine VM, einen VLAN-Anhang oder einen Cloud VPN-Tunnel in derselben Region wie die eingehenden Abfragen enthalten.

  • 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, das den Einstiegspunkt für die Serverrichtlinie 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 die zugehörige Region für die DNS-Abfrage us-east1.
    • 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 zugehörige Region für eine DNS-Anfrage ist wichtig, wenn Sie Routingrichtlinien für die Standortbestimmung verwenden. Weitere Informationen finden Sie unter DNS-Routingrichtlinien und Systemdiagnosen verwalten.

Route Advertisement für Einstiegspunkt für Serverrichtlinie für eingehenden Traffic

Da die IP-Adressen der Einstiegspunkte für die Serverrichtlinie für eingehenden Traffic aus den primären IPv4-Adressbereichen von Subnetzen stammen, geben Cloud Router diese IP-Adressen bekannt, wenn die BGP-Sitzung (Border Gateway Protocol) für einen Cloud VPN-Tunnel, einen Cloud Interconnect-VLAN-Anhang oder eine Router-Appliance für die Verwendung des Standard-Advertisement-Modus des Cloud Routers konfiguriert ist. Sie können auch eine BGP-Sitzung so konfigurieren, dass sie IP-Adressen für den Einstiegspunkt der eingehenden Serverrichtlinie bewirbt, 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 IP-Adressen für Einstiegspunkte für Richtlinien für eingehende Server in Ihre benutzerdefinierten Präfixankündigungen ein.

Serverrichtlinien für ausgehenden Traffic

Sie können die Reihenfolge der Cloud DNS-Namensauflösung eines VPC-Netzwerk ändern, indem Sie eine Serverrichtlinie für ausgehenden Traffic erstellen, die eine Liste alternativer Nameserver 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 Anfragen an die alternativen Nameserver, es sei denn die Anfragen stimmen mit einer Antwortrichtlinie oder einer privaten Zone mit GKE-Clusterbereich überein.

Wenn in einer Serverrichtlinie für ausgehenden Traffic zwei oder mehr alternative Nameserver vorhanden sind, werden diese von Cloud DNS eingestuft und wie im ersten Schritt der Reihenfolge der VPC-Namensauflösung beschrieben abgefragt. Wichtig: Sehen Sie sich die Auflösungsreihenfolge für VPC-Netzwerke genau an. Durch die Verwendung alternativer Nameserver wird die Auflösung vieler Cloud DNS-Funktionen deaktiviert. Je nach Konfiguration der alternativen Nameserver kann dies auch die Auflösung öffentlicher DNS-Abfragen beeinträchtigen. Weitere Informationen zu anderen Strategien für die ausgehende DNS-Weiterleitung finden Sie unter DNS-Weiterleitungsmethoden in der Cloud DNS-Übersicht. Informationen zum Erstellen von Serverrichtlinien für ausgehenden Traffic finden Sie unter Serverrichtlinie für ausgehenden Traffic erstellen.

Alternative Nameserver-Typen, Routingmethoden und Adressen

Cloud DNS unterstützt die folgenden alternativen Nameserver und bietet Standard- oder private Routingmethoden für die Verbindung.

Alternativer Nameserver-Typ Standardrouting wird unterstützt Privates Routing unterstützt Quelladressbereich für Anfragen

Nameserver 1

Eine interne IP-Adresse einer Google Cloud -VM im selben 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 Adresse gemäß RFC 1918, eine private IP-Adresse außerhalb von RFC 1918 oder eine privat wiederverwendete externe IP-Adresse, mit Ausnahme einer verbotenen alternativen Nameserver-IP-Adresse. Der 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 Adresse gemäß RFC 1918, eine private IP-Adresse außerhalb von RFC 1918 oder eine privat wiederverwendete externe IP-Adresse, mit Ausnahme einer verbotenen alternativen Nameserver-IP-Adresse. Der 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 das Abfragen 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 Anfragen ü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 den 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 Ermitteln des Typs eines alternativen Nameservers finden Sie unter Typen, Routingmethoden und Adressen für alternative Nameserver. Informationen zu den Netzwerkanforderungen finden Sie in einem der folgenden Abschnitte.

Netzwerkanforderungen an alternative Nameserver vom Typ 1

Cloud DNS sendet Pakete, deren Quellen aus dem IP-Adressbereich 35.199.192.0/19 stammen, an die IP-Adresse des alternativen Nameservers vom Typ 1.Google Cloud leitet Pakete für Anfragen über lokale Subnetzrouten im VPC-Netzwerk weiter. Prüfen Sie, ob Sie richtlinienbasierte 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 Merkmalen erstellen:

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

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

Wenn ein alternativer Nameserver vom Typ 1 Antwortpakete an 35.199.192.0/19 sendet, wird ein spezieller Routingpfad verwendet.

Netzwerkanforderungen an 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 im VPC-Netzwerk, auf das die ausgehende Serverrichtlinie angewendet wird:

Damit eingehende Pakete auf alternativen Nameservern vom Typ 2 zugelassen werden, 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 das TCP- als auch das UDP-Protokoll mit dem Zielport 53 und den Quellen 35.199.192.0/19 zulassen.

Für Cloud DNS ist es erforderlich, dass jeder alternative Nameserver Antwortpakete an die Cloud DNS-IP-Adresse in 35.199.192.0/19 zurücksendet, von der die Anfrage stammt. Die Quellen für Antwortpakete müssen mit der IP-Adresse des alternativen Nameservers übereinstimmen, an den Cloud DNS die ursprüngliche Anfrage sendet. Cloud DNS ignoriert Antworten, wenn sie von einer unerwarteten IP-Adresse stammen, z. B. der IP-Adresse eines anderen Nameservers, an den ein alternativer Nameserver eine Anfrage 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 denen Cloud DNS die Anfrage 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 VPC-Netzwerk, das sich vom VPC-Netzwerk unterscheidet, in dem die Anfragen stammen
  • Nächste Hops im selben VPC-Netzwerk, aber in einer anderen Region als der, in der die Anfragen stammen

Um die 35.199.192.0/19-Routen in Ihrem lokalen Netzwerk zu konfigurieren, verwenden Sie den benutzerdefinierten Advertisement-Modus des Cloud Routers und fügen Sie 35.199.192.0/19 als benutzerdefiniertes Präfix in die BGP-Sitzungen der relevanten Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Cloud Router ein, die Ihr VPC-Netzwerk mit dem lokalen Netzwerk verbinden, das den alternativen Nameserver vom Typ 2 enthält. Alternativ können Sie entsprechende statische Routen in Ihrem lokalen Netzwerk konfigurieren.

Netzwerkanforderungen an alternative Nameserver vom Typ 3

Cloud DNS sendet Pakete, deren Quellen mit den Google Public DNS-Quellbereichen übereinstimmen, an alternative Nameserver vom Typ 3. Cloud DNS verwendet öffentliches Routing. Es stützt sich nicht auf Routen innerhalb des VPC-Netzwerk, auf das sich die ausgehende Serverrichtlinie bezieht.

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 Google Public DNS-Quellbereichen zulassen.

Nächste Schritte