DNS-Richtlinien

Cloud DNS unterstützt verschiedene Typen von Richtlinien. Auf dieser Seite finden Sie Details zu den verschiedenen Richtlinientypen und dazu, wann Sie den einen oder den anderen verwenden können.

  • Serverrichtlinien wenden eine private DNS-Konfiguration auf ein VPC-Netzwerk (Virtual Private Cloud) (DNS-Weiterleitung, Logging) an.
  • Antwortrichtlinien überschreiben private DNS-Antworten anhand des Abfragenamens.
  • Routingrichtlinien leiten den Traffic anhand der Abfrage weiter (z. B. Round-Robin, Standortbestimmung).

Sie können je nach Anforderungen alle drei Richtlinien gleichzeitig verwenden.

Serverrichtlinien

Verwenden Sie Serverrichtlinien, um Hybridbereitstellungen für DNS-Auflösungen einzurichten. Sie können eine Serverrichtlinie für eingehenden Traffic je nach Richtung der DNS-Auflösungen einrichten. Wenn Ihre Arbeitslasten einen lokalen DNS-Resolver verwenden sollen, können Sie DNS-Weiterleitungszonen mithilfe einer Serverrichtlinie für ausgehenden Traffic einrichten. Wenn jedoch Ihre lokalen Arbeitslasten Namen in Google Cloud auflösen sollen, können Sie eine Serverrichtlinie für eingehenden Traffic einrichten.

Ausführliche Informationen zu Serverrichtlinien finden Sie unter Serverrichtlinien.

Informationen zum Konfigurieren und Anwenden von DNS-Serverrichtlinien finden Sie unter DNS-Serverrichtlinien anwenden.

Antwortrichtlinien

Eine Antwortrichtlinie ist ein Konzept der privaten Cloud DNS-Zone, das Regeln anstelle von Datensätzen enthält. Mit diesen Regeln können ähnliche Effekte erzielt werden wie beim Entwurfskonzept für die DNS-Antwortrichtlinienzone (RPZ) (IETF). Mit der Antwortrichtlinienfunktion können Sie benutzerdefinierte Regeln auf DNS-Servern in Ihrem Netzwerk einführen, die der DNS-Resolver während der Suche prüft. Wenn sich eine Regel in der Antwortrichtlinie auf die eingehende Abfrage auswirkt, wird diese verarbeitet. Andernfalls wird die Suche normal fortgesetzt. Weitere Informationen finden Sie unter Antwortrichtlinien und Regeln verwalten.

Eine Antwortrichtlinie unterscheidet sich von einer RPZ. Dabei handelt es sich um eine ansonsten normale DNS-Zone mit speziell formatierten Daten, die dafür sorgen, dass kompatible Resolver für spezielle Aktionen zuständig sind. Antwortrichtlinien sind keine DNS-Zonen und werden in der API separat verwaltet. Verwenden Sie zum Erstellen und Ändern von Antwortrichtlinien in Cloud DNS die ResponsePolicies-API. Antwortrichtlinien sind getrennt von ManagedZones und können nicht mithilfe der ManagedZones-API oder der RRSet-API verwaltet werden.

Routingrichtlinien

Mit DNS-Routingrichtlinien können Sie Ihren Traffic anhand bestimmter Kriterien steuern. Cloud DNS unterstützt auch die Systemdiagnose und automatische Failovers, die in jede Routingrichtlinie eingebettet sind. Systemdiagnosen sind für interne Passthrough-Network Load Balancer und interne Application Load Balancer verfügbar, für die globalen Zugriff aktiviert ist, sowie für regionsübergreifende interne Application Load Balancer.

Cloud DNS unterstützt die folgenden Routingrichtlinien:

  • Richtlinie für gewichtetes Round-Robin-Routing
  • Routingrichtlinie für die Standortbestimmung
  • Geofencing-Routingrichtlinie
  • Failover-Routingrichtlinie

Es kann jeweils nur ein Typ von Routingrichtlinie auf einen Ressourcendatensatz angewendet werden. Routingrichtlinien lassen sich nicht kombinieren, außer beim Konfigurieren einer Failover-Routingrichtlinie, in der Sie eine Routingrichtlinie für die Standortbestimmung als Sicherung festlegen können.

Richtlinien für die gewichtete Round-Robin-Weiterleitung

Mit einer WRR-Routingrichtlinie (Weighted Round-Robin) können Sie unterschiedliche Gewichtungen pro DNS-Ziel angeben. Cloud DNS sorgt dann dafür, dass der Traffic entsprechend der Gewichtung verteilt wird. Sie können diese Richtlinie zur Unterstützung manueller active-active- oder active-passive-Konfigurationen verwenden. Sie können den Traffic auch zwischen Produktions- und Testversionen der Software aufteilen.

Systemdiagnosen sind standardmäßig verfügbar, wenn die Ziele interne Passthrough-Network Load Balancer sind. Dadurch wird ein automatisches Failover aktiviert, wenn die Endpunkte die Systemdiagnosen nicht bestehen. Im Falle eines Failovers wird die Trafficaufteilung automatisch unter den verbleibenden fehlerfreien Endpunkten angepasst. Weitere Informationen finden Sie unter Systemdiagnosen.

Routingrichtlinien für die Standortbestimmung

Mit einer Geolocation-Routingrichtlinie (Geolocation) können Sie Traffic, der aus 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 dem Internet, mit externem Traffic oder mit Traffic verwenden, der aus Google Cloud stammt und an interne Passthrough-Network Load Balancer gebunden ist. Cloud DNS verwendet die Region, in der die Abfragen in Google Cloud eingegeben werden, als Quellregion.

Systemdiagnosen sind standardmäßig verfügbar, wenn das Ziel der interne Passthrough-Network Load Balancer, der interne Application Load Balancer oder der regionsübergreifende interne Application Load Balancer ist. Dies ermöglicht ein automatisches Failover, wenn die Endpunkte die Systemdiagnosen nicht bestehen. Bei einer Standortbestimmung wird der Traffic auf die nächstgelegene, dem Quelltraffic am nächsten liegende Standortbestimmung übergeben.

Geofencing-Routingrichtlinien

Die Systemdiagnose aktiviert den Richtlinientyp für das Geofencing-Routing, mit dem Sie den Traffic auf einen bestimmten Standort beschränken können, auch wenn alle Endpunkte an diesem Standort fehlerhaft sind. Wenn in einer Richtlinie zur Standortbestimmung Fehler bei der Systemdiagnose für einen bestimmten Geo-Bucket festgestellt werden, wird der Traffic automatisch an den nächstgelegenen Standort weitergeleitet. Wenn Geofencing aktiviert ist, erfolgt kein automatisches 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 Systemdiagnosen fehlschlagen.

Failover-Routingrichtlinien

Mit der Richtlinie für das Failover-Routing können Sie aktive Sicherungskonfigurationen einrichten, um Hochverfügbarkeit für interne Ressourcen in Ihrer VPC bereitzustellen. Sie können eine Failover-Routingrichtlinie nur für private Zonen konfigurieren.

Im Normalbetrieb werden die im active-Satz bereitgestellten IP-Adressen immer zurückgegeben. Wenn alle IP-Adressen im aktiven Satz fehlschlagen (der Systemstatus sich zu "fehlerhaft" ändert), beginnt Cloud DNS mit der Bereitstellung der IP-Adressen im Sicherungssatz. Sie können den Sicherungssatz als Richtlinien für die Standortbestimmung konfigurieren. Diese verhalten sich wie im Abschnitt zu den Richtlinien für die Standortbestimmung beschrieben. Wenn sie als interner Passthrough-Network Load Balancer, interner Application Load Balancer oder regionsübergreifender interner Application Load Balancer konfiguriert sind, werden alle virtuellen Sicherungs-IP-Adressen (VIP-Adressen) ebenfalls überprüft.

Mit Cloud DNS können Sie Traffic nach und nach zu den virtuellen Sicherungsadressen durchlassen. So können Sie sicher sein, dass die virtuellen Sicherungsadressen funktionieren. Sie können den Prozentsatz des an die Sicherung gesendeten Traffics als Bruchteil zwischen 0 und 1 konfigurieren. Der typische Wert muss 0, 1 sein.Mit Cloud DNS können Sie jedoch 100% des Traffics an die virtuellen IP-Adressen der Sicherung senden, um manuell ein Failover auszulösen. Systemdiagnosen können nur auf interne Load-Balancer angewendet werden. Daher müssen alle konfigurierten VIP-Adressen entweder interne Passthrough-Network Load Balancer, interne Application Load Balancer oder regionsübergreifende interne Application Load Balancer sein.

Systemdiagnosen

Cloud DNS unterstützt Systemdiagnosen für interne Passthrough-Network Load Balancer und interne Application Load Balancer, die globalen Zugriff aktiviert haben, sowie für regionsübergreifende interne Application Load Balancer.

Systemdiagnosen für private Load-Balancer sind nur in privaten verwalteten Zonen verfügbar. Für Weiterleitungs-, Peering- und verwaltete Reverse-Lookup-Zonen sind keine Systemdiagnosen verfügbar.

Ausführliche Informationen zu Systemdiagnosen für Load-Balancer finden Sie in der Übersicht über Systemdiagnosen.

Systemdiagnosen für interne Passthrough-Network Load Balancer

Cloud DNS bestimmt den Systemstatus eines internen Passthrough-Network Load Balancers mithilfe der integrierten Systemdiagnosekonfiguration des Load-Balancers. Cloud DNS stuft den internen Passthrough-Network Load Balancer als fehlerfrei ein und kann Traffic empfangen, wenn mindestens 20% der Systemdiagnosen erfolgreich sind.

Bei einem internen Passthrough-Network Load Balancer erhält Cloud DNS direkte Systemsignale von den einzelnen Back-End-Instanzen und ein Grenzwertalgorithmus wird angewendet, um zu bestimmen, ob ein Endpunkt fehlerfrei ist.

Auf einer einzelnen virtuellen IP-Adresse des internen Passthrough-Network Load Balancers können mehrere Dienste dahinter ausgeführt werden. Cloud DNS sucht nach Systemsignalen von dem Protokoll und Port, die in der Konfiguration der Systemdiagnose für den Load-Balancer angegeben sind. Ausführliche Informationen zu Systemdiagnosen finden Sie unter Systemdiagnosen – Übersicht.

Beim internen und regionsübergreifenden internen Application Load Balancer berücksichtigt Cloud DNS bei der Routingentscheidung den Zustand des Load-Balancers selbst. Wenn ein Load-Balancer eine Abfrage empfängt, verteilt er den Traffic nur an die fehlerfreien Back-End-Dienste. Um sicherzustellen, dass fehlerfreie Back-Ends vorhanden sind, können Sie den Lebenszyklus der Back-Ends mithilfe von Diensten wie verwalteten Instanzgruppen (Managed Instance Groups, MIGs) verwalten. Cloud DNS muss den Systemstatus einzelner Back-Ends nicht kennen. Der Load-Balancer übernimmt diese Aufgabe.

Gewichtete Round-Robin-Richtlinien und -Systemdiagnosen

Cloud DNS unterstützt Gewichtungen von 0 bis 1.000, einschließlich beider. Wenn Systemdiagnosen enthalten sind, geschieht Folgendes:

  • Wenn Sie mehrere Ziele mit der Gewichtung 0 konfigurieren, wird der Traffic gleichmäßig auf die Ziele verteilt.
  • Wenn Sie ein neues gewichtetes Ziel konfigurieren, das nicht null ist, wird es zum primären Ziel und der gesamte Traffic wird zu diesem Ziel verschoben.
  • Wenn Sie weitere Ziele mit einer Gewichtung ungleich null hinzufügen, berechnet Cloud DNS dynamisch die Trafficaufteilung zwischen den Zielen (mit jeder Anfrage) und verteilt den Traffic entsprechend. Wenn Sie beispielsweise drei Ziele mit den Gewichtungen 0, 25 und 75 konfiguriert haben, erhält das Ziel mit der Gewichtung 0 keinen Traffic, das Ziel mit einer Gewichtung von 25 erhält ein Viertel des Traffics und das verbleibende Ziel erhält drei Viertel des eingehenden Traffics.
  • Wenn Systemdiagnosen mit gewichteten Zielen ungleich null, aber nicht mit null gewichteten Zielen verknüpft sind, werden die mit null gewichteten Ziele immer als fehlerfrei erachtet. Wenn alle Datensätze ungleich null fehlerhaft sind, gibt Cloud DNS die null gewichteten Datensätze zurück.
  • Wenn Systemdiagnosen sowohl mit Einträgen ungleich null als auch mit null gewichteten Einträgen verknüpft sind und bei allen Systemdiagnosen Fehler auftreten, gibt Cloud DNS alle gewichteten Ziele ungleich null zurück und vermeidet null gewichtete Ziele.
  • Wenn Cloud DNS einen Gewichtungs-Bucket auswählt, der an den Anfragenden zurückgegeben werden soll (ein einzelnes Richtlinienelement), wird nur die IP-Adresse in diesem Gewichtungs-Bucket zurückgegeben. Wenn Sie nur eine IP-Adresse im Gewichtungs-Bucket angeben, ist nur diese IP-Adresse in der Antwort enthalten. Wenn der Gewichtungs-Bucket mehr als eine IP-Adresse enthält, gibt Cloud DNS alle IP-Adressen in einer zufälligen Reihenfolge zurück.

Richtlinie zur Standortbestimmung mit Systemdiagnose

Bei Richtlinien zur Standortbestimmung mit aktivierten Systemdiagnosen geschieht Folgendes:

  • Wenn für einen Geo-Bucket mehrere IP-Adressen konfiguriert sind und für alle IP-Adressen eine Systemdiagnose durchgeführt wurde, werden nur die fehlerfreien IP-Adressen zurückgegeben.
  • Wenn es eine Mischung aus Systemdiagnose und keiner Systemdiagnose gibt und alle IP-Adressen der Systemdiagnose fehlschlagen, gibt Cloud DNS alle IP-Adressen zurück, für die keine Systemdiagnose konfiguriert wurde. In diesem Szenario erfolgt kein automatisches Failover auf die nächstgelegene Region.
  • Diese Richtlinie leitet den Traffic in folgenden Fällen automatisch an den nächsten Geo-Bucket weiter:
    • Für alle IP-Adressen in einem Geo-Bucket ist die Systemdiagnose aktiviert.
    • In der Richtlinie ist der Fencing deaktiviert.
    • Alle IP-Adressen bestehen bei den Systemdiagnosen nicht. Dadurch wird ein automatisches Failover auf das nächste geografische Ziel ermöglicht.

Logging für Systemdiagnosen

Cloud DNS unterstützt das Logging von Systemdiagnosen und protokolliert den Status der Systemdiagnose von Back-End-Änderungen. Sie können damit Folgendes tun:

  • Prüfen Sie, ob die Routingrichtlinien wie erwartet funktionieren. Beispiel:
    • Bei GEO-Richtlinien können Sie damit prüfen, ob die Richtlinien die richtige Geografie erkennen und das richtige RR-Dataset zurückgeben.
    • Bei WRR-Richtlinien können Sie damit prüfen, ob die Richtlinien die IP-Adressen mit der richtigen Gewichtung zurückgeben.
  • Identifizieren Sie Infrastrukturprobleme mit bestimmten Back-Ends und IP-Adressen, die fehlerhaft sind.
  • Beheben Sie, warum bestimmte Back-Ends nie eingeschlossen werden oder die einzigen Back-Ends sind, die zurückgegeben werden.

Informationen zum Erstellen, Bearbeiten oder Löschen von DNS-Routingrichtlinien finden Sie unter DNS-Routingrichtlinien und -Systemdiagnosen verwalten.

Unterstützte Datensatztypen für DNS-Routingrichtlinien

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

Datensatztyp Beschreibung
A IPv4-Adressen
AAAA IPv6-Adressen
CNAME Kanonische Namen
MX Mail-Exchange-Datensätze
SRV Host/Port (RFC 2782)
TXT Textdaten