reverseproxy: move DNS SRV+A discovery into modules/internal/network

[tannevaled]

What

Reverse proxy's dynamic-upstream DNS discovery (SRV and A/AAAA resolution, with caching/refresh/grace) was duplicated between SRVUpstreams and AUpstreams, and is the kind of logic third-party proxies want to reuse. This extracts it into a single shared place and refactors reverse_proxy to consume it (behavior unchanged).

Placement (per review)

Following @francislavoie's feedback, this is not a top-level package — it's internal helper code, not part of Caddy's runtime surface. It now lives in the existing modules/internal/network package, alongside the other shared network helper there. reverse_proxy's upstreams.go calls network.SRV(...) / network.A(...).

Because it's under modules/internal, third-party modules (e.g. layer4) can't import it yet, so they keep their own copy for now; they can switch over once layer4 is part of Caddy's standard distribution.

Changes

• modules/internal/network/dynamicupstreams.go: transport-neutral Target + SRV(...) / A(...) with the existing caching/refresh/grace semantics, plus ResetSRV / ResetAllSRV.
• modules/caddyhttp/reverseproxy/upstreams.go: SRVUpstreams/AUpstreams delegate to the shared functions (−177 lines of duplicated logic).
• Tests for the shared package (resolve/cache/grace/reset, cache bounding, filtered-record handling, concurrent-refresh dedup under -race).

No change to reverse_proxy's Caddyfile/JSON surface or behavior.

[CLAassistant]

All committers have signed the CLA.

[francislavoie]

I don't think it should be a top-level package/directory, it has nothing to do with Caddy as a runtime specifically. We typically put things in modules/ but it's not really a module in of itself, instead moreso being some shared library code.

I would say this would end up becoming a package in internal long-term, with the assumption that layer4 ends up being moved into Caddy's standard distribution, which would make it allowed to use internal.

So I'm thinking we can probably just put it in modules/internal/network for now, it's a useful refactor, but layer4 won't be able to use this until later, so it'll need to use a copy for the time being.

[tannevaled]

Thanks, that placement makes sense. Done: I moved it out of the top-level package into the existing modules/internal/network package, and reverse_proxy's upstreams.go now calls network.SRV(...) / network.A(...). Title/description updated to match.

Agreed that being under modules/internal means layer4 can't import it yet, so it keeps its copy for the time being — switching it over once layer4 is part of the standard distribution. So this PR is now purely the in-tree dedup of reverse_proxy's SRV/A discovery (behavior unchanged, −177 lines), with tests for the shared package. No rush on review.

[vnxme]

So I'm thinking we can probably just put it in modules/internal/network for now, it's a useful refactor, but layer4 won't be able to use this until later, so it'll need to use a copy for the time being.

@francislavoie, is it possible we find an exportable place in the mainline code, so that the layer4 app could easily reuse this code before it gets merged? Same as you, I suggest we find a solution to avoid duplicating things.

[tannevaled]

Happy to go whichever way you two prefer — it's a one-line move for me.

One option that threads both concerns: keep it under modules/ (not a top-level package, per @francislavoie) but exported rather than internal — i.e. modules/network instead of modules/internal/network. That lets the layer4 app import it and drop its copy today, while not adding anything to Caddy's top-level surface. The tradeoff is that it does become part of the importable API a bit earlier than the "wait until layer4 is in-tree" plan.

If you'd rather keep it internal for now, that's fine too and I'll leave it as-is. Just let me know where you land and I'll adjust the package path (and wire caddy-l4 to it if we go exported).

[francislavoie]

Thing is, it's not really a module, so that's my reticence here.

I'd like to see l4 moved into Caddy sooner rather than later but I'm not actively maintaining this project

[vnxme]

I don't insist on moving the code into a new module either. Do you mind if we simply make some relevant types and functions exportable and reusable while keeping them within the reverseproxy module?