Utiliser la journalisation et la surveillance

Cette page fournit des informations sur la journalisation et la surveillance des métriques de Cloud DNS, y compris celles des zones publiques, des zones privées et des zones de transfert. Cette page 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 cloud privés virtuels (VPC, Virtual Private Cloud), ainsi que les requêtes d'une entité externe directement vers une zone publique.

Les requêtes consignées peuvent provenir d'instances de machines virtuelles (VM) Compute Engine, de conteneurs Google Kubernetes Engine appartenant au 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 journal appartiennent au projet qui possède le réseau ou la zone publique contenant la requête. Dans le cas d'un VPC partagé, les enregistrements de journal appartiennent au projet hôte, car ce dernier est propriétaire du réseau.

Activer et désactiver la journalisation pour les zones gérées privées

Utilisez des règles DNS pour activer ou désactiver la journalisation sur vos réseaux. Lorsque vous activez la journalisation des requêtes, chaque requête DNS adressée à une zone gérée privée Cloud DNS est consigné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 les éléments suivants :

  • 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 les éléments suivants :

  • 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 les éléments suivants :

  • 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.

Activer et désactiver la journalisation pour les zones publiques gérées

Pour activer la journalisation pour une zone gérée publique existante, exécutez la commande dns managed-zones update.

gcloud 

gcloud dns managed-zones update ZONE_NAME --log-dns-queries \

Remplacez ZONE_NAME par le nom de la zone gérée DNS pour laquelle vous souhaitez activer la journalisation.

Pour désactiver la journalisation pour une zone gérée publique existante, exécutez la commande dns managed-zones update.

gcloud 

gcloud dns managed-zones update ZONE_NAME --no-log-dns-queries \

Remplacez ZONE_NAME par le nom de la zone gérée DNS pour laquelle vous souhaitez désactiver la journalisation.

Voir les journaux

Console

Dans la console Google Cloud, 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
alias_query_response_code (aperçu) Chaîne Le code de réponse renvoyé par la requête pour résoudre le nom canonique de l'enregistrement d'ALIAS. Oui
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, 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 Non
queryType Chaîne/DNS Type de requête DNS, RFC 1035 4.1.2 Non
responseCode Numéro/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 initié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 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 Non
destinationIP Chaîne/Cible Adresse IP cible, applicable uniquement aux cas de transfert Non
protocol Chaîne/DNS TCP | UDP Non
healthyIps Chaîne

Ensemble d'adresses IP dans le jeu d'enregistrements ResourceRecordSet connues pour être HEALTHY dans Cloud DNS au moment de la requête

 Non
unHealthyIps Chaîne

Ensemble d'adresses IP dans le jeu d'enregistrements de ressources dont l'état est UNHEALTHY dans Cloud DNS au moment de la requête

 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

Tarification

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 Mo 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 l'observabilité Google Cloud: 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.

Surveiller les métriques

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 utilisez Google Cloud CLI ou l'API REST pour effectuer des modifications, 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 gcloud CLI 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, exécutez la commande dns record-sets changes list.

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.

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.

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.

Étapes suivantes