Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.
Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.
Auf dieser Seite finden Sie Informationen zum Logging und Monitoring von Messwerten für Cloud DNS, einschließlich
privater Zonen und Weiterleitungszonen.
Cloud DNS-Logging verwenden
Cloud DNS-Logging erfasst Abfragen, die Nameserver für Ihre VPC-Netzwerke (Virtual Private Cloud) auflösen.
In Logs erfasste Abfragen können von Compute Engine-VM-Instanzen, von Google Kubernetes Engine-Containern im selben VPC-Netzwerk, von Peering-Zonen oder von lokalen Clients, die eingehende DNS-Weiterleitung nutzen, stammen.
Private DNS-Zonen, Weiterleitungs-DNS-Zonen, alternative Nameserver, interneCloud de Confiance -DNS-Zonen oder externe DNS-Zonen können die Abfragen letztlich auflösen.
Logdatensätze gehören zu dem Projekt, das Inhaber des Netzwerks ist, die die Anfrage ausgeführt hat. Bei gemeinsam genutzter VPC gehören die Logdatensätze zum Hostprojekt, da das Hostprojekt Inhaber des Netzwerks ist.
Logging für private verwaltete Zonen aktivieren
Verwenden Sie DNS-Richtlinien, um das Logging für Ihre Netzwerke zu aktivieren oder zu deaktivieren. Wenn Sie die Abfrageprotokollierung aktivieren, wird jede DNS-Abfrage an eine private verwaltete Cloud DNS-Zone protokolliert.
Führen Sie die folgenden Schritte aus, um das Logging für ein Netzwerk zu aktivieren, das keine DNS-Richtlinie hat.
Ziel-IP-Adresse, nur für Weiterleitungsfälle relevant
Nein
egressError
String
Fehler beim Ausgangs-Proxy. Der tatsächliche Fehler, der vom Ausgangs-Proxy gemeldet wird, wie vom lokalen DNS-Server empfangen.
Mit diesem Feld kann zwischen einem tatsächlichen SERVFAIL, der vom lokalen DNS zurückgegeben wird, und einem Netzwerkfehler, der vom Egress-Proxy erkannt wird, unterschieden werden.
Nein
egressPath
String
Wenn none oder nicht angegeben, wurde für die Abfrage der standardmäßige Cloud DNS-Pfad verwendet oder OUTBOUND_ENDPOINT, wenn die Abfrage mit einem ausgehenden Endpunkt weitergeleitet wurde.
Nein
healthyIps
String
Satz von IP-Adressen im ResourceRecordSet, die zum Zeitpunkt der Abfrage für Cloud DNS als HEALTHY bekannt sind
Nein
location
String
Cloud de Confiance Region, z. B. us-east1, aus der die Antwort bereitgestellt wurde
Ja
outboundEndpoint.name
String
Vom Nutzer angegebener Name des Endpunkts für ausgehenden Traffic (dieser String ist nur vorhanden, wenn egress_path den Wert OUTBOUND_ENDPOINT hat)
Nein
outboundEndpoint.projectId
String
Die Projekt-ID von Cloud de Confiance , in der sich der Endpunkt für ausgehenden Traffic befindet (dieser String ist nur vorhanden, wenn egress_path den Wert OUTBOUND_ENDPOINT hat)
Nein
outboundEndpoint.location
String
Die Cloud de Confiance Region, in der sich der ausgehende Endpunkt befindet (dieser String ist nur vorhanden, wenn egress_path gleich OUTBOUND_ENDPOINT ist)
Nein
project_id
String
Cloud de Confiance Projekt-ID des Netzwerks, von dem die Abfrage empfangen wurde
Netzwerk, von dem die Abfrage unser System erreicht hat
Nein
source_type
String
Quelle der Abfrage: inbound-forwarding, gce-vm, internet, peering-zone, fqdn-forwarding-target
Nein
target_name
String
Der Zielname, z. B. Zonenname, Richtlinienname, interner Zonenname, externer Domainname
Ja
target_type
String
Typ des Ziels, das die DNS-Abfrage auflöst: private-zone, forwarding-zone, forwarding-policy, peering-zone, internal, external, response-policy, service-directory-zone, reverse-lookup-zone, zonal-private-zone
Ja
unHealthyIps
String
Satz von IP-Adressen im ResourceRecordSet, die zum Zeitpunkt der Abfrage für Cloud DNS als UNHEALTHY bekannt sind
Nein
vmInstanceId
Quelle der Nummer
Compute Engine-VM-Instanz-ID, nur anwendbar auf Abfragen, die von Compute Engine-VMs initiiert wurden
Nein
vmInstanceName
String/Quelle
Name der Compute Engine-VM-Instanz, gilt nur für Abfragen, die von Compute Engine-VMs initiiert wurden
Nein
vmProjectId
String/Quelle
Cloud de Confiance Projekt-ID des Netzwerks, aus dem die Anfrage gesendet wurde. Gilt nur für Anfragen, die von Compute Engine-VMs initiiert wurden.
Nein
vmZoneName
String/Quelle
Name der VM-Zone, von der die Abfrage gesendet wurde, gilt nur für Abfragen, die von Compute Engine-VMs initiiert wurden
Nein
Preise
Alle Cloud DNS-Logs werden in Cloud Logging geschrieben. Für diesen Dienst fallen keine separaten Kosten für Cloud DNS an. Diese Logs können jedoch je nach Größe der geschriebenen und gespeicherten Logs zu zusätzlichen Speicherkosten führen.
Für Berechnungszwecke: Cloud DNS schreibt etwa 5 MB an Log-Daten für die Verarbeitung von 10.000 DNS-Anfragen.
Sie können die Rate von DNS-Abfragen und -Antworten überwachen, die auf private Zonen, Weiterleitungszonen, Richtlinienweiterleitung, interne Cloud de Confiance -Zonen und das Internet verweisen. Monitoring ist in der Cloud de Confiance Console auf der Seite „Monitoring“ und in der Cloud Monitoring API verfügbar.
Das private DNS exportiert den Deltamesswert dns.googleapis.com/query/response_count, der das Label response_code enthält, um die Anzahl der Abfragen pro Antwortcode zu zählen.
Das Label response_code ist vom Typ string mit den möglichen Werten: NOERROR, FORMERR, SERVFAIL, NXDOMAIN, NOTIMP und UNKNOWN.
Definitionen dieser Codes finden Sie unter IANA DNS-RCODEs.
Der Messwert wird unter dem Ressourcentyp dns_query mithilfe der entsprechenden Felder des Eintragsformats für Logs exportiert.
DNS-Weitergabe überwachen
Wenn Sie Änderungen über die Google Cloud CLI oder die REST API vornehmen, werden die Änderungen anfangs als ausstehend markiert, bis der Vorgang abgeschlossen ist. Mit der gcloud-CLI oder der REST API können Sie den Status von Änderungen prüfen oder einen Änderungsverlauf abrufen.
Ein Vorgang ist abgeschlossen (Status done), wenn Cloud DNS das System aktualisiert hat, das die Server steuert. Solange nicht alle Nameserver aktualisiert wurden, kann es noch zu Verzögerungen kommen.
Wenn Sie überwachen und prüfen möchten, ob der DNS-Nameserver Ihre Änderungen übernommen hat, können Sie die Befehle watch und dig verwenden. Im folgenden Beispiel wird gezeigt, wie Sie Ihren Nameserver abrufen und prüfen, ob ein Nameserver Ihrer verwalteten Zone eine Änderung an einem MX-Eintrag vorliegt.
Der Befehl watch führt standardmäßig alle zwei Sekunden den Befehl dig aus. Sie können mit diesem Befehl festlegen, wann der autoritative Nameserver Ihre Änderung übernimmt. Dies sollte innerhalb von 120 Sekunden erfolgen. Nachdem der autoritative Nameserver die Änderung übernommen hat, können die DNS-Resolver den neuen Eintrag abrufen.
Resolver, die den vorherigen Eintrag bereits im Cache gespeichert haben, warten, bis der vorherige TTL-Wert des Eintrags abläuft.
Wenn Sie dig für den Nameserver Ihres Systems ausführen möchten, können Sie @<address> aus dem Befehl dig entfernen. Wenn Sie die Weitergabe an andere Nameserver überwachen möchten, können Sie address ändern, um auf andere Nameserver zu verweisen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2026-10-15 (UTC)."],[],[]]
