Journalisation et surveillance

Cette page fournit des informations sur la journalisation et la surveillance des métriques de Cloud DNS, y compris celles des zones privées et des zones de transfert. Cette page fournit également des instructions pour surveiller la propagation de vos modifications DNS publiques.

Journalisation DNS privée

La journalisation DNS privée suit les requêtes résolues par les serveurs de noms de vos réseaux Virtual Private Cloud. Les requêtes en provenance d'une entité externe envoyées directement à une zone publique ne sont pas consignées, car elles sont gérées par un serveur de noms public.

Les requêtes enregistrées peuvent provenir de machines virtuelles (VM) Compute Engine, de conteneurs Google Kubernetes Engine appartenant au même réseau VPC, ou de zones d'appairage, ou de clients sur site via un transfert DNS entrant. Les requêtes peuvent éventuellement être résolues par des zones DNS privées, des zones DNS de transfert, un autre serveur de noms, des zones DNS internes GCP ou des zones DNS externes.

Les enregistrements de journaux appartiennent au projet qui possède le réseau ayant acheminé la requête. Dans le cas d'un réseau VPC partagé, les enregistrements de journaux appartiennent au projet hôte, car ce dernier est propriétaire du réseau.

Activer et désactiver la journalisation

Utilisez des règles DNS pour activer la journalisation de vos réseaux.

Activer la journalisation pour un réseau n'ayant pas de règle DNS

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

Remplacez les options de commande suivantes :

  • réseaux : un ou plusieurs réseaux dans une liste d'éléments séparés par une virgule
  • description : description de la règle

Activer la journalisation pour un réseau disposant d'une règle DNS existante

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

Remplacez l'option de commande suivante :

  • réseaux : un ou plusieurs réseaux dans une liste d'éléments séparés par une virgule

Désactiver la journalisation

La commande suivante désactive la journalisation tout en laissant la stratégie en place. Vous pouvez également supprimer entièrement cette dernière.

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

Remplacez l'option de commande suivante :

  • réseaux : un ou plusieurs réseaux dans une liste d'éléments séparés par une virgule

Afficher les journaux

Accédez à la page "Visionneuse de journaux" de Cloud DNS dans Google Cloud Console.
Accéder à la page "Visionneuse de journaux"

Format d'enregistrement

Chaque entrée de journal comporte les champs suivants, le cas échéant. Certains champs sont également partagés avec les métriques de surveillance.

Champ Type de champ Description Utilisé dans les métriques
source_type Chaîne Source de la requête : "inbound-forwarding", "gce-vm" Oui
location Chaîne Région GCP à partir de laquelle la réponse a été diffusée, par exemple "us-east1". Oui
project_id Chaîne ID de projet GCP du réseau à partir duquel la requête a été émise Oui
target_type Chaîne Type de cible résolvant la requête DNS : "zone privée", "zone de transfert", "stratégie de transfert", "zone d'appairage", "interne", "externe" Oui
target_name Chaîne Nom de la cible ; par exemple, nom de zone, nom de stratégie, nom de zone interne, nom de domaine externe Oui
queryName Chaîne/DNS Nom de la requête DNS, RFC 1035 4.1.2 No
queryType Chaîne/DNS Type de requête DNS, RFC 1035 4.1.2 No
responseCode Nombre/DNS Code de réponse, RFC 1035 4.1.1 Non
rdata Chaîne/DNS Réponse DNS au format de présentation, RFC 1035 5.1, tronquée à 260 octets No
authAnswer Booléen/DNS Réponse faisant autorité, RFC 1035 No
sourceNetwork Chaîne/Source Réseau à partir duquel la requête a atteint notre système No
vmInstanceId Numéro/source ID d'instance de la VM Compute Engine, applicable uniquement aux requêtes initiées par des VM Compute Engine Non
vmInstanceName Chaîne/Source Nom d'instance de VM Compute Engine, applicable uniquement aux requêtes lancées par des VM Compute Engine Non
vmProjectId Chaîne/Source ID de projet GCP du réseau à partir duquel la requête a été envoyée, applicable uniquement aux requêtes lancées par des VM Compute Engine. Non
vmZoneName Chaîne/Source Nom de la zone de VM à partir de laquelle la requête a été envoyée, applicable uniquement aux requêtes lancées par des VM Compute Engine. Non
sourceIP Chaîne/Source Adresse IP à l'origine de la requête No
destinationIP Chaîne/Cible Adresse IP cible, applicable uniquement aux cas de transfert Non
protocol Chaîne/DNS "TCP" | "UDP" Non
egressError Chaîne Erreur de proxy de sortie, erreur réelle signalée par le proxy de sortie telle que reçue du serveur DNS sur site. Ce champ permet de différencier un SERVFAIL réel renvoyé par le DNS sur site d'une erreur réseau rencontrée par le proxy de sortie. Non

Transfert sortant

Si vous recevez des journaux contenant SERVFAIL où sont absents certains champs tels que destinationIP, egressIP et egressError, consultez la section à ce sujet dans la documentation de dépannage.

Métriques de surveillance

Cloud DNS exporte les métriques de surveillance vers Cloud Monitoring.

Vous pouvez surveiller le taux de requêtes et de réponses DNS qui ciblent des zones privées, des zones de transfert, des transferts de règles, des zones internes GCP et Internet. La surveillance est disponible dans Cloud Monitoring et dans l'API Monitoring.

Métriques et types de ressources

Le DNS privé exporte la métrique delta dns.googleapis.com/query/response_count contenant le libellé response_code afin de compter le nombre de requêtes par code de réponse.

Le libellé response_code est de type string avec les valeurs possibles suivantes : NOERROR, FORMERR, SERVFAIL, NXDOMAIN, NOTIMP et UNKNOWN. Consultez la page RCODE DNS IANA pour obtenir des définitions de ces codes.

La métrique est exportée sous le type de ressource dns_query à l'aide des champs applicables du format d'enregistrement du journal.

Surveiller la propagation DNS

Lorsque vous effectuez des modifications à l'aide de l'outil de ligne de commande ou de l'API REST, celles-ci sont initialement marquées comme en attente jusqu'à ce que l'opération soit terminée. Vous pouvez vérifier l'état des modifications ou en obtenir un historique à l'aide de l'outil de ligne de commande gcloud ou de l'API REST.

Une opération est terminée (état : done) lorsque Cloud DNS a correctement mis à jour le système qui contrôle les serveurs. La mise à jour de tous les serveurs de noms peut occasionner des retards.

Répertorier les modifications pour une zone gérée

Ligne de commande

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]

Vérifier la propagation DNS

Vous pouvez utiliser les commandes watch et dig pour surveiller vos modifications et vérifier qu'elles ont bien été détectées par le serveur de noms DNS. L'exemple suivant montre comment rechercher votre serveur de noms et vérifier si une modification apportée à un enregistrement MX est détectée par l'un des serveurs de noms de votre zone gérée.

Recherchez les serveurs de noms de votre zone :

gcloud dns managed-zones describe zone-name

Remplacez l'option de commande suivante :

  • zone-name : nom de votre zone Cloud DNS

Vérifiez si les enregistrements sont déjà disponibles sur votre serveur de noms primaire. Remplacez your-zone-nameserver par l'un des serveurs de noms de la zone gérée :

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

La commande watch exécute la commande dig toutes les deux secondes par défaut. Celle-ci vous permet de déterminer à quel moment votre serveur de noms primaire effectuera la modification, ce qui devrait se produire dans les 120 secondes. Une fois que votre serveur de noms faisant autorité dispose de la modification, les résolveurs DNS peuvent commencer à récupérer le nouvel enregistrement. Les résolveurs qui possèdent déjà l'enregistrement précédent en cache attendent que la valeur TTL précédente de l'enregistrement arrive à expiration.

Vous pouvez supprimer la valeur @<address> de la commande dig puis exécuter celle-ci sur le serveur de noms de votre système, ou modifier l'adresse identifiant d'autres serveurs de noms si vous souhaitez surveiller la propagation vers ces serveurs.

Étapes suivantes