Repository navigation
fix(local-ca): forward unlisted base-domain names in the CoreDNS custom zone - #144
Merged
Merged
Conversation
…om zone The coredns-custom server block for the base domain answered the listed app hosts from the hosts plugin and fell through to nothing, so CoreDNS returned SERVFAIL for every other name in the zone. A new ingress host could not resolve inside the cluster, and an ACME HTTP-01 self-check for it stayed pending until someone added the host to the list by hand. Forward unanswered names to the node's resolvers, the same upstream as the k3s main server block. Add a static test that confines its checks to the base-domain block and requires the forward there, after the hosts block, with /etc/resolv.conf as its upstream, and run it in CI. Closes dmfdeploy/dmfdeploy#894 Signed-off-by: znerol2 <6800371+znerol2@users.noreply.github.com>
lkirc
approved these changes
Nov 12, 2026
lkirc
left a comment
lkirc
left a comment
There was a problem hiding this comment.
Static review complete. The base-domain forward correctly follows the hosts fallthrough, and the scoped regression test and CI step cover it without changing workflow permissions or triggers. Current head, required checks, and the exact ntfy OK token were verified.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
In the local-CA lane, playbook 321 adds a CoreDNS server block for the base domain. Its
hostsblock answers the listed app hosts and ends infallthrough, but nothing followed it, so CoreDNS answered SERVFAIL for every other name in the zone. A new ingress host couldn't resolve inside the cluster, and cert-manager's HTTP-01 self-check for it stayed pending until someone added the host by hand.This adds
forward . /etc/resolv.confafter thehostsblock, the same upstream the k3s main server block uses. Listed hosts keep their in-cluster addresses.cacheis left out, so a newly added host isn't held back by a cached negative answer.Tests
tests/test_coredns_custom_zone.py, run by a new CI step. It confines its checks to the base-domain server block and requires aforwardthere, after thehostsblock and outside it, with/etc/resolv.confas the upstream. It fails on main.hosts, only in a separate server block, with a different upstream, with an extra upstream, commented out, or removed.Live check (sandbox env)
failed=0, CoreDNS restarted and ready.One side note from the live run: the workstation inventory maps the app hosts to the node's public address, while the env was first built with its private address. Pods reach the apps either way. The playbook follows whichever inventory runs it.
Closes dmfdeploy/dmfdeploy#894