Sie können genau eine DNS-Serverrichtlinie für jedes VPC-Netzwerk (Virtual Private Cloud) konfigurieren. Die Richtlinie kann die eingehende DNS-Weiterleitung, die ausgehende DNS-Weiterleitung oder beides angeben. In diesem Abschnitt bezieht sich Richtlinie für Eingangsserver auf eine Richtlinie, die die eingehende DNS-Weiterleitung zulässt. Die Richtlinie für ausgehende Server bezieht sich auf eine mögliche Methode zur Implementierung der ausgehenden DNS-Weiterleitung. Eine Richtlinie kann sowohl eine Serverrichtlinie für eingehenden Traffic als auch eine Serverrichtlinie für ausgehenden Traffic sein, wenn sie die Features beider Richtlinien implementiert.
Weitere Informationen finden Sie unter Cloud DNS-Serverrichtlinien anwenden.
Serverrichtlinien für eingehenden Traffic
Jedes VPC-Netzwerk stellt Cloud DNS-Namensauflösungsdienste für VM-Instanzen bereit, deren Netzwerkschnittstelle (vNIC) an das VPC-Netzwerk angehängt ist. Wenn eine VM ihren Metadatenserver 169.254.169.254 als Nameserver verwendet, sucht Google Cloud gemäß der Reihenfolge der VPC-Netzwerknamen-Auflösung nach Cloud DNS-Ressourcen.
Um die Namensauflösungsdienste eines VPC-Netzwerks lokalen Netzwerken zur Verfügung zu stellen, die über Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliances mit dem VPC-Netzwerk verbunden sind, können Sie eine Serverrichtlinie für eingehenden Traffic verwenden.
Wenn Sie eine Serverrichtlinie für eingehenden Traffic erstellen, erstellt Cloud DNS in dem VPC-Netzwerk, auf das die Serverrichtlinie angewendet wird, Einstiegspunkte für Serverrichtlinien für eingehenden Traffic. Einstiegspunkte für eingehende Serverrichtlinien sind interne IPv4-Adressen, die aus dem primären IPv4-Adressbereich eines 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 haben, das zwei Subnetze in derselben Region und ein drittes Subnetz in einer anderen Region enthält, verwendet Cloud DNS beim Konfigurieren einer Serverrichtlinie für eingehenden Traffic für das VPC-Netzwerk insgesamt drei IPv4-Adressen als Einstiegspunkte für Serverrichtlinien (eines pro Subnetz).
Informationen zum Erstellen einer Serverrichtlinie für eingehenden Traffic für eine VPC finden Sie unter Serverrichtlinie für eingehenden Traffic erstellen.
Netzwerk und Region für eingehende Abfragen
Zur Verarbeitung von DNS-Abfragen, die an Einstiegspunkte von Serverrichtlinien für eingehende E-Mails 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 eine Verbindung zu Ihrem lokalen Netzwerk herstellt. Auf diese Weise befinden sich die Einstiegspunkte der Serverrichtlinien für eingehenden Traffic im selben VPC-Netzwerk wie die Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliances, die eine Verbindung zum lokalen Netzwerk herstellen.
Ein lokales Netzwerk kann Abfragen an Einstiegspunkte von Serverrichtlinien in einem anderen VPC-Netzwerk senden. Dies 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, über VPC-Netzwerk-Peering mit einem anderen VPC-Netzwerk verbunden ist. Wir raten jedoch davon ab, diese Konfiguration zu verwenden, da das zugehörige VPC-Netzwerk für DNS-Abfragen nicht mit dem VPC-Netzwerk übereinstimmt, das die Einstiegspunkte der eingehenden Serverrichtlinien enthält. Dies bedeutet, dass DNS-Abfragen nicht mithilfe von privaten Cloud DNS-Zonen und -Antwortrichtlinien im VPC-Netzwerk, das die eingehende Serverrichtlinie enthält, aufgelöst werden. Um Verwirrung zu vermeiden, empfehlen wir stattdessen die folgenden Konfigurationsschritte:
- Erstellen Sie eine Serverrichtlinie für eingehenden Traffic im VPC-Netzwerk, das über Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder Router-Appliances eine Verbindung zum lokalen Netzwerk herstellt.
- Konfigurieren Sie lokale Systeme so, dass DNS-Abfragen an die Einstiegspunkte der eingehenden Serverrichtlinien gesendet werden, die im vorherigen Schritt konfiguriert wurden.
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:
- Fügen Sie das VPC-Netzwerk, das eine Verbindung zum lokalen Netzwerk herstellt, 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 eine Verbindung zum lokalen Netzwerk herstellt, 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 eine Verbindung zum lokalen Netzwerk herstellt: Legen Sie das Zielnetzwerk der Peering-Zone auf das andere VPC-Netzwerk fest. Dabei spielt es keine Rolle, ob das VPC-Netzwerk, das eine Verbindung zum lokalen Netzwerk herstellt, ü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 für eine DNS-Abfrage zugeordnete Region 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, und nicht die Region des Subnetzes, das den Einstiegspunkt für die eingehende Serverrichtlinie enthält.
- Wenn die Pakete für eine DNS-Abfrage beispielsweise in ein VPC-Netzwerk über einen Cloud VPN-Tunnel in der Region
us-east1gelangen und an einen Einstiegspunkt für Serverrichtlinien in der Regionus-west1gesendet werden, ist die zugehörige Region für die DNS-Abfrageus-east1. - Senden Sie DNS-Abfragen als Best Practice an die IPv4-Adresse eines Einstiegspunkt der Serverrichtlinie für eingehenden Traffic in derselben Region wie der Cloud VPN-Tunnel, der Cloud Interconnect-VLAN-Anhang oder die Router-Appliance.
- Die für eine DNS-Abfrage zugeordnete Region ist wichtig, wenn Sie Richtlinien für das Routing zur Standortbestimmung verwenden. Weitere Informationen finden Sie unter DNS-Routingrichtlinien und -Systemdiagnosen verwalten.
- Wenn die Pakete für eine DNS-Abfrage beispielsweise in ein VPC-Netzwerk über einen Cloud VPN-Tunnel in der Region
Route Advertising mit Einstiegspunkt für Serverrichtlinie für eingehenden Traffic
Da IP-Adressen der Einstiegspunkte von Serverrichtlinien für eingehenden Traffic aus den primären IPv4-Adressbereichen von Subnetzen stammen, bieten 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 für die Verwendung des Standardwerbemodus von Cloud Router konfiguriert ist. Sie können eine BGP-Sitzung auch so konfigurieren, dass IP-Adressen der Einstiegspunkte von Serverrichtlinien für eingehenden Traffic angeboten werden. Dazu verwenden Sie den benutzerdefinierten Advertising-Modus von Cloud Router auf eine der folgenden Arten:
- Zusätzlich zu Ihren benutzerdefinierten Präfixen bieten Sie Subnetz-IP-Adressbereiche an.
- Sie nehmen IP-Adressen der Einstiegspunkte von Serverrichtlinien für eingehenden Traffic in Ihr benutzerdefiniertes Präfix-Advertising auf.
Serverrichtlinien für ausgehenden Traffic
Sie können die Reihenfolge der Cloud DNS-Namensauflösung eines VPC-Netzwerk ändern. Dazu erstellen Sie eine Serverrichtlinie für ausgehenden Traffic, die eine Liste mit 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 von einer clusterbezogenen Antwortrichtlinie der Google Kubernetes Engine oder einer privaten GKE-Clusterzone abgeglichen.
Informationen zum Erstellen von Richtlinien für ausgehende Server finden Sie unter Richtlinien für ausgehende Server erstellen.
Alternative Nameserver-Typen, Routingmethoden und Adressen
Cloud DNS unterstützt drei Arten 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 der Abfrage |
|---|---|---|---|
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 RFC 1918-Adresse, eine private IP-Adresse außerhalb von RFC 1918 oder eine privat wiederverwendete öffentliche IP-Adresse, mit Ausnahme einer verbotenen alternativen Nameserver-IP-Adresse. 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 von RFC 1918 oder eine privat wiederverwendete öffentliche IP-Adresse, mit Ausnahme einer verbotenen alternativen Nameserver-IP-Adresse. 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 zum 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 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).
Unzulässige alternative Nameserver-IP-Adressen
Sie können die folgenden IP-Adressen nicht für alternative Cloud DNS-Nameserver verwenden:
169.254.0.0/16192.0.0.0/24192.0.2.0/24192.88.99.0/24198.51.100.0/24203.0.113.0/24224.0.0.0/4240.0.0.0/4::1/128::/1282001:db8::/32fe80::/10fec0::/10ff00::/8
Netzwerkanforderungen an alternative Nameserver
Die Netzwerkanforderungen für alternative Nameserver variieren je nach Typ des alternativen Nameservers. Informationen zum Ermitteln des Typs für einen alternativen Nameserver finden Sie unter Alternative Nameservertypen, Routingmethoden und Adressen. Informationen zu den Netzwerkanforderungen finden Sie in den folgenden Abschnitten.
Netzwerkanforderungen für alternative Nameserver des Typs 1
Cloud DNS sendet Pakete, deren Quellen aus dem IP-Adressbereich 35.199.192.0/19 an die alternative Nameserver-IP-Adresse Typ 1 sind.
Google Cloud leitet Pakete für Abfragen über lokale Subnetzrouten im VPC-Netzwerk weiter. Achten Sie darauf, dass Sie keine richtlinienbasierten Routen erstellt haben, deren Ziele alternative Nameserver-IP-Adressen vom Typ 1 enthalten.
Wenn Sie eingehende Pakete auf alternativen Nameserver-VMs zulassen möchten, müssen Sie VPC-Firewallregeln oder Regeln in Firewallrichtlinien mit den folgenden Eigenschaften erstellen:
- Ziele: Muss die alternativen Nameserver-VMs enthalten
- Quellen:
35.199.192.0/19 - Protokolle:
TCPundUDP - 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. 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-Adressquelle stammen, z. B. von der IP-Adresse eines anderen Nameservers, an den ein alternativer Nameserver eine Abfrage weiterleiten könnte.
Wenn ein alternativer Typ 1-Nameserver Antwortpakete an 35.199.192.0/19 sendet, verwendet er einen speziellen Routingpfad.
Netzwerkanforderungen für alternative Nameserver des Typs 2
Cloud DNS sendet Pakete, deren Quellen aus dem IP-Adressbereich 35.199.192.0/19 an alternative Nameserver vom Typ 2 sind. Cloud DNS stützt sich auf die folgenden Arten von Routen innerhalb des VPC-Netzwerk, für das die Serverrichtlinie für ausgehenden Traffic gilt:
- Statische Routen mit Ausnahme statischer Routen, die nur für VMs nach Netzwerktag gelten
- Dynamische Routen
Wenn Sie eingehende Pakete auf alternativen Nameservern vom Typ 2 zulassen möchten, müssen Sie Firewallregeln zum Zulassen von eingehendem Traffic konfigurieren, die für die alternativen Nameserver und alle relevanten lokalen Netzwerkgeräte mit Firewallfunktionen gelten. Die geltende Firewallkonfiguration muss die Protokolle TCP und UDP mit den Zielports 53 und 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. 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-Adressquelle 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, dessen 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, von denen Cloud DNS die Abfrage sendet. Solange die nächsten Hops diese Netzwerk- und Regionsanforderungen erfüllen, benötigt Google Cloud keinen symmetrischen Rückgabepfad. Antworten von alternativen Nameservern Typ 2 können nicht mit einem der folgenden nächsten Hops weitergeleitet werden:
- Nächste Hops im Internet
- Nächste Hops in einem VPC-Netzwerk, das sich von dem VPC-Netzwerk unterscheidet, aus dem die Abfragen stammen
- Nächste Hops im selben VPC-Netzwerk, aber in einer Region, die sich von der Region unterscheidet, aus der die Abfragen stammen
Verwenden Sie zum Konfigurieren der 35.199.192.0/19-Routen in Ihrem lokalen Netzwerk den benutzerdefinierten Advertising-Modus von Cloud Router und fügen Sie 35.199.192.0/19 als benutzerdefiniertes Präfix in die 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 Nameserver Typ 2 enthält. Alternativ können Sie entsprechende statische Routen in Ihrem lokalen Netzwerk konfigurieren.
Netzwerkanforderungen für alternative Nameserver des Typs 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 verlässt sich nicht auf Routen innerhalb des VPC-Netzwerk, für das die Serverrichtlinie für ausgehenden Traffic gilt.
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.