Résoudre les problèmes liés à Cloud DNS

Ce document fournit des conseils pour résoudre les problèmes liés à Cloud DNS dans Google Distributed Cloud (GDC) air gap. Il couvre les erreurs et les problèmes potentiels que vous pourriez rencontrer lors de l'exécution d'opérations de gestion sur les configurations DNS, et fournit des conseils et des suggestions pour déboguer les problèmes de résolution DNS. Ce document s'adresse aux administrateurs de plate-forme et aux opérateurs d'applications chargés de gérer les enregistrements DNS dans un projet.

Résoudre les problèmes liés aux opérations de gestion Cloud DNS

Cette section fournit des informations de dépannage pour les problèmes courants rencontrés lors des opérations de création, de lecture, de mise à jour et de suppression (CRUD) sur les zones et les jeux d'enregistrements Cloud DNS.

Dépannage de base

  • Assurez-vous de disposer des rôles IAM appropriés, comme décrit dans Préparer les autorisations IAM.
  • Si vous utilisez gdcloud, vous pouvez actualiser votre jeton d'authentification en exécutant gdcloud auth login.

Nommage et validation des ressources (RFC 1123)

Problème : la création ou la mise à jour échoue avec des erreurs d'argument non valide ou de validation.

Détails :

  • Noms de ressources : les noms des zones DNS et des jeux d'enregistrements doivent être conformes à la norme RFC
    1. Ils ne doivent contenir que des caractères alphanumériques minuscules ou -, et doivent commencer et se terminer par un caractère alphanumérique.
  • Noms DNS : les valeurs des noms de domaine et des noms de domaine complets doivent être des noms de domaine valides.
  • Valeurs d'énumération : les valeurs telles que la visibilité (PUBLIC ou PRIVATE) et les types d'enregistrements (par exemple, A, CNAME) sont sensibles à la casse et doivent correspondre exactement à la chaîne attendue.

Impossible de supprimer des zones non vides

Problème : Impossible de supprimer une zone gérée ; l'opération est refusée.

Détails : Une zone DNS gérée doit être vide de jeux d'enregistrements de ressources avant de pouvoir être supprimée. Vous devez d'abord supprimer tous les enregistrements de la zone.

Conflits de noms et de domaines

Problème : Échec de la création d'une ressource avec une erreur indiquant que le nom ou le domaine est déjà utilisé.

Détails :

  • Nom de la ressource Kubernetes : le nom de l'objet (par exemple, le nom dans metadata.name) doit être unique dans l'espace de noms du projet.
  • Nom DNS (FQDN) : le nom de domaine réel (par exemple, dnsName pour les zones ou les enregistrements) doit être unique pour une visibilité donnée (PUBLIC ou PRIVATE). Vous ne pouvez pas créer deux zones ou deux enregistrements avec le même nom de domaine dans le même niveau de visibilité.

Résoudre les problèmes de résolution DNS

Cette section aide les administrateurs de plate-forme et les opérateurs d'applications à résoudre les problèmes de résolution DNS lors de l'accès aux services hébergés sur Google Distributed Cloud.

Attendre la propagation et vider le cache DNS

Lorsque des enregistrements DNS sont créés ou mis à jour, il est possible que les modifications ne soient pas visibles instantanément. Ce délai est généralement dû aux raisons suivantes :

  1. Temps de rapprochement : le système a besoin de temps pour traiter la requête et mettre à jour la configuration du serveur DNS. Cela prend généralement quelques minutes.
  2. Délai de propagation DNS (mise en cache) : les résolveurs et les clients DNS mettent en cache les enregistrements pour accélérer les recherches. Les clients peuvent continuer à utiliser l'ancien enregistrement jusqu'à l'expiration de la valeur TTL (Time To Live).

Recommandations :

  • Attendre : prévoyez suffisamment de temps pour le rapprochement et l'expiration du cache.
  • Vider le cache : videz votre cache DNS local pour forcer une nouvelle recherche.

Vérifier la configuration du résolveur local

Assurez-vous que votre client utilise les bons serveurs DNS. Si vous ne connaissez pas l'adresse IP correcte, contactez votre équipe Infrastructure Operations (IO) pour trouver l'adresse IP du serveur DNS approprié.

  • Linux/macOS : vérifiez le contenu de /etc/resolv.conf.
  • Windows : exécutez ipconfig /all et vérifiez les serveurs DNS listés.

Les postes de travail de l'administrateur de plate-forme (PA) et de l'opérateur d'application (AO) sur le réseau du client doivent utiliser une résolution DNS distincte du réseau WAN IO et du réseau OIRv2. Étant donné que des noms de domaine GDC identiques sont résolus en différentes adresses IP selon que la requête arrive via le WAN IO ou l'interconnexion client, il n'est pas possible d'utiliser une configuration DNS partagée pour les postes de travail IO et PA ou AO. Pour en savoir plus, consultez Interconnexions système, Schéma de dénomination de nom de domaine DNS et le runbook DNS-R0016.

Tester la résolution à l'aide d'outils standards

Utilisez des outils de ligne de commande standards pour tester la résolution et identifier l'origine de l'échec.

  • Recherche de base :

    dig <domain_name>

    ou

    nslookup <domain_name>

  • Interroger un serveur DNS spécifique : si vous connaissez l'adresse IP du serveur ManagedDNS public, interrogez-le directement pour contourner les résolveurs locaux :

    dig @<public_dns_server_ip> <domain_name>

  • Interroger un serveur de noms public : Pour exclure les problèmes de résolveur local, essayez d'interroger un résolveur public tel que Google DNS :

    dig @8.8.8.8 <domain_name>

Analyser les codes de réponse DNS

Lorsque vous utilisez dig ou nslookup, vérifiez le code d'état dans la réponse :

  • NXDOMAIN : le nom de domaine est introuvable. Vérifiez qu'il n'y a pas de fautes de frappe ou que l'enregistrement existe.
  • SERVFAIL : le serveur n'a pas pu traiter la requête. Cela indique souvent un problème côté serveur ou un échec de communication entre les serveurs DNS.
  • NOERROR : la requête a abouti, mais il n'y a peut-être pas de réponse. Vérifiez si le type d'enregistrement demandé (par exemple, A, CNAME) existe.
  • REFUSED : le serveur a refusé de répondre à la requête, probablement en raison de paramètres de stratégie ou de contrôle des accès.

Vérifier la connectivité réseau

Assurez-vous que le trafic réseau vers le serveur DNS n'est pas bloqué.

  • Le DNS utilise le port 53 pour UDP et TCP.

  • Testez la connectivité à l'aide de nc (netcat) :

    nc -zv <dns_server_ip> 53

  • Vérifiez que les règles de pare-feu autorisent le trafic sur le port 53.

Vider le cache DNS

Le vidage du cache DNS supprime toutes les entrées de votre cache DNS local. Cela force votre système d'exploitation à interroger à nouveau les serveurs DNS pour le nom de domaine, ce qui vous permet d'obtenir l'enregistrement le plus récent plutôt qu'un enregistrement obsolète mis en cache.

  • Windows : ipconfig /flushdns
    • Action : vide le cache du résolveur DNS géré par le service client DNS.
  • macOS : sudo killall -HUP mDNSResponder
    • Action : envoie un signal de raccrochage (HUP) au processus mDNSResponder, ce qui le force à actualiser et à vider son cache.
  • Linux (systemd-resolved) : sudo systemd-resolve --flush-caches ou sudo resolvectl flush-caches
    • Action : indique au service systemd-resolved d'ignorer son cache DNS interne.

Vérifier l'état des ressources avec l'API ou gdcloud

Si vous êtes un locataire ou si vous avez accès à l'API GDC, vous pouvez vérifier l'état des ressources directement :

  • Vérifiez une zone DNS :

    kubectl describe manageddnszone <zone_name> -n <project_namespace>

  • Vérifier un jeu d'enregistrements de ressources :

    kubectl describe resourcerecordset <record_name> -n <project_namespace>

    Recherchez les conditions et les événements susceptibles d'indiquer des échecs dans le processus de rapprochement.

Si vous avez accès à la ligne de commande gdcloud, vous pouvez utiliser la sous-commande describe comme indiqué dans Répertorier les enregistrements DNS ou Répertorier les zones DNS.