--- service: "Publicasta" schema_version: "1.0" article_id: 946 title: "TelltaleDNS 0.6.0 simplifie les tests DNS mixtes sur Raspberry Pi et Kubernetes" language: "fr" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=fr" json_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=fr" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=fr" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-10-23T06:39:20+00:00" updated_at: "2026-10-23T06:39:20+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=de" markdown_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=de" json_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=en" markdown_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=en" json_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=es" markdown_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=es" json_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=zh" --- # TelltaleDNS 0.6.0 simplifie les tests DNS mixtes sur Raspberry Pi et Kubernetes > TelltaleDNS 0.6.0 ajoute la visibilité sur les workloads Kubernetes, les tests de basculement et HTTPS pour son API web. Une version à essayer en homelab ou sur de petits clusters, avec prudence avant tout usage en production. ## Ce que TelltaleDNS 0.6.0 change réellement ![Équipements de laboratoire domestique Raspberry Pi et Kubernetes connectés pour un test de basculement DNS](https://publicasta.com/storage/projects/10/pages/946/2026/10/2247bc95-4ecf-4e69-af99-5c32bd43e6ad.webp) TelltaleDNS 0.6.0, publié le 20 octobre 2026, cherche moins à ajouter un serveur DNS généraliste qu’à faciliter l’observation et la mise à l’épreuve d’un environnement mixte. Son changement le plus visible concerne Kubernetes : les workloads peuvent apparaître comme des appareils nommés dans l’interface web et l’historique des requêtes. L’opérateur obtient ainsi une réponse plus utile à une question familière — quel client a effectué cette requête ? — lorsque la réponse serait autrement masquée par le réseau du cluster, des adresses de résolveurs partagées ou des libellés liés à l’infrastructure. Cette distinction compte, car cette version améliore autant la visibilité opérationnelle que la résolution. Une entrée du tableau de bord identifiant un workload Kubernetes peut être examinée à côté des appareils ordinaires, ce qui facilite la comparaison entre l’activité du cluster et les requêtes d’un Raspberry Pi, d’un poste de travail ou d’un autre client réseau. La fonctionnalité ne transforme pas tous les problèmes DNS en problèmes simples, mais elle réduit une couche d’ambiguïté : l’opérateur dispose d’un workload nommé à examiner, plutôt que d’une simple adresse ou d’un flux de requêtes impossible à distinguer. L’autre ajout majeur est un test de basculement intégré. TelltaleDNS peut arrêter volontairement certains nœuds pendant des périodes de 15 à 300 secondes, puis indiquer quels clients ont changé de nœud pendant l’exercice. L’essentiel est qu’il s’agit d’un test contrôlé du comportement, et pas seulement d’un indicateur d’état. Une installation peut sembler saine tant que tous les nœuds sont disponibles, puis échouer lorsqu’un nœud disparaît, lorsque les clients conservent une ancienne réponse ou lorsque le routage ne déplace pas le trafic comme prévu. Le test révèle cet écart sans obliger l’opérateur à attendre une panne imprévue. La plage de durées permet aussi d’ajuster le test. Une interruption brève peut montrer si les clients réagissent rapidement ; une interruption plus longue peut révéler si le repli reste stable après le premier cycle de nouvelle tentative. Le rapport obtenu vise à relier l’événement de panne au déplacement des clients, afin que l’opérateur puisse examiner ce qui a réellement changé au lieu de supposer que la redondance a fonctionné simplement parce qu’un nœud de secours existait. Cette fonction est particulièrement pertinente pour les petites installations, où le DNS repose souvent sur quelques machines et fait l’objet de tests peu fréquents. La version ajoute également HTTPS à l’interface web et à l’API. Les opérateurs peuvent ainsi modifier la manière dont ils exposent et consultent la surface d’administration, tout en gardant le service DNS lui-même distinct de la question de la protection de ses points d’accès administratifs. HTTPS constitue donc une amélioration pratique du déploiement, mais doit être évalué dans le cadre de la configuration de confiance environnante : les clients et les administrateurs doivent reconnaître le certificat utilisé par l’interface, et le guide de déploiement reste la référence pour la configuration prise en charge. Au-delà des fonctions mises en avant, la version 0.6.0 améliore la gestion des connexions chiffrées vers les serveurs en amont et les contrôles de disponibilité. Ensemble, ces changements facilitent l’intégration du service dans une topologie où la confidentialité des connexions amont et la disponibilité du service doivent toutes deux être observables. Ils ne suppriment pas la nécessité de tester le chemin réel du résolveur. La gestion des connexions chiffrées peut encore dépendre du point d’accès distant ou de la configuration locale, tandis que les signaux de disponibilité ne sont utiles que s’ils correspondent à l’état qui intéresse réellement l’opérateur. Il faut considérer cette version comme une étape concrète dans la direction actuelle du projet, et non comme la promesse que chaque élément de sa feuille de route étendue est déjà disponible. Le nommage des workloads Kubernetes, les tests de basculement, HTTPS, la gestion des connexions amont chiffrées et les améliorations des contrôles de disponibilité sont les changements décrits ici. Les autres fonctionnalités prévues ne doivent pas être considérées comme livrées simplement parce qu’elles s’inscrivent dans la conception générale du projet. Pour qui évalue TelltaleDNS, cette limite est utile : la version 0.6.0 peut être testée sur les comportements qu’elle offre aujourd’hui, tandis que la feuille de route reste un ensemble distinct d’attentes futures. ## Pourquoi l’architecture mixte Pi-Kubernetes compte Une configuration mêlant Raspberry Pi et Kubernetes fonctionne souvent très bien, jusqu’au moment où il faut diagnostiquer un problème. Le service DNS peut s’exécuter sur le Pi ou à proximité, tandis que les applications et les services qui les accompagnent vivent dans le cluster. Kubernetes dispose de sa propre couche de nommage et de découverte de services, CoreDNS assurant la résolution interne au cluster, alors que le reste du réseau domestique ou d’un petit bureau dépend du résolveur principal. Les tableaux de bord des appareils offrent encore une autre vue de l’environnement. Chaque composant peut être sain isolément, mais l’opérateur doit toujours reconstituer le chemin suivi par une requête donnée. Cette fragmentation compte, car les pannes DNS se manifestent rarement par une interruption nette d’un système unique. Un client peut atteindre les noms publics, mais échouer à résoudre un service interne. Une charge de travail peut être accessible depuis le cluster, mais pas depuis un appareil du réseau local. Un changement de nœud peut modifier l’endroit où une requête reçoit sa réponse ou le résolveur disponible, sans que la cause réelle apparaisse clairement dans une simple liste d’appareils. Dans un petit environnement, il n’y a pas forcément d’équipe de supervision distincte pour relier ces signaux. La personne qui administre le Pi, le résolveur et le cluster a besoin d’une vision opérationnelle qui franchisse ces frontières. TelltaleDNS 0.6.0 cherche à rendre cette vision plus cohérente. Son intégration à Kubernetes expose les charges de travail comme des appareils nommés dans l’interface et l’historique des requêtes. Ce détail modifie les questions qu’un opérateur peut poser. Au lieu de ne voir qu’une adresse ou une identité client opaque, l’enquête peut s’appuyer sur la charge de travail à l’origine de la requête. Une requête associée à une application Kubernetes peut être examinée avec celles de clients réseau ordinaires : le résolveur n’est plus observé comme s’il desservait deux univers sans rapport. La même logique s’applique aux vues des noms internes. Les noms utilisés dans le cluster et les recherches DNS inverses privées sont différents, sur le plan opérationnel, du trafic DNS public. Ils doivent pourtant s’inscrire dans la même démarche de dépannage lorsque le Pi et Kubernetes se partagent la responsabilité de la résolution des noms. Réunir ces vues dans un même plan de gestion peut faciliter la vérification : le problème se limite-t-il à un nom local au cluster, touche-t-il les recherches d’adresses privées ou concerne-t-il le trajet entre le cluster et le reste du réseau ? L’intérêt n’est pas que l’interface fasse disparaître les couches sous-jacentes ; elle fournit à l’opérateur un point commun pour en observer le comportement. Le routage tenant compte des nœuds ajoute une autre dimension utile. Dans un cluster, le chemin de réponse peut dépendre du nœud qui héberge une charge de travail ou traite une requête. Un résolveur capable de prendre cette relation en compte donne aux tests de basculement une cible plus concrète : l’opérateur peut examiner ce qui se produit lorsqu’un nœud donné devient indisponible, quels clients se déplacent et si le comportement obtenu correspond à la topologie prévue. C’est plus instructif que de vérifier uniquement qu’un processus DNS continue de fonctionner. La disponibilité est ainsi reliée aux charges de travail et aux clients qui dépendent de ce chemin. Cela concerne particulièrement les homelabs et les petites équipes d’exploitation, car l’objectif n’est généralement pas de construire une vaste plateforme abstraite de découverte de services. Il s’agit de garder un environnement modeste compréhensible à mesure qu’il s’agrandit. Un Raspberry Pi peut offrir un emplacement stable aux services réseau, tandis que Kubernetes fournit un cadre pratique pour les applications qui nécessitent des déploiements reproductibles et un nommage interne. Le défi opérationnel consiste à préserver une relation claire entre ces éléments. Les étiquettes de charges de travail de TelltaleDNS, la visibilité des noms internes et son comportement conscient des nœuds vont dans le sens de cette relation partagée, au lieu de traiter le cluster comme une boîte hermétique. La distinction entre visibilité et autorité reste toutefois importante. Un plan de gestion unique ne dispense pas de comprendre la topologie DNS réelle. Le guide de déploiement demeure la référence pour l’organisation des composants et l’ordre dans lequel effectuer les changements. Les opérateurs doivent utiliser l’interface pour observer et tester l’environnement, tout en s’appuyant sur le modèle de déploiement documenté pour décider où placer le résolveur, l’intégration au cluster et le trafic des clients. Cette séparation évite qu’un tableau de bord utile ne devienne un substitut aux connaissances de configuration. Cette version facilite aussi une évaluation sûre. L’architecture mixte devient particulièrement intéressante lorsqu’elle permet de répondre à des questions concrètes à la frontière entre les environnements : quelle charge de travail a effectué la requête ? Quel nœud était impliqué ? Le nom était-il local au cluster, privé ou externe ? Les clients se sont-ils déplacés comme prévu lorsqu’un nœud a été retiré du service ? Si ces questions trouvent une réponse dans un historique et une vue de gestion cohérents, un petit réseau combinant Raspberry Pi et Kubernetes devient plus facile à comprendre pendant les opérations de maintenance et les exercices de panne. Il ne s’agit pas de promettre que tous les problèmes DNS deviennent simples, mais de fournir une manière plus testable d’observer l’interaction entre les différents composants. ## Un plan de test raisonnable avant de modifier le DNS du réseau Considérez TelltaleDNS 0.6.0 comme une évaluation contrôlée, pas comme une raison de diriger immédiatement tous les clients vers un nouveau résolveur. Commencez avec la version balisée et conservez un résolveur connu comme fiable pendant toute la durée du test. Ce recours est important, car le DNS intervient dans le chemin utilisé pour accéder à presque tous les autres services : si le nouveau déploiement comporte une erreur de topologie, un certificat non approuvé ou un problème de nouvelle tentative vers l’amont, le retour en arrière doit passer par une modification de configuration volontaire, et non par une réparation improvisée. La première phase doit donc fonctionner en parallèle de l’organisation existante, en ne dirigeant vers TelltaleDNS qu’un petit groupe de clients sans caractère critique. Avant de modifier les paramètres des clients, documentez les noms auxquels le test doit répondre. Dans un environnement mêlant Raspberry Pi et Kubernetes, cela comprend l’espace `cluster.local` du cluster ainsi que les recherches inversées privées. Vérifiez où chaque catégorie de noms est censée être résolue et si le chemin de réponse dépend d’un nœud ou d’un serveur amont particulier. Il ne s’agit pas seulement de vérifier qu’un navigateur peut ouvrir un service familier. Un test utile doit montrer que les noms de workloads, les noms des appareils internes et les enregistrements inversés restent visibles et utilisables depuis les clients qui en ont réellement besoin. Gardez cette correspondance explicite : un résolveur peut sembler sain tout en envoyant discrètement une requête interne au mauvais endroit. HTTPS mérite un point de contrôle distinct. La version ajoute HTTPS à l’interface web et à l’API ; vérifiez donc la confiance accordée au certificat depuis les machines et les outils qui administreront ou surveilleront le service. Une page qui ne s’ouvre qu’après avoir ignoré un avertissement ne constitue pas un test opérationnel réussi ; la chaîne de certificats et les attentes concernant le nom d’hôte doivent fonctionner pour les clients de gestion prévus. Testez également l’API, et pas seulement l’interface du navigateur, car une voie d’automatisation peut échouer alors que le tableau de bord visible semble normal. Notez le point d’accès exact et les hypothèses de confiance utilisées pendant le test afin de pouvoir les reproduire après une mise à niveau ou une modification de la topologie. Une fois la résolution et l’administration de base opérationnelles, réalisez un exercice de basculement avec un groupe de clients sans caractère critique. Cette fonction est conçue pour arrêter volontairement certains nœuds pendant un intervalle choisi de 15 à 300 secondes, puis signaler les clients qui ont changé de chemin. Utilisez-la comme un exercice d’observation : identifiez les nœuds arrêtés, notez le comportement attendu des clients et vérifiez si ceux-ci continuent à résoudre les noms par le chemin disponible. Ne commencez pas avec l’ensemble du réseau. Un petit groupe de test permet de distinguer un transfert prévu d’une panne plus large due à une route incorrecte, à un paramètre client obsolète ou à une correspondance incomplète des noms internes. Pendant l’exercice, examinez davantage que le résultat final. L’historique des requêtes doit montrer ce que les clients ont demandé pendant l’indisponibilité des nœuds sélectionnés, et le rapport de basculement doit rendre visibles les déplacements des clients. Le comportement en matière de readiness constitue un autre signal important : vérifiez comment le service se présente avant et après l’interruption du nœud, au lieu de supposer qu’un processus en cours d’exécution équivaut à un résolveur prêt. Après l’exercice, rétablissez les nœuds sélectionnés et répétez suffisamment de vérifications côté client pour confirmer que le trafic revient vers le chemin attendu. Un test est réversible lorsque la panne comme la récupération peuvent être observées dans les journaux et dans le comportement réel des clients. La même approche par étapes s’applique à la gestion des serveurs amont chiffrés. Commencez par tester les requêtes ordinaires, puis observez le comportement du résolveur lorsqu’une connexion chiffrée vers un serveur amont doit être réessayée. Cherchez un rétablissement propre plutôt que de vous appuyer sur une seule requête réussie. L’objectif est de déterminer ce qui se passe en cas d’interruption, pas seulement de vérifier que le chiffrement peut être activé. Limitez le trafic de test et conservez le résolveur connu comme fiable jusqu’à ce que le comportement lors des nouvelles tentatives, les signaux de disponibilité, les journaux de requêtes et les résultats pour les noms internes soient tous compris. Ce n’est qu’après ces vérifications que le test doit être étendu à davantage de clients. Modifiez une seule dépendance à la fois, conservez une procédure de retour arrière documentée et comparez le comportement avec les schémas de trafic réels du réseau. Cela inclut les requêtes courantes des appareils, mais aussi les noms liés à Kubernetes et les requêtes inverses privées. Si un résultat surprend, rétablissez les clients concernés sur le résolveur connu comme fiable et isolez la cause avant d’élargir l’expérience. La version devient ainsi un outil opérationnel utile et testable, tout en tenant compte du fait qu’une modification DNS peut toucher l’ensemble de l’environnement en une seule fois. ## Limites, licence et alternatives TelltaleDNS 0.6.0 doit plutôt être considéré comme un projet testable que comme un remplacement finalisé d’une plateforme DNS établie. Le projet est encore en version pré-1.0 : les clés de configuration, les interfaces et les API peuvent donc évoluer. Cela concerne particulièrement les opérateurs qui souhaitent le placer devant un réseau puis ne plus y toucher : une mise à niveau peut nécessiter de vérifier les instructions de déploiement, de revoir la configuration et de confirmer que la vue de gestion représente toujours la même topologie de résolveurs. Cette version est utile parce qu’elle facilite l’inspection et la mise à l’épreuve d’un DNS mêlant Raspberry Pi et Kubernetes, mais cette utilité ne supprime pas le travail opérationnel associé à un service réseau central. Les notes de version signalent également une limitation DNSSEC précise qui doit faire partie de toute évaluation. En mode de validation, le démarrage peut échouer et produire `SERVFAIL` jusqu’à la mise en cache des clés nécessaires. Ce n’est pas un détail à découvrir pendant une migration étendue du réseau. Toute personne qui teste la validation DNSSEC devrait isoler le test, observer le comportement au démarrage et lors de la disponibilité, puis confirmer que les réponses reviennent comme prévu une fois le cache rempli. Un résolveur connu comme fiable doit rester disponible pendant cette vérification, et la procédure de retour arrière doit être assez simple pour être utilisée sans dépendre du bon fonctionnement du nouveau service. La distinction importante est celle entre une validation contrôlée de cette limite et l’hypothèse qu’une requête de base réussie prouve que tous les modes du résolveur sont prêts pour la production. La licence est relativement simple à examiner. Le dépôt contient à la fois `LICENSE-APACHE` et `LICENSE-MIT`, ce qui fournit au projet deux fichiers de licence à étudier avec les propres conditions du dépôt avant toute redistribution ou intégration dans un système plus vaste. La documentation du projet et les supports de publication avancent également des éléments concernant des images signées et une nomenclature logicielle. Ces éléments donnent des indications utiles sur la chaîne d’approvisionnement à l’opérateur qui décide comment tester et déployer le logiciel, mais ils ne remplacent pas la vérification de la source réelle de l’image, du processus de vérification de la signature, de la provenance de la compilation et du contenu de la SBOM dans l’environnement où le service fonctionnera. Ils doivent être considérés comme des éléments à vérifier, et non comme une conclusion générale sur la sécurité. TelltaleDNS occupe donc une position intermédiaire assez pratique pour les utilisateurs de Pi-hole ou de Technitium. Son évaluation est pertinente lorsque le problème concerne précisément un petit environnement mixte où l’infrastructure Raspberry Pi et les charges de travail Kubernetes doivent être observées dans une même vue opérationnelle, et où le comportement du basculement peut être testé avant toute modification. Il est moins raisonnable de considérer cette version comme un remplacement universel simplement parce qu’elle réunit dans un même projet la visibilité sur les charges de travail, les exercices de basculement, HTTPS et la gestion de serveurs amont chiffrés. Les résolveurs existants peuvent rester le meilleur choix lorsque leur comportement actuel, leur documentation, leurs intégrations ou leur stabilité correspondent déjà au réseau. Une décision prudente dépend donc du résultat du test par étapes, et pas seulement de la liste des fonctionnalités. Exécutez la version marquée, gardez le résolveur actuel à disposition, vérifiez les noms privés et ceux propres au cluster, contrôlez la confiance accordée aux certificats, inspectez le comportement des requêtes et de la disponibilité, puis répétez l’exercice de basculement avec des clients non critiques. Ajoutez ensuite le comportement au démarrage du mode de validation DNSSEC aux critères d’acceptation et consignez les modalités de rétablissement et de retour arrière. Si ces vérifications sont satisfaisantes, TelltaleDNS 0.6.0 peut constituer une expérimentation crédible pour un homelab ou un petit cluster. Dans le cas contraire, le statut pré-1.0 et la limite DNSSEC documentée donnent des raisons claires de reporter l’adoption tout en continuant à utiliser le service DNS existant.