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 legt die eingehende DNS-Weiterleitung, die ausgehende DNS-Weiterleitung oder beides fest. Eine DNS-Serverrichtlinie für eingehenden Traffic erlaubt 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, damit reine IPv6-VM-Instanzen mit reinen IPv4-Zielen kommunizieren können.

Reine IPv6-VPC-Subnetze unterstützen keine eingehenden DNS-Serverrichtlinien. Sie können jedoch ausgehende DNS-Serverrichtlinien für Ihre reinen IPv6-VM-Instanzen konfigurieren.

Serverrichtlinien für eingehenden Traffic

Jedes VPC-Netzwerk stellt Cloud DNS-Namensauflösungsdienste für VM-Instanzen bereit, die eine mit dem VPC-Netzwerk verbundene Netzwerkschnittstelle (vNIC) haben. 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, die über Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliances mit dem VPC-Netzwerk verbunden sind, verfügbar machen möchten, können Sie eine Serverrichtlinie für eingehenden Traffic verwenden.

Wenn Sie eine Serverrichtlinie für eingehenden Traffic erstellen, erzeugt Cloud DNS Einstiegspunkte für Serverrichtlinien für eingehenden Traffic in dem VPC-Netzwerk, auf das die Serverrichtlinie angewendet wird. Einstiegspunkte für Serverrichtlinien für eingehenden Traffic sind interne IPv4-Adressen, die aus dem primären IPv4-Adressbereich jedes Subnetzes im entsprechenden VPC-Netzwerk stammen. Ausgenommen sind Subnetze mit bestimmten --purpose-Daten, z. B. Nur-Proxy-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 DNS-Serverrichtlinie für eingehenden Traffic 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, 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 Serverrichtlinie für eingehenden Traffic im selben VPC-Netzwerk wie die Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliances, die eine Verbindung mit dem lokalen Netzwerk herstellen.

    • Es ist möglich, dass ein lokales Netzwerk Abfragen an die Einstiegspunkte für die Serverrichtlinie für eingehenden Traffic 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 mit dem 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 in dem 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 die Serverrichtlinie für eingehenden Traffic gesendet werden.

      3. Konfigurieren Sie Cloud DNS-Ressourcen, die für das VPC-Netzwerk autorisiert sind, das eine Verbindung mit dem 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. Cloud DNS-Peering-Zonen sind für die Netzwerkverbindung nicht auf VPC-Netzwerk-Peering angewiesen.

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

  • Die zugeordnete 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, der bzw. 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 die Serverrichtlinie 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 die Serverrichtlinie für eingehenden Traffic in der Region senden, in der sich auch der Cloud VPN-Tunnel, der Cloud Interconnect-VLAN-Anhang oder die Router-Appliance befindet.
    • Die zugeordnete 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.

Route Advertisement für Einstiegspunkte für die 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 für die Serverrichtlinie für eingehenden Traffic bewirbt, wenn Sie den benutzerdefinierten Advertisement-Modus von Cloud Router auf eine der folgenden Arten verwenden:

  • Sie bewerben zusätzlich zu Ihren benutzerdefinierten Präfixen auch Subnetz-IP-Adressbereiche.
  • Sie fügen IP-Adressen für Einstiegspunkte für die Richtlinie für eingehenden Traffic in Ihre benutzerdefinierten Präfix-Bewerbungen ein.

Serverrichtlinien für ausgehenden Traffic

Sie können die Reihenfolge der Cloud DNS-Namensauflösung eines VPC-Netzwerks ändern, indem Sie eine Serverrichtlinie für ausgehenden Traffic erstellen, die eine Liste alternativer Nameserver enthält. 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 stimmen mit einer clusterbezogenen Antwortrichtlinie oder einer clusterbezogenen privaten Zone von Google Kubernetes Engine überein.

Wenn in einer Serverrichtlinie für ausgehenden Traffic zwei oder mehr alternative Nameserver vorhanden sind, ordnet Cloud DNS jedem alternativen Nameserver einen Rang zu und fragt sie ab, wie im ersten Schritt der Reihenfolge der VPC-Namensauflösung beschrieben. 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 DNS-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 unterstützt Privates Routing unterstützt Quelladressbereich für Abfragen

Nameserver des Typs 1

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

 Nur IP-Adressen im RFC 1918-Bereich – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. Jede interne IP-Adresse, z. B. eine private Adresse im RFC 1918-Bereich, eine private IP-Adresse außerhalb des RFC 1918-Bereichs oder eine privat wiederverwendete externe IP-Adresse, mit Ausnahme von verbotenen alternativen Nameserver-IP-Adressen. Der Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. 35.199.192.0/19

Nameserver des Typs 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 IP-Adressen im RFC 1918-Bereich – Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. Jede interne IP-Adresse, z. B. eine private Adresse im RFC 1918-Bereich, eine private IP-Adresse außerhalb des RFC 1918-Bereichs oder eine privat wiederverwendete externe IP-Adresse, mit Ausnahme von verbotenen alternativen Nameserver-IP-Adressen. Der Traffic wird immer über ein autorisiertes VPC-Netzwerk weitergeleitet. 35.199.192.0/19

Nameserver des Typs 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, im Internet routingfähige IP-Adressen – 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:

  • Standardrouting: 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 IP-Adresse im RFC 1918-Bereich 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).
    • Wenn der alternative Nameserver keine IP-Adresse im RFC 1918-Bereich 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 als 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 an alternative Nameserver variieren je nach Typ des alternativen Nameservers. Informationen zum Ermitteln des Typs eines alternativen Nameservers finden Sie unter Alternative Nameserver-Typen, Routingmethoden und Adressen. 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. 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 Merkmalen erstellen:

  • Ziele: müssen die VMs des alternativen Nameservers enthalten
  • Quelle(n): 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 Abfrage 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 Abfrage weiterleiten könnte.

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

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 Routenarten innerhalb des VPC-Netzwerks, auf das die Serverrichtlinie für ausgehenden Traffic 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 gültige Firewallkonfiguration muss die Protokolle TCP und UDP 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 Abfrage 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 Abfrage weiterleiten könnte.

Ihr lokales Netzwerk muss Routen für das Ziel 35.199.192.0/19 haben, deren next 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 Abfrage sendet. Solange die next 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 next Hops weitergeleitet werden:

  • Next Hops im Internet
  • Next Hops in einem VPC-Netzwerk, das sich von dem VPC-Netzwerk unterscheidet, aus dem die Abfragen stammen
  • Next Hops im selben VPC-Netzwerk, aber in einer anderen Region als der, aus 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 auch 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-Netzwerks, auf das sich die Serverrichtlinie für ausgehenden Traffic bezieht.

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

Nächste Schritte