{"schema_version":"1.0","service":"Publicasta","type":"article","id":946,"slug":"telltaledns_060_kubernetes_dns_failover_drills","title":"TelltaleDNS 0.6.0 makes mixed Raspberry Pi and Kubernetes DNS easier to test","excerpt":"TelltaleDNS 0.6.0 adds Kubernetes workload visibility, failover drills, and HTTPS for its web API. The release is worth testing for homelabs and small clusters, but its pre-1.0 status and DNSSEC caveat still rule out blind production adoption.","language":"en","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=en","image":{"url":"https://publicasta.com/storage/projects/10/pages/946/2026/10/2247bc95-4ecf-4e69-af99-5c32bd43e6ad.webp","alt":"Raspberry Pi and Kubernetes homelab equipment connected for a DNS failover drill"},"publisher":{"id":10,"slug":"open_source_radar","name":"Open Source Radar","url":"https://publicasta.com/open_source_radar"},"author":{"name":"Anton R"},"published_at":"2026-10-23T06:39:15+00:00","updated_at":"2026-10-23T06:39:15+00:00","content_markdown":"## What TelltaleDNS 0.6.0 actually changes\n\n ![Raspberry Pi and Kubernetes homelab equipment connected for a DNS failover drill](https://publicasta.com/storage/projects/10/pages/946/2026/10/2247bc95-4ecf-4e69-af99-5c32bd43e6ad.webp)\n\n TelltaleDNS 0.6.0, released on 20 October 2026, is focused less on adding another general-purpose DNS server than on making a mixed environment easier to observe and exercise. Its most visible change is Kubernetes awareness: workloads can appear as named devices in the web interface and in query history. That gives an operator a more useful answer to a familiar question— which client made a request—when the answer would otherwise be hidden behind cluster networking, shared resolver addresses, or infrastructure-level labels.\n\n That distinction matters because the release is about operational visibility as much as resolution. A dashboard entry that identifies a Kubernetes workload can be inspected alongside ordinary devices, making activity from a cluster easier to compare with requests from a Raspberry Pi, a workstation, or another network client. The feature does not turn every DNS problem into a simple one, but it reduces one layer of ambiguity: the operator has a named workload to investigate instead of only an address or an undifferentiated stream of queries.\n\n The second major addition is a built-in failover drill. TelltaleDNS can deliberately stop selected nodes for intervals from 15 to 300 seconds and then report which clients moved during the exercise. The important point is that this is a controlled test of behavior, not merely a status indicator. An installation may look healthy while all nodes are available, yet still fail when one disappears, when clients retain an old answer, or when routing does not move traffic as expected. A drill exposes that gap without requiring an operator to wait for an unplanned outage.\n\n The duration range also makes the test adjustable. A short interruption can show whether clients react promptly; a longer one can reveal whether fallback remains stable after the first retry cycle. The resulting report is intended to connect the failure event with client movement, so the operator can examine what actually changed rather than assuming that redundancy worked because a backup node existed. That makes the feature especially relevant for small installations where DNS is often assembled from a few machines and tested infrequently.\n\n The release also adds HTTPS for the web UI and API. This changes how operators can expose and access the management surface, while keeping the DNS service itself separate from the question of how its administrative endpoints are protected. HTTPS is therefore a practical deployment improvement, but it should be evaluated as part of the surrounding trust setup: clients and administrators need to recognize the certificate used by the interface, and the deployment guide remains the reference for the supported arrangement.\n\n Beyond the headline features, 0.6.0 improves handling for encrypted upstream connections and readiness checks. Together, those changes make the service easier to place in a topology where upstream privacy and service availability are both observable concerns. They do not remove the need to test the actual resolver path. Encrypted connection handling can still be affected by the remote endpoint or by local configuration, while readiness signals are useful only when they correspond to the state an operator actually cares about.\n\n The release should be read as a concrete step in the project’s current direction, not as a promise that every item on its broader roadmap is already available. Kubernetes workload naming, failover drills, HTTPS, encrypted-upstream handling, and readiness improvements are the changes described here. Other planned capabilities should not be treated as shipped merely because they fit the project’s overall design. For anyone evaluating TelltaleDNS, that boundary is useful: 0.6.0 can be tested for the behavior it provides today, while the roadmap remains a separate set of future expectations.\n\n ## Why the mixed Pi-and-Kubernetes design matters\n\n A mixed Raspberry Pi and Kubernetes setup often works well until something needs to be diagnosed. The DNS service may run on or near the Pi, while applications and their supporting services live inside the cluster. Kubernetes has its own naming and service-discovery layer, with CoreDNS handling cluster-internal resolution, while the rest of the home or small-office network depends on the main resolver. Device dashboards add another view of the environment. Each component can be healthy in isolation, yet an operator still has to reconstruct the path taken by a particular request.\n\n That fragmentation matters because DNS failures rarely present themselves as a clean, single-system outage. A client may reach public names but fail to resolve an internal service. A workload may be reachable from inside the cluster but not from a device on the local network. A node change can alter where a request is answered or which resolver is available, without making the underlying cause obvious from a general-purpose device list. In a small environment, there may be no separate monitoring team to connect those signals. The person maintaining the Pi, the resolver and the cluster needs an operational picture that crosses those boundaries.\n\n TelltaleDNS 0.6.0 is aimed at making that picture more coherent. Its Kubernetes integration exposes workloads as named devices in the interface and in query history. That detail changes the question an operator can ask. Instead of seeing only an address or an opaque client identity, the investigation can be framed around the workload that generated the request. A query associated with a Kubernetes application can be considered alongside requests from ordinary network clients, so the resolver is no longer observed as if it served two unrelated worlds.\n\n The same idea applies to internal-name views. Names used inside the cluster and private reverse lookups are operationally different from public DNS traffic, but they still belong in the same troubleshooting story when the Pi and Kubernetes share responsibility for name resolution. Bringing those views into one management plane can make it easier to check whether the problem is limited to a cluster-local name, affects private address lookups, or involves the route between the cluster and the rest of the network. The value is not that the interface eliminates the underlying layers; it gives the operator a common place to inspect their behavior.\n\n Node-aware routing adds another useful dimension. In a cluster, the answer path can depend on which node is serving a workload or handling a request. A resolver that can account for that relationship gives failover testing a more concrete target: the operator can examine what happens when a selected node is unavailable, which clients move, and whether the resulting behavior matches the intended topology. That is more informative than checking only whether a DNS process remains running. It connects availability to the workloads and clients that depend on the route.\n\n This is particularly relevant to homelabs and small operators because the goal is usually not to build a large, abstract service-discovery platform. The goal is to keep a modest environment understandable as it grows. A Raspberry Pi may provide a stable place for network services, while Kubernetes supplies a convenient home for applications that need repeatable deployment and internal naming. The operational challenge is preserving a clear relationship between those pieces. TelltaleDNS’s workload labels, internal-name visibility and node-aware behavior point toward that shared relationship rather than treating the cluster as a sealed box.\n\n The distinction between visibility and authority is important, however. A single management plane does not remove the need to understand the actual DNS topology. The deployment guide remains the authority for how the components should be arranged and for the order in which changes should be made. Operators should use the interface to observe and test the environment, while using the documented deployment model to decide where the resolver, cluster integration and client traffic belong. That separation keeps a useful dashboard from becoming a substitute for configuration knowledge.\n\n It also makes the new release easier to evaluate safely. The mixed design is most compelling when it answers practical questions across the boundary: Which workload made the request? Which node was involved? Was the name cluster-local, private or external? Did clients move as expected when a node was taken out of service? If those questions can be answered from a consistent history and management view, a small Pi-and-Kubernetes network becomes easier to reason about during maintenance and failure drills. The result is not a promise that every DNS problem becomes simple; it is a more testable way to see how the parts interact.\n\n ## A sensible test plan before changing network DNS\n\n Treat TelltaleDNS 0.6.0 as a controlled evaluation, not as a reason to point every client at a new resolver immediately. Start with the tagged release and keep a known-good resolver available throughout the test. That fallback matters because DNS is part of the path used to reach nearly every other service: if the new deployment has a topology mistake, an untrusted certificate, or an upstream retry problem, recovery should be a deliberate change of configuration rather than an improvised repair. The first pass should therefore run alongside the existing arrangement, with only a small, non-critical group of clients directed toward TelltaleDNS.\n\n Before changing client settings, document the names that the test must answer. In a mixed Raspberry Pi and Kubernetes environment, this includes the cluster’s `cluster.local` space as well as private reverse lookups. Check where each class of name is expected to be resolved and whether the response path depends on a particular node or upstream. The purpose is not merely to confirm that a browser can open a familiar service. A useful test should show that workload names, internal device names, and reverse records remain visible and usable from the clients that actually need them. Keep the mapping explicit, because a resolver can appear healthy while silently sending an internal query to the wrong place.\n\n HTTPS deserves its own checkpoint. The release adds HTTPS for the web UI and API, so verify certificate trust from the machines and tools that will administer or monitor the service. A page that opens only after bypassing a warning is not a successful operational test; the certificate chain and hostname expectations should work for the intended management clients. Test the API as well as the browser interface, since an automation path can fail even when the visible dashboard appears normal. Record the exact endpoint and trust assumptions used by the test so they can be reproduced after an upgrade or a topology change.\n\n Once basic resolution and administration are working, exercise a failover drill with a non-critical client group. The feature is designed to deliberately stop selected nodes for a chosen interval between 15 and 300 seconds and report which clients moved. Use that mechanism as an observation exercise: identify the nodes being stopped, note the expected client behavior, and watch whether those clients continue resolving names through the available path. Do not begin with the whole network. A small test group makes it possible to distinguish an intended handoff from a broader outage caused by an incorrect route, a stale client setting, or an incomplete internal-name mapping.\n\n During the drill, inspect more than the final result. Query history should show what clients asked for while the selected nodes were unavailable, and the failover report should make the client movement visible. Readiness behavior is another important signal: confirm how the service presents itself before and after the node interruption rather than assuming that a running process is equivalent to a ready resolver. After the drill, restore the selected nodes and repeat enough of the client checks to verify that traffic returns to the expected path. A reversible test is one where both the failure and the recovery can be seen in the logs and in real client behavior.\n\n The same staged approach applies to encrypted upstream handling. Test ordinary lookups first, then observe how the resolver behaves when an encrypted upstream connection must retry. Look for a clean recovery path rather than relying on a single successful query. The point is to establish what happens under interruption, not just to demonstrate that encryption can be enabled. Keep the test traffic narrow and retain the known-good resolver until the retry behavior, readiness signals, query logs, and internal-name results are all understood.\n\n Only after these checks should the test expand to more clients. Change one dependency at a time, preserve a documented rollback path, and compare behavior under the real traffic patterns the network produces. That includes routine device lookups as well as Kubernetes-related names and private reverse queries. If a result is surprising, return the affected clients to the known-good resolver and isolate the cause before widening the experiment. This makes the release useful as a testable operational tool while respecting the fact that DNS changes can affect the entire environment at once.\n\n ## Limits, licensing and alternatives\n\n TelltaleDNS 0.6.0 is best approached as a testable project rather than a finished replacement for an established DNS platform. It is still pre-1.0, so configuration keys, interfaces, and APIs may change as the project develops. That matters particularly for operators who want to place it in front of a network and then leave it untouched: an upgrade can require checking deployment instructions, reviewing configuration, and confirming that the management view still represents the same resolver topology. The release is useful because it makes mixed Raspberry Pi and Kubernetes DNS easier to inspect and exercise, but that usefulness does not remove the operational work around a core network service.\n\n The release notes also identify a specific DNSSEC limitation that should be part of any evaluation. In validate mode, startup can fail in a way that produces `SERVFAIL` until the required keys are cached. That is not a detail to discover during a broad network migration. Anyone testing DNSSEC validation should isolate the test, observe startup and readiness behavior, and confirm whether answers recover as expected after the cache is populated. A known-good resolver should remain available while this is checked, and the rollback path should be simple enough to use without depending on the new service being healthy. The important distinction is between a controlled validation of the caveat and assuming that a successful basic lookup proves every resolver mode is ready for production.\n\n Licensing is comparatively straightforward to inspect. The repository includes both `LICENSE-APACHE` and `LICENSE-MIT`, giving the project dual licensing files that should be reviewed alongside the repository’s own terms before redistribution or incorporation into a larger system. The project documentation and release material also make claims about signed images and a software bill of materials. Those are useful supply-chain signals for an operator deciding how to test and deploy the software, but they do not substitute for checking the actual image source, signature-verification process, build provenance, and the contents of the SBOM in the environment where the service will run. They should be treated as evidence to verify, not as a blanket security conclusion.\n\n That leaves TelltaleDNS in a practical middle ground for users of Pi-hole or Technitium. It is reasonable to evaluate when the problem is specifically a small, mixed environment where Raspberry Pi infrastructure and Kubernetes workloads need one operational picture, and where failover behavior can be exercised before a change is made. It is less reasonable to treat the release as a universal replacement simply because it offers workload visibility, drills, HTTPS, and encrypted-upstream handling in one project. Existing resolvers may remain the better choice when their current behavior, documentation, integrations, or stability already fit the network.\n\n A careful decision therefore depends on the result of the staged test, not on the feature list alone. Run the tagged release, keep the current resolver available, check private and cluster-local names, verify certificate trust, inspect query and readiness behavior, and repeat the failover exercise with non-critical clients. Then include the DNSSEC validate-mode startup behavior in the acceptance criteria and record how recovery and rollback work. If those checks are satisfactory, TelltaleDNS 0.6.0 can be a credible experiment for a homelab or small cluster. If they are not, the pre-1.0 status and the documented DNSSEC caveat provide clear reasons to postpone adoption while continuing to use the existing DNS service.","available_translations":[{"language":"ar","title":"يجعل TelltaleDNS 0.6.0 اختبار DNS المختلط بين Raspberry Pi وKubernetes أسهل","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","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=ar"},{"language":"de","title":"TelltaleDNS 0.6.0 erleichtert Tests für gemischte DNS-Umgebungen mit Raspberry Pi und Kubernetes","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","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=de"},{"language":"en","title":"TelltaleDNS 0.6.0 makes mixed Raspberry Pi and Kubernetes DNS easier to test","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","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=en"},{"language":"es","title":"TelltaleDNS 0.6.0 facilita las pruebas de DNS en entornos mixtos con Raspberry Pi y Kubernetes","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","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=es"},{"language":"fr","title":"TelltaleDNS 0.6.0 simplifie les tests DNS mixtes sur Raspberry Pi et Kubernetes","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","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=fr"},{"language":"pl","title":"TelltaleDNS 0.6.0 ułatwia testowanie DNS-u w mieszanych środowiskach Raspberry Pi i Kubernetes","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","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=pl"},{"language":"ru","title":"TelltaleDNS 0.6.0 упрощает тестирование DNS в смешанных средах Raspberry Pi и Kubernetes","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","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=ru"},{"language":"zh","title":"TelltaleDNS 0.6.0 让混合 Raspberry Pi 与 Kubernetes 的 DNS 更易测试","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","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=zh"}],"_links":{"self":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=en","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/telltaledns_060_kubernetes_dns_failover_drills?lang=en","html":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=en","canonical":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills?lang=en","markdown":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.md?lang=en","json":"https://publicasta.com/open_source_radar/telltaledns_060_kubernetes_dns_failover_drills.json?lang=en","channel":"https://publicasta.com/api/public/v1/channels/open_source_radar","channel_articles":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}