DNS-Routingrichtlinien und ‑Systemdiagnosen

Sie können DNS-Routingrichtlinien für Ressourceneinträge in privatenoder öffentlichenZonen konfigurieren, um den Traffic anhand bestimmter Kriterien zu steuern. Erstellen Sie Ressourceneinträge mit bestimmten Werten für die Routingrichtlinie, um diese Richtlinien einzurichten. Mit diesen Werten wird festgelegt, wie Cloud DNS Abfragetraffic weiterleitet.

Cloud DNS unterstützt die folgenden Routingrichtlinien:

  • Gewichtete Round-Robin-Routingrichtlinie (WRR): Mit einer WRR-Routingrichtlinie können Sie jedem Ressourceneintragssatz für einen DNS-Namen unterschiedliche Gewichtungen zuweisen. Mit einer WRR-Routingrichtlinie wird dafür gesorgt, dass der Traffic gemäß den konfigurierten Gewichtungen verteilt wird. Die Kombination von WRR- und Standortbestimmungs-Routingrichtlinien wird nicht unterstützt.

  • Routingrichtlinie für die Standortbestimmung: Verwenden Sie die Routingrichtlinie für die Standortbestimmung, um Quellstandorte anzugeben und entsprechende Antworten für diese Geografien bereitzustellen. Die Standortbestimmungs-Routingrichtlinie wendet die nächstgelegene Übereinstimmung für den Quellstandort an, wenn keine Richtlinienelemente genau mit der Besucherquelle übereinstimmen.

DNS-Routingrichtlinien können für die folgenden privaten Zonen nicht konfiguriert werden:

  • Weiterleitungszonen
  • DNS-Peering-Zonen
  • Verwaltete Zonen für den umgekehrten Lookup
  • Service Directory-Zonen

WRR-Routingrichtlinien

Mit einer WRR-Routingrichtlinie können Sie unterschiedliche Gewichtungen pro DNS-Ziel angeben. Cloud DNS sorgt dafür, dass Ihr Traffic gemäß den Gewichtungen verteilt wird. Sie können diese Richtlinie verwenden, um manuelle active-active- oder active-passive-Konfigurationen zu unterstützen. Sie können den Traffic auch auf Produktionsversionen und experimentelle Versionen Ihres Dienstes aufteilen.

Cloud DNS unterstützt Systemdiagnosen und Failover innerhalb von Routing-Richtlinien für interne Load Balancer und externe Endpunkte. Cloud DNS ermöglicht ein automatisches Failover, wenn die Endpunkte die Systemdiagnosen nicht bestehen. Bei einem Failover passt Cloud DNS die Trafficaufteilung automatisch auf die verbleibenden fehlerfreien Endpunkte an. Weitere Informationen finden Sie unter Systemdiagnosen.

Routingrichtlinien für die Standortbestimmung

Mit einer Routingrichtlinie für die Standortbestimmung können Sie Traffic, der von Quellregionen (Google Cloud-Regionen) stammt, bestimmten DNS-Zielen zuordnen. Mit dieser Richtlinie können Sie eingehende Anfragen basierend auf dem Ursprung des Traffics an verschiedene Dienstinstanzen verteilen. Sie können diese Funktion mit Traffic von außerhalb von Google Cloud oder mit Traffic aus Google Cloud, der an interne Passthrough Network Load Balancer gebunden ist, verwenden. Cloud DNS verwendet die Region, in der Abfragen in Google Cloud gelangen, als Quellregion.

Eine Routingrichtlinie für die Standortbestimmung ordnet die Quelle für öffentliches und privates DNS so zu:

  • Beim öffentlichen DNS wird die Quell-IP-Adresse oder das -EDNS-Clientsubnetz (Erweiterungsmechanismus für DNS) der Abfrage verwendet.
  • Beim privaten DNS wird das EDNS-Clientsubnetz nicht verwendet. Stattdessen ist der Standort der Abfrage der Standort des Systems, das die Pakete für die Abfrage sendet:
    • Bei Abfragen von einer Compute Engine-VM-Instanz mit einer Netzwerkschnittstelle in einem VPC-Netzwerk ist der Standort der Abfrage die Region, in der sich die VM-Instanz befindet.
    • Bei Abfragen, die von einem Einstiegspunkt für Serverrichtlinien für eingehenden Traffic empfangen werden, ist der Standort der Abfrage die Region des Cloud VPN-Tunnels, des Cloud Interconnect-VLAN-Anhang oder der Router-Appliance, die die Pakete für die Abfrage empfangen hat. Die Region der IP-Adresse des Einstiegspunkts ist nicht relevant. Weitere Informationen finden Sie unter Netzwerk und Region für eingehende Abfragen.

Cloud DNS unterstützt Systemdiagnosen und Failover in Routing-Richtlinien für interne Load Balancer und externe Endpunkte. Cloud DNS ermöglicht ein automatisches Failover, wenn die Endpunkte die Systemdiagnosen nicht bestehen. Wenn Sie Standortbestimmung-Routingrichtlinien verwenden, wird der Traffic an den Standort weitergeleitet, der dem Quelltraffic am nächsten ist.

Routingrichtlinie für die Standortbestimmung mit Geofence

Mit einem Geofence wird sichergestellt, dass Traffic an eine bestimmte Region weitergeleitet wird, auch wenn alle Endpunkte in dieser Region die Systemdiagnosen nicht bestehen.

Wenn die Geofencing-Funktion deaktiviert ist und für eine bestimmte Region ein Systemdiagnosefehler auftritt, wird der Traffic automatisch auf die nächstgelegene Region umgeleitet. Wenn Geofencing jedoch aktiviert ist, kommt es nicht zu diesem automatischen Failover. Als autoritativer Server muss Cloud DNS einen Wert zurückgeben. In diesem Szenario gibt Cloud DNS alle IP-Adressen unverändert zurück, wenn die Endpunkte die Systemdiagnosen nicht bestehen.

Failover-Routingrichtlinien

Mit der Failover-Routing-Richtlinie können Sie aktive Sicherungskonfigurationen einrichten, um eine hohe Verfügbarkeit für interne Ressourcen in Ihrem VPC-Netzwerk zu gewährleisten.

Im Normalbetrieb gibt Cloud DNS immer die IP-Adressen aus dem active-Set zurück. Wenn alle IP-Adressen im Satz active fehlerhaft sind, werden die IP-Adressen aus dem Satz backup von Cloud DNS bereitgestellt. Wenn Sie den Satz backup als Routingrichtlinie für die Standortbestimmung konfigurieren, wird er wie im Abschnitt Routingrichtlinien für die Standortbestimmung beschrieben verwendet. Wenn Sie die backup-Gruppe für einen internen Load Balancer konfigurieren, führt Cloud DNS Systemdiagnosen für alle virtuellen IP-Adressen (VIP) aus.

Mit Cloud DNS können Sie den Traffic schrittweise auf die VIP-Sicherungsadressen umleiten, um zu prüfen, ob sie funktionieren. Sie können den Prozentsatz des Traffics, der an die Sicherung gesendet wird, als Bruchteil von 0 bis 1 konfigurieren. Sie können einen Failover manuell auslösen, indem Sie 100% des Traffics an die VIP-Ersatzadressen senden. Der typische Wert ist 0,1. Systemdiagnosen können nur auf interne Load Balancer und externe Endpunkte angewendet werden.

Systemdiagnosen

Cloud DNS unterstützt Systemdiagnosen und Failover in Routingrichtlinien für die folgenden internen Load Balancer und externen Endpunkte:

Wenn Sie die Systemdiagnose mit einer verwalteten Zone verwenden möchten und DNS-Sicherheitserweiterungen (DNSSEC) aktiviert sind, kann in jedem Richtlinienelement(einem WRR oder einer Standortbestimmung)nur eine einzige IP-Adresse verwendet werden. Sie können in einer bestimmten Richtlinie keine IP-Adressen mit Systemdiagnose und IP-Adressen ohne Systemdiagnose kombinieren.

Informationen zu Best Practices bei der Konfiguration des Cloud DNS-Eintrags und der Systemdiagnosen finden Sie unter Best Practices.

Systemdiagnosen für interne Load Balancer

Systemdiagnosen für interne Load Balancer sind nur in privaten Zonen verfügbar.

Bei internen Application Load Balancern und internen Proxy-Network Load Balancern berücksichtigt Cloud DNS bei der Routingentscheidung den Status des Load Balancers selbst. Wenn ein Load Balancer eine Abfrage empfängt, verteilt er den Traffic nur an die fehlerfreien Backend-Dienste. Damit es immer fehlerfreie Back-Ends gibt, können Sie den Lebenszyklus der Back-Ends mithilfe von Diensten wie verwalteten Instanzgruppen (Managed Instance Groups, MIGs) verwalten. Cloud DNS muss nicht über den Status einzelner Back-Ends informiert sein. Diese Aufgabe übernimmt der Load Balancer.

Bei internen Passthrough-Network Load Balancern prüft Cloud DNS die Systemdiagnoseinformationen der einzelnen Backend-Instanzen des Load Balancers. Cloud DNS verwendet standardmäßig einen Grenzwert von 20 %. Wenn mindestens 20% der Backend-Instanzen fehlerfrei sind, gilt der Load Balancer-Endpunkt als fehlerfrei. DNS-Routingrichtlinien kennzeichnen den Endpunkt basierend auf diesem Schwellenwert als fehlerfrei oder fehlerhaft und leiten den Traffic entsprechend weiter.

Eine einzelne virtuelle IP-Adresse (VIP) eines internen Passthrough-Network Load Balancers kann mehrere Backendinstanzen haben. Wenn ein interner Passthrough-Network Load Balancer keine Backend-Instanzen hat, wird er von Cloud DNS weiterhin als fehlerfrei eingestuft. Damit die Systemdiagnose ordnungsgemäß funktioniert, müssen Sie in der Load Balancer-Konfiguration mindestens eine Backend-Instanz angeben.

Wenn der Endpunkt als fehlerhaft gekennzeichnet ist, können die folgenden Bedingungen auftreten:

  • Wenn für eine Richtlinie mehrere VIP-Adressen programmiert sind, werden nur fehlerfreie VIP-Adressen zurückgegeben.

  • Wenn alle VIP-Adressen, die für einen Richtlinien-Bucket programmiert wurden, fehlerhaft sind, ist diese Richtlinienzeile fehlgeschlagen. Das folgende Verhalten gilt:

    • Bei einer WRR-Richtlinie verteilt Cloud DNS den Traffic proportional auf die verbleibenden fehlerfreien Endpunkte, die in der Richtlinie definiert sind.
    • Bei einer Richtlinie für die Standortbestimmung, für die keine Begrenzung aktiviert ist, wird der Traffic an Endpunkte in der Region in der Nähe der in der Richtlinie definierten Google Cloud-Quellregion weitergeleitet.
    • Bei einer Standortbestimmungsrichtlinie, für die Geofencing aktiviert ist, verteilt Cloud DNS den Traffic an die VIP-Adresse, die der in der Richtlinie definierten Google Cloud-Quellregion am nächsten ist.
    • Bei einer Failover-Richtlinie leitet Cloud DNS den Traffic an die in der Richtlinie definierten Ersatzendpunkte weiter.
    • Wenn alle Richtlinien-Buckets nicht fehlerfrei sind, verhält sich Cloud DNS so, als wären alle Endpunkte fehlerfrei. Dieses Szenario kann dazu führen, dass Traffic an nicht reagierende Endpunkte weitergeleitet wird.

Weitere Informationen zu Systemdiagnosen für interne Load Balancer finden Sie unter Systemdiagnosen – Übersicht.

Systemdiagnosen für externe Endpunkte (Vorabversion)

Systemdiagnosen für externe Endpunkte sind nur in öffentlichen Zonen verfügbar. Auf die Endpunkte, die Sie prüfen möchten, muss über das öffentliche Internet zugegriffen werden können. Der angegebene Endpunkt kann eine beliebige externe IP-Adresse und ein beliebiger Port sein, einschließlich einer globalen externen VIP-Adresse eines Application Load Balancers, einer regionalen externen VIP-Adresse eines Application Load Balancers, einer globalen externen VIP-Adresse eines Proxy-Network Load Balancers, lokaler Endpunkte oder anderer Endpunkte, auf die über das öffentliche Internet zugegriffen werden kann.

Verwenden Sie Systemdiagnosen für externe Endpunkte in den folgenden Fällen:

  • Damit wird der Traffic an einen regionalen externen Application Load Balancer weitergeleitet, wenn das Backend eines globalen externen Application Load Balancers oder eines globalen externen Proxy-Network Load Balancers nicht mehr betriebsbereit ist.
  • Damit wird der Traffic an einen anderen regionalen externen Application Load Balancer weitergeleitet, wenn das Backend eines bestimmten regionalen externen Application Load Balancers nicht mehr betriebsbereit ist.
  • Überwachen Sie den Status von lokalen Endpunkten oder anderen Endpunkten, die über das öffentliche Internet erreichbar sind.

Wenn Sie eine DNS-Routingrichtlinie mit Systemdiagnosen für externe Endpunkte erstellen, sendet Cloud DNS Systemdiagnosen an Ihre Endpunkte. Diese Systemdiagnosen stammen aus drei von Ihnen angegebenen Google Cloud-Quellregionen. Die Systemdiagnose-Prober der einzelnen Regionen werden unabhängig voneinander ausgeführt und Cloud DNS aggregiert ihre Ergebnisse, um den Gesamtstatus des Endpunkts zu ermitteln. Innerhalb jeder Region prüfen drei Systemdiagnose-Proberinstanzen jeden Endpunkt. Wenn ein Test fehlschlägt, kann Cloud DNS den Zustand des Endpunkts anhand der verbleibenden Tests ermitteln. Das bedeutet, dass Sie für jeden Endpunkt insgesamt neun Prober haben und jede Prüfung mit der Häufigkeit erfolgt, die Sie im Prüfintervall der Systemdiagnose angeben. Anhand der Parameter der Routingrichtlinie und der Informationen zur Systemdiagnose wählt Cloud DNS einen Endpunkt aus und leitet den Traffic an den ausgewählten Endpunkt weiter.

Cloud DNS unterstützt die Protokolle TCP, HTTP und HTTPS mit den folgenden Einschränkungen:

  • Das TCP-Anfragefeld wird nicht unterstützt.
  • Das Feld proxyHeader für HTTP, HTTPS und TCP wird nicht unterstützt.

SSL-, HTTP/2- und gRPC-Protokolle werden nicht unterstützt.

Beim TCP-Protokoll versucht Cloud DNS, eine Verbindung zum Endpunkt herzustellen. Bei den HTTP- und HTTPS-Protokollen prüft Cloud DNS, ob der Endpunkt einen HTTP-Antwortcode 200 zurückgibt. Sie können auch eine inhaltsbasierte Systemdiagnose konfigurieren, bei der Cloud DNS prüft, ob die Antwort einen bestimmten String enthält.

Im Gegensatz zur Systemdiagnose für interne Load Balancer stammen Cloud DNS-Systemdiagnosen für externe Endpunkte nicht aus festen IP-Adressbereichen. Die Quell-IP-Adressbereiche der Prüfung können sich im Laufe der Zeit ändern.

Das Protokoll und der Port, die Sie beim Erstellen der Systemdiagnose angeben, legen fest, wie die Systemdiagnoseprüfungen durchgeführt werden. Wenn Sie keinen Port angeben, verwendet Cloud DNS Port 80. Damit die Systemdiagnosen ordnungsgemäß funktionieren, müssen Sie Ihre Firewallregeln so konfigurieren, dass Systemdiagnosetests von jeder Quell-IP-Adresse und über den in der Systemdiagnose konfigurierten Port zugelassen werden.

Wenn Sie Ihre Firewall nicht so konfiguriert haben, dass Systemdiagnosetests zulässig sind, schlagen die Tests fehl. Cloud DNS betrachtet die blockierten Endpunkte dann als nicht betriebsbereit. Wenn alle Endpunkte als nicht betriebsbereit zurückgegeben werden, stellt Cloud DNS sie trotzdem bereit, auch wenn sie nicht betriebsbereit sind.

Intervall der Systemdiagnose

Cloud DNS sendet regelmäßig Systemdiagnosen gemäß dem Systemdiagnoseintervall. Wenn das Intervall für die Systemdiagnose beispielsweise 30 Sekunden beträgt, sendet Cloud DNS alle 30 Sekunden eine Systemdiagnose.

Für die Systemdiagnose externer Cloud DNS-Endpunkte muss das Intervall zwischen 30 und 300 Sekunden liegen.

Routingrichtlinien und Systemdiagnosen für gewichteten Round Robin

Cloud DNS unterstützt Gewichte von 0 bis 1.000. Wenn Systemdiagnosen enthalten sind, geschieht Folgendes:

  • Wenn Sie mehrere Ziele mit dem Gewicht „0“ konfigurieren, wird der Traffic gleichmäßig auf die Ziele verteilt.
  • Wenn Sie ein neues Ziel mit einer Gewichtung ungleich Null konfigurieren, wird es zum primären Ziel und der gesamte Traffic wird an dieses Ziel weitergeleitet.
  • Wenn Sie weitere Ziele mit nicht nullwertigen Gewichten hinzufügen, berechnet Cloud DNS bei jeder Anfrage dynamisch die Aufteilung des Traffics auf die Ziele und verteilt den Traffic entsprechend. Wenn Sie beispielsweise drei Ziele mit den Gewichten 0, 25 und 75 konfiguriert haben, erhält das Ziel mit dem Wert 0 keinen Traffic, das Ziel mit dem Wert 25 ein Viertel des Traffics und das verbleibende Ziel drei Viertel des eingehenden Traffics.
  • Wenn Systemdiagnosen mit Zielen mit einer Gewichtung ungleich Null verknüpft sind, aber nicht mit Zielen mit einer Gewichtung von null, werden die Ziele mit einer Gewichtung von null immer als fehlerfrei betrachtet. Wenn alle Einträge mit einem Wert unzuverlässig sind, gibt Cloud DNS die Einträge mit dem Wert 0 zurück.
  • Wenn Systemdiagnosen sowohl mit Einträgen mit einem Wert ungleich 0 als auch mit Einträgen mit dem Wert 0 verknüpft sind und alle Einträge die Systemdiagnosen nicht bestehen, gibt Cloud DNS alle Ziele mit einem Wert ungleich 0 zurück und ignoriert die Ziele mit dem Wert 0.
  • Wenn Cloud DNS einen Gewichts-Bucket auswählt, der an den Anfragenden zurückgegeben werden soll (ein einzelnes Richtlinienelement), wird nur die IP-Adresse in diesem Gewichts-Bucket zurückgegeben. Wenn Sie nur eine IP-Adresse im Gewichts-Bucket angeben, ist nur diese IP-Adresse in der Antwort enthalten. Wenn sich mehr als eine IP-Adresse im Gewichts-Bucket befindet, gibt Cloud DNS alle IP-Adressen in einer zufälligen Reihenfolge zurück.

Routingrichtlinien und Systemdiagnosen für die Standortbestimmung

Bei Geolokalisierungs-Routingrichtlinien mit aktivierten Systemdiagnosen passiert Folgendes:

  • Wenn für eine Richtlinie mehrere IP-Adressen konfiguriert sind und für alle IP-Adressen eine Systemdiagnose ausgeführt wird, werden nur die fehlerfreien IP-Adressen zurückgegeben.
  • Wenn IP-Adressen mit und ohne Systemdiagnose verwendet werden und alle IP-Adressen mit Systemdiagnose fehlschlagen, gibt Cloud DNS alle IP-Adressen zurück, für die keine Systemdiagnose konfiguriert ist. In diesem Szenario erfolgt kein automatischer Failover in die nächstgelegene Region.

Logging für Systemdiagnosen

Cloud DNS unterstützt das Logging von Systemdiagnosen und protokolliert den Status Ihrer IP-Adressen mit aktivierter Systemdiagnose, wenn Sie den DNS-Namen abfragen, der sich auf diese IP-Adressen bezieht.

Mit dem Logging für Systemdiagnosen haben Sie folgende Möglichkeiten:

  • Prüfen Sie, ob die Routingrichtlinien wie erwartet funktionieren. Beispiel:
    • Bei Richtlinien für die Standortbestimmung können Sie prüfen, ob die Richtlinien die richtige Region erkennen und den richtigen Datensatz mit Ressourceneinträgen zurückgeben.
    • Bei WRR-Richtlinien können Sie prüfen, ob die Richtlinien die IP-Adressen mit der richtigen Gewichtung zurückgeben.
  • Infrastrukturprobleme mit bestimmten Backends und IP-Adressen identifizieren, bei denen Fehler auftreten.
  • Beheben Sie Probleme, wenn bestimmte Backends nie oder nur zurückgegeben werden.

Weitere Informationen finden Sie unter Informationen zum Logging von Systemdiagnosen.

Unterstützte Datensatztypen für DNS-Routingrichtlinien

DNS-Routingrichtlinien unterstützen nicht alle Datensatztypen, die von Cloud DNS unterstützt werden.

Die folgenden Datensatztypen werden unterstützt:

Datensatztyp Beschreibung
A IPv4-Adressen für interne (private Zone) und externe (öffentliche Zone) Systemdiagnosen.
AAAA IPv6-Adressen für externe (öffentliche Zone) Systemdiagnosen.
CNAME Kanonische Namen Systemdiagnosen werden nicht unterstützt.
MX Mail-Exchange-Einträge Systemdiagnosen werden nicht unterstützt.
SRV Host/Port (RFC 2782) Systemdiagnosen werden nicht unterstützt.
TXT Textdaten Systemdiagnosen werden nicht unterstützt.

Nächste Schritte