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