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. 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 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 journaux appartiennent au projet qui possède le réseau ou la zone publique que a transféré 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 réseau.
Activer et désactiver la journalisation pour les zones gérées privées
Utilisez les règles DNS pour activer ou désactiver la journalisation pour vos réseaux. Lorsque vous activez la journalisation des requêtes, chaque requête DNS à Cloud DNS gérée 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 l'élément suivant :
POLICY_NAME
: nom de la règle DNSNETWORK
: un ou plusieurs réseaux dans une liste séparée par des virgulesDESCRIPTION
: 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 DNSNETWORK
: 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 DNSNETWORK
: 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 gérées publiques
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 Google Cloud Console, accédez à la page 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, 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 |
healthyIps |
Chaîne | Ensemble d'adresses IP dans le jeu d'enregistrement de ressources qui ont l'état |
Non |
unHealthyIps |
Chaîne | Ensemble d'adresses IP dans le jeu d'enregistrement de ressources qui ont l'état |
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 Mo de données de journal pour le traitement de 10 000 requêtes DNS.
Pour en savoir plus sur les tarifs de Cloud Logging, consultez la page Tarifs pour Google Cloud Observability: 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 la console Google Cloud 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.
Étape suivante
- Pour ajouter, supprimer et mettre à jour des enregistrements, consultez la page Ajouter, modifier et supprimer des 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.