config: accept hostname for [domain-fronting] target#480
config: accept hostname for [domain-fronting] target#480dolonet wants to merge 4 commits into9seconds:masterfrom
Conversation
The existing `[domain-fronting].ip` only accepts a literal IP. That forces SNI-router setups to pin a static container address (and a static docker subnet) so mtg can dial the fronting backend directly instead of resolving the secret's hostname via DNS, which would loop back into mtg through the SNI router. Add a sibling `[domain-fronting].host` that accepts either a hostname or an IP. Hostnames are resolved at dial time by the native dialer (Happy Eyeballs / dual-stack), so a docker-DNS or any A+AAAA record naturally picks the right backend address family per client. Setting both `host` and `ip` is rejected at validation. The mtglib API stays backward compatible: ProxyOpts.DomainFrontingIP is still a plain string and the dial path already calls JoinHostPort + DialContext, both of which accept hostnames. Only the doc comment was clarified.
Follow-up to the previous commit on this branch: - Rename Config.GetDomainFrontingIP -> GetDomainFrontingHost. The helper now returns a hostname or an IP, so the old name was a lie. Drop the unused defaultValue net.IP parameter (every caller passed nil). Update internal/cli/run_proxy.go and internal/cli/doctor.go; rename the misleading `ip` local var in doctor.go to `override`. - Add TOML fixtures (domain_fronting_host.toml, domain_fronting_ip.toml) so the new field is exercised through the actual Parse()->JSON->Config path users hit, not just via direct .Set() calls. Plus a positive backward-compat test confirming an `ip`-only legacy config still validates and resolves correctly, and a no-fronting test confirming the unset case returns empty. - Clarify example.config.toml: `ip` is kept for backward compatibility, not because it has stricter validation semantics worth choosing over `host`. mtglib.ProxyOpts.DomainFrontingIP keeps its name (public API).
|
A few open questions worth deciding before merge — happy to do either branch: 1. Additive vs. rename-with-deprecation. This PR adds 2. 3. Mutual-exclusion scope. The current check rejects |
- mtglib/proxy.go: rename private field domainFrontingIP -> domainFrontingHost
and update DomainFrontingAddress() doc comment to reflect that hostnames
are now accepted. The exported mtglib.ProxyOpts.DomainFrontingIP is
unchanged (public API), so the assignment in NewProxy now reads
`domainFrontingHost: opts.DomainFrontingIP,` which makes the
public-vs-internal naming explicitly visible at the boundary.
- internal/config/{parse,config}.go: reorder so Host comes before IP in
the [domain-fronting] struct. Cosmetic, but signals Host is the
preferred forward path.
- Add TestDomainFrontingHostAcceptsLiteralIP + domain_fronting_host_ip.toml
fixture exercising the documented "host accepts hostname or literal IP"
contract end-to-end.
1 participant
Summary
Today
[domain-fronting].iponly accepts a literal IP (TypeIP→net.ParseIP). When mtg sits behind an SNI router (HAProxy, etc.)whose DNS for the secret's hostname points back at the same host,
mtg's default fronting behaviour resolves that hostname and dials
itself, looping. Working around this in deployment requires pinning a
static docker container IP and subnet so the literal-IP field can
target the fronting backend directly.
This adds a sibling
[domain-fronting].hostfield that accepts eithera hostname or an IP. Hostnames are resolved at dial time by the native
dialer (which already handles dual-stack / Happy Eyeballs), so an A+AAAA
docker-DNS or normal DNS record reaches the right backend address
family for IPv4 and IPv6 clients without a static pin.
ipsemantics are unchanged. Setting bothhostandipis rejectedin
Validate().API stability
mtglib.ProxyOpts.DomainFrontingIPis still a plainstring. Thedial path already passes it to
net.JoinHostPort+DialContext,both of which accept hostnames. Only the field's doc comment was
clarified — no signature change, no new public symbols in
mtglib.internal/cli/run_proxy.go,simple_run.goanddoctor.goallcontinue to work via the existing
Config.GetDomainFrontingIP()helper, which now prefers
HostoverIPover the legacy flatdomain-fronting-ip.What's added
internal/config/type_host.go—TypeHost(accepts hostname or IP,rejects empty,
host:port, URLs, whitespace).internal/config/type_host_test.go— Get / UnmarshalOk / UnmarshalFail.internal/config/config_test.go—TestDomainFrontingHostOrIPcovering precedence and mutual-exclusion.
[domain-fronting]section ofexample.config.tomlupdated todocument
hostalongsideip.Motivation
Direct follow-up to a review thread on #478, which currently works
around the literal-IP restriction with a pinned docker subnet. Once
this lands, that PR collapses to ~3 lines (
host = "web") and itsIPv6 PROXY-protocol-family caveat goes away.
Test plan
go build ./...go vet ./...go test ./...— full suite greenTypeHosttests pass (5 accept, 5 reject)TestDomainFrontingHostOrIPcovers Validate() rejection of both-set and Host-wins precedence