fix(dns): dns service must point names at the local proxy - #466
Merged
Conversation
`dns enable` probes for the pinned-TLS proxy and passes it to the daemon, so Moshpit names answer on loopback and TLS terminates somewhere the local root covers. `dns service` — added in v0.78.0 — never did, so the unit it wrote started a bridge that answered every name with its origin. The origin serves a certificate no CA signed, which is the whole reason the proxy exists. So on a machine with the proxy installed, trusted and running, every https:// URL still failed, and the supervised bridge that v0.78.0 told people to use was the one way to run Moshpit where HTTPS could not work at all. The name resolved, curl said "self-signed certificate", and nothing in the output connected the two. `dns service` now runs the same probe `enable` does, at generation time — while this command can still ask — and bakes `--proxy` into ExecStart. The unit runs at boot and has no way to find out later. When no proxy is found it says so, and says what that means for https://, rather than writing a unit that resolves names and cannot serve them. `--no-proxy` skips the probe. An origin has nginx on 443 and correctly finds nothing: pointing names at loopback there would hand them to a web server that never heard of them. Four tests: the flag is written for v4 and v6, absent rather than empty when there is no proxy, and does not collide with --upstream. Suite: 2730 tests, 0 failures. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ThnQwoieWt8VR6N7gtgnhp
ThreatCrush Security Scan1 finding(s) in the 3 file(s) this pull request changes. HIGH/CRITICAL: 1
90 pre-existing finding(s) elsewhere in the repository — **HIGH/CRITICAL**: 7 | **MEDIUM**: 73 | **LOW**: 10Not introduced by this pull request. The full set is in the Security tab.
…and 70 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
Merged
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
1 participant
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.
dns enableprobes for the pinned-TLS proxy and passes it to the daemon, so Moshpit names answer on loopback and TLS terminates somewhere the local root covers.dns service— added in v0.78.0 — never did, so the unit it wrote started a bridge that answered every name with its origin.The origin serves a certificate no CA signed, which is the entire reason the proxy exists. So on a machine with the proxy installed, trusted and running, every
https://URL still failed — and the supervised bridge v0.78.0 told people to use was the one way to run Moshpit where HTTPS could never work. The name resolved, curl saidself-signed certificate, and nothing in the output connected the two.The fix
dns servicenow runs the same probeenabledoes, at generation time — while the command can still ask — and bakes--proxyintoExecStart. The unit runs at boot and has no way to find out later.When no proxy is found it says so, and says what that means for
https://, rather than writing a unit that resolves names it cannot serve.--no-proxyskips the probe. An origin (nginx on 443) correctly finds nothing — pointing names at loopback there would hand them to a web server that never heard of them.Tests
Four added: the flag is written for v4 and v6, absent rather than empty when there's no proxy, and doesn't collide with
--upstream.Verified on this box, which is an origin: it reports no proxy found and omits the flag, which is the correct branch here.
Suite: 2730 tests, 0 failures.
🤖 Generated with Claude Code
https://claude.ai/code/session_01ThnQwoieWt8VR6N7gtgnhp