Logging und Monitoring

Diese Seite enthält Informationen zum Logging und Monitoring von Messwerten für Cloud DNS, einschließlich privater Zonen und Weiterleitungszonen. Außerdem enthält diese Seite Anweisungen zum Monitoring der Weitergabe Ihrer öffentlichen DNS-Änderungen.

Privates DNS-Logging

Das private DNS-Logging verfolgt Abfragen, die von Nameservern für Ihre Virtual Private Cloud-Netzwerke aufgelöst werden. Abfragen von einer externen Entität direkt an eine öffentliche Zone werden nicht in Logs erfasst, da sie von einem öffentlichen Nameserver verarbeitet werden.

In Logs erfasste Abfragen können von virtuellen Compute Engine-Maschinen, von Google Kubernetes Engine-Containern im selben VPC-Netzwerk, von Peering-Zonen oder von lokalen Clients über eine eingehende DNS-Weiterleitung stammen. Letztlich werden die Abfragen möglicherweise durch private DNS-Zonen, Weiterleitungs-DNS-Zonen, alternative Nameserver, interne GCP-DNS-Zonen oder externe DNS-Zonen aufgelöst.

Logeinträge gehören zu dem Projekt, das Inhaber des Netzwerks ist, das die Abfrage ausgeführt hat. Bei Shared VPC gehören die Logeinträge zum Hostprojekt, da das Hostprojekt Inhaber des Netzwerks ist.

Logging aktivieren und deaktivieren

Verwenden Sie DNS-Richtlinien, um das Logging für Ihre Netzwerke zu aktivieren.

Logging für ein Netzwerk ohne DNS-Richtlinie aktivieren

gcloud dns policies create policy-name \
    --networks=network \
    --enable-logging \
    --description=description

Ersetzen Sie dabei die folgenden Befehlsoptionen:

  • networks: ein oder mehrere Netzwerke in einer durch Kommas getrennten Liste
  • description: eine Beschreibung der Richtlinie

Logging für ein Netzwerk mit einer vorhandenen DNS-Richtlinie aktivieren

gcloud dns policies update policy-name \
    --networks=network \
    --enable-logging

Ersetzen Sie die folgende Befehlsoption:

  • networks: ein oder mehrere Netzwerke in einer durch Kommas getrennten Liste

Logging deaktivieren

Dadurch wird das Logging deaktiviert, während die Richtlinie beibehalten wird. Alternativ können Sie die Richtlinie komplett löschen.

gcloud dns policies update policy-name \
    --networks=network \
    --no-enable-logging

Ersetzen Sie die folgende Befehlsoption:

  • networks: ein oder mehrere Netzwerke in einer durch Kommas getrennten Liste

Logs ansehen

Rufen Sie in der Google Cloud Console die Seite der Loganzeige von Cloud DNS auf.
Zur Loganzeige

Eintragsformat

Jeder Logeintrag enthält ggf. die folgenden Felder. Einige Felder werden auch gemeinsam mit Monitoring-Messwerten genutzt.

Feld Feldtyp Beschreibung Wird in Messwerten verwendet
source_type String Quelle der Abfrage: "eingehende Weiterleitung", "GCE-VM" Ja
location String GCP-Region, z. B. "us-east1", von der die Antwort gesendet wurde. Ja
project_id String GCP-Projekt-ID des Netzwerks, von dem die Abfrage empfangen wurde. Ja
target_type String Zielart, die die DNS-Abfrage auflöst: "private Zone", "Zonenweiterleitung", "Richtlinienweiterleitung", "Peering-Zone", "intern", "extern" Ja
target_name String Der Zielname; z. B. Zonenname, Richtlinienname, Name der internen Zone, Name der externen Domain. Ja
queryName String/DNS DNS-Abfragename, RFC 1035 4.1.2. Nein
queryType String/DNS DNS-Abfragetyp, RFC 1035 4.1.2. Nein
responseCode Zahl/DNS Antwortcode, RFC 1035 4.1.1. Nein
rdata String/DNS DNS-Antwort im Präsentationsformat, RFC 1035 5.1, verkürzt auf 260 Byte Nein
authAnswer Boolesch/DNS Autoritative Antwort, RFC 1035 Nein
sourceNetwork String/Quelle Netzwerk, von dem die Abfrage unser System erreicht hat. Nein
vmInstanceId Zahl/Quelle ID der VM-Instanz von Compute Engine, gilt nur für Abfragen, die von Compute Engine-VMs initiiert werden. Nein
vmInstanceName String/Quelle Name der VM-Instanz von Compute Engine; gilt nur für Abfragen, die von Compute Engine-VMs initiiert werden. Nein
vmProjectId String/Quelle GCP-Projekt-ID des Netzwerks, von dem aus die Abfrage gesendet wurde; gilt nur für Abfragen, die von Compute Engine-VMs initiiert wurden. Nein
vmZoneName String/Quelle Name der verwalteten Zone, aus der die Abfrage gesendet wurde; gilt nur für Abfragen, die von Compute Engine-VMs initiiert wurden. Nein
sourceIP String/Quelle IP, von der die Abfrage stammt. Nein
destinationIP String/Ziel Ziel-IP, gilt nur für Weiterleitungsfälle. Nein
protocol String/DNS "TCP" | "UDP" Nein
egressError String Ausgehender Proxy-Fehler, d. h. der tatsächliche vom ausgehenden Proxy ermittelte Fehler, wie er vom lokalen DNS-Server empfangen wurde. Mithilfe dieses Felds kann ein tatsächlicher SERVFAIL, der vom lokalen DNS zurückgegeben wird, von einem Netzwerkfehler des ausgehenden Proxys unterschieden werden. Nein

Ausgehende Weiterleitung

Wenn Sie Logs mit SERVFAIL erhalten, in denen bestimmte Felder wie destinationIP, egressIP und egressError fehlen, finden Sie Informationen dazu im entsprechenden Abschnitt der Dokumentation zur Fehlerbehebung.

Monitoring-Messwerte

Cloud DNS exportiert Monitoring-Messwerte in Cloud Monitoring.

Sie können die Rate von DNS-Abfragen und -Antworten überwachen, die auf private Zonen, Weiterleitungszonen, Richtlinienweiterleitung, interne GCP-Zonen und das Internet abzielen. Das Monitoring ist in Cloud Monitoring und in der Monitoring API verfügbar.

Messwerte und Ressourcentypen

Das private DNS exportiert den Deltamesswert dns.googleapis.com/query/response_count mit dem Label response_code, um die Anzahl der Abfragen pro Antwortcode zu ermitteln.

Das Label response_code ist vom Typ string mit den möglichen Werten: NOERROR, FORMERR, SERVFAIL, NXDOMAIN, NOTIMP und UNKNOWN. Informationen zur Definition 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 prüfen

Wenn Sie Änderungen mit dem Befehlszeilentool oder mit der REST API vornehmen, werden diese erst einmal als ausstehend markiert, bis der Vorgang abgeschlossen ist. Mit dem gcloud-Befehlszeilentool oder mit der REST API können Sie den Status von Änderungen überprü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.

Änderungen für eine verwaltete Zone auflisten

Befehlszeile

gcloud dns record-sets changes list --zone="myzonename"

Python

def list_changes(project_id, zone_name):
    client = dns.Client(project=project_id)
    zone = client.zone(zone_name)

    changes = zone.list_changes()

    return [(change.started, change.status) for change in changes]

Übernahme der DNS-Änderungen prüfen

Mit den Befehlen watch und dig können Sie prüfen, ob Ihre Änderungen vom DNS-Nameserver übernommen wurden. Das folgende Beispiel zeigt, wie Sie Ihren Nameserver abrufen und prüfen, ob eine Änderung an einem MX-Eintrag von einem Nameserver Ihrer verwalteten Zone übernommen wurde.

So rufen Sie die Nameserver Ihrer verwalteten Zone ab:

gcloud dns managed-zones describe zone-name

Ersetzen Sie die folgende Befehlsoption:

  • zone-name: der Name Ihrer Cloud DNS-Zone

Prüfen Sie, ob die Einträge auf dem autoritativen Nameserver verfügbar sind. Ersetzen Sie your-zone-nameserver durch einen der Nameserver aus der verwalteten Zone:

watch dig example.com in MX @your-zone-nameserver

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.

Sie können @<address> aus dem Befehl "dig" entfernen, um "dig" für den Nameserver Ihres Systems auszuführen, oder die Adresse ändern, wenn Sie die Weitergabe an andere Nameserver überwachen möchten.

Weitere Informationen