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. Elle fournit également des instructions pour surveiller la propagation de vos modifications DNS publiques.

Utiliser la journalisation Cloud DNS

La journalisation Cloud DNS suit les requêtes résolues par les serveurs de noms pour vos réseaux VPC (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 consignées peuvent provenir d'instances de machines virtuelles (VM) Compute Engine, de conteneurs Google Kubernetes Engine situés sur le même réseau VPC, de zones d'appairage ou de clients sur site qui utilisent un transfert DNS entrant. Les zones DNS privées, les zones DNS de transfert, les serveurs de noms secondaires, les zones Cloud DNS internes de Google ou les zones DNS externes peuvent éventuellement résoudre les requêtes.

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

Remarque : Seules les requêtes qui atteignent un serveur de noms sont consignées. Les réponses de cache des résolveurs Cloud DNS et les requêtes traitées à partir des caches ne sont pas consignées.

Activer et désactiver la journalisation

Utilisez les règles DNS pour activer et désactiver la journalisation pour vos réseaux.

Remarque : Lorsque vous activez la journalisation des requêtes, chaque requête DNS adressée à une zone gérée Cloud DNS est enregistrée.

Si vous souhaitez activer la journalisation pour un réseau ne disposant pas de règles DNS, exécutez la commande dns policies create.

gcloud

gcloud dns policies create POLICY_NAME \
    --networks=NETWORK \
    --enable-logging \
    --description=DESCRIPTION

Remplacez l'élément suivant :

• POLICY_NAME : nom de la règle DNS
• NETWORK : un ou plusieurs réseaux dans une liste séparée par des virgules
• DESCRIPTION : description de la règle

Si vous souhaitez activer la journalisation pour un réseau disposant d'une règle DNS existante, exécutez la commande dns policies update.

gcloud

gcloud dns policies update POLICY_NAME \
    --networks=NETWORK \
    --enable-logging

Remplacez l'élément suivant :

• POLICY_NAME : nom de la règle DNS
• NETWORK : un ou plusieurs réseaux dans une liste séparée par des virgules

Pour désactiver la journalisation tout en laissant la règle en place, exécutez la commande dns policies update.

gcloud

gcloud dns policies update POLICY_NAME \
    --networks=NETWORK \
    --no-enable-logging

Remplacez l'élément suivant :

• POLICY_NAME : nom de la règle DNS
• NETWORK : un ou plusieurs réseaux dans une liste séparée par des virgules

Pour supprimer entièrement la règle, exécutez la commande dns policies delete.

gcloud

gcloud dns policies delete POLICY_NAME \

Remplacez POLICY_NAME par le nom de la règle DNS que vous souhaitez supprimer.

Voir les journaux

Console

Dans Google Cloud Console, accédez à la page Explorateur de journaux.

Accéder à l'explorateur de journaux

Afficher les champs de format des enregistrements

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 Google Cloud (par exemple, us-east1) à partir de laquelle la réponse a été diffusée	Oui
project_id	Chaîne	ID de projet Google Cloud situé dans le réseau à partir duquel la requête a été reçue	Oui
target_type	Chaîne	Type de cible résolvant la requête DNS : private-zone, forwarding-zone, forwarding-policy, peering-zone, internal, external	Oui
target_name	Chaîne	Nom de la cible, par exemple, le nom de la zone, le nom de la règle, le nom de la zone interne ou le nom de domaine externe	Oui
queryName	Chaîne/DNS	Nom de la requête DNS, RFC 1035 4.1.2	Non
queryType	Chaîne/DNS	Type de requête DNS, RFC 1035 4.1.2	Non
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	Non
authAnswer	Booléen/DNS	Réponse faisant autorité, RFC 1035	Non
sourceNetwork	Chaîne/Source	Réseau à partir duquel la requête a atteint notre système	Non
vmInstanceId	Numéro/Source	ID d'instance de la VM Compute Engine, applicable uniquement aux requêtes lancées par des VM Compute Engine	Non
vmInstanceName	Chaîne/Source	Nom d'instance de la VM Compute Engine, applicable uniquement aux requêtes lancées par les VM Compute Engine	Non
vmProjectId	Chaîne/Source	ID de projet Google Cloud situé dans le 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 la 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	Non
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

Tarifs

Tous les journaux Cloud DNS sont écrits dans Cloud Logging. Aucuns frais distincts ne sont facturés par Cloud DNS pour ce service. Toutefois, ces journaux peuvent entraîner des coûts de stockage supplémentaires en fonction de la taille des journaux écrits et stockés.

À des fins de calcul, Cloud DNS écrit environ 5 Ko de données de journal pour le traitement de 10 000 requêtes DNS.

Pour en savoir plus sur la tarification de Cloud Logging, consultez la page Tarifs de la suite Google Cloud Operations : Cloud Logging.

Résoudre les problèmes de 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 pointent vers des zones privées, des zones de transfert, un transfert de règles, des zones internes Google Cloud et Internet. La fonctionnalité de surveillance est disponible sur la page Surveillance de Google Cloud Console et dans l'API Cloud Monitoring.

Le DNS privé exporte la métrique delta dns.googleapis.com/query/response_count contenant le libellé response_code pour 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. Pour obtenir la définition de ces codes, consultez la page RCODE DNS IANA.

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 gcloud 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 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

Pour répertorier les modifications apportées à une zone gérée, consultez les options suivantes.

gcloud

Exécutez la commande dns record-sets changes list :

gcloud dns record-sets changes list --zone=ZONE

Remplacez ZONE par le nom de la zone gérée dont vous souhaitez gérer les jeux d'enregistrements.

Python

dns/api/main.py

Afficher sur GitHub

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

Pour surveiller et vérifier que le serveur de noms DNS a récupéré vos modifications, vous pouvez exécuter les commandes watch et dig. L'exemple suivant montre comment rechercher un serveur de noms de votre zone gérée et vérifier s'il a récupéré la modification d'un enregistrement MX.

Remarque : Les commandes watch et dig sont fournies par le système d'exploitation Linux et ne sont pas des commandes gcloud. Par conséquent, le préfixe gcloud n'est pas nécessaire pour pouvoir les exécuter. Pour les autres systèmes d'exploitation, vous devrez peut-être installer les commandes.

Pour rechercher les serveurs de noms de votre zone, exécutez la commande dns managed-zones describe :

gcloud dns managed-zones describe ZONE_NAME

Remplacez ZONE_NAME par le nom de votre zone Cloud DNS.

Pour vérifier si les enregistrements sont déjà disponibles sur votre serveur de noms primaire, exécutez la commande dig suivante :

watch dig example.com in MX @ZONE_NAME_SERVER

Remplacez ZONE_NAME_SERVER par l'un des serveurs de noms de la zone gérée :

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.

Pour exécuter dig sur le serveur de noms de votre système, vous pouvez supprimer @<address> de la commande dig. Si vous souhaitez surveiller la propagation vers d'autres serveurs de noms, vous pouvez modifier la valeur address pour qu'elle pointe vers d'autres serveurs de noms.

Étape suivante

• Pour ajouter, supprimer ou mettre à jour des enregistrements, consultez la section Gérer les enregistrements.
• Pour créer, mettre à jour, répertorier et supprimer des zones gérées, consultez la page Gérer les zones.
• Pour trouver des solutions aux problèmes courants que vous pouvez rencontrer lors de l'utilisation de Cloud DNS, consultez la page Dépannage.
• Pour référencer l'API, consultez la documentation sur l'API REST Cloud DNS.
• Pour en savoir plus sur Cloud DNS, consultez la page Présentation de Cloud DNS.