Gate `hickory-dns` reqwest feature behind an opt-in feature flag

[liuchengxu]

Summary

helios-core, helios-ethereum, and helios-verifiable-api-client consume reqwest from the workspace with the hickory-dns feature hardcoded:

https://github.com/a16z/helios/blob/v0.11.1/Cargo.toml#L71

reqwest = { version = "0.12.4", features = [..., "hickory-dns", ...] }

Crates inherit this with reqwest.workspace = true and no per-crate feature override:

• helios-core/Cargo.toml:22
• helios-ethereum/Cargo.toml:24
• helios-verifiable-api/client/Cargo.toml:11

This forces every Helios consumer to pull hickory-resolver / hickory-proto transitively, with no way to opt out from the consumer's manifest.

Why this matters

The currently resolved Hickory stack is affected by RUSTSEC-2026-0119 — a medium-severity O(n²) CPU-exhaustion issue in hickory-proto 0.25.x. An attacker with DNS-position influence over a Helios-configured RPC domain (BGP hijack, DNS-zone takeover, on-path) can trigger CPU exhaustion in the resolver, stalling Helios-driven request paths.

The recommended fix per the advisory is to bump hickory-proto to >=0.26.1. Consumers can't currently do that downstream:

• [patch.crates-io] to hickory-proto 0.26.x is not semver-compatible because hickory-resolver 0.25.2 requires hickory-proto = "0.25" (hickory-resolver-0.25.2/Cargo.toml:191).
• Helios's workspace-level feature set can't be overridden from the consumer's Cargo.toml.

The realistic path forward is to either:

1. Move hickory-dns behind an opt-in feature flag exposed by Helios crates (e.g. helios-core/hickory-dns), so consumers can opt out and fall back to reqwest's default system resolver, or
2. Bump Helios's workspace reqwest to a version whose hickory-resolver / hickory-proto are at the fixed 0.26.x line.

(1) is the cleaner change because it gives downstream control without committing Helios to a specific Hickory release cadence.

Context

This was surfaced during a third-party security audit of a Helios-based prover service. Downstream impact: even with the service bound to localhost, an attacker controlling DNS for the configured execution / consensus RPC domains can cause prover CPU exhaustion via Helios's resolver path.

We're not blocked on a fix — we can wait for upstream — but a feature flag would let any operator opt out today and pick up RUSTSEC-2026-0119 mitigations at their own pace.

Suggested change

Workspace Cargo.toml:

-reqwest = { version = "0.12.4", features = [..., "hickory-dns", ...] }
+reqwest = { version = "0.12.4", features = [..., ...] }  # hickory-dns removed

Per-crate (example for helios-core/Cargo.toml):

[features]
default = []
hickory-dns = ["reqwest/hickory-dns"]

Happy to send a PR if this direction looks right.

References

• RUSTSEC-2026-0119: https://rustsec.org/advisories/RUSTSEC-2026-0119

[HusseinAdeiza]

Agreed, and I'd rather you sent it than me — you did the analysis and know the downstream constraints better than I can from the outside. Flagging only that this is still open with no PR after three months, in case it fell off anyone's radar.

One thing worth checking against master before you write it: Cargo.toml:71 is still reqwest = { version = "0.12.4", features = [..., "hickory-dns"] } at 21b6d56, so the analysis still holds.

If you'd rather I take it, say so and I'll do the per-crate feature wiring plus a check that the default build still compiles without the flag. Otherwise I'll stay out of the way.

[liuchengxu]

Hey @HusseinAdeiza I have submitted #842, please have a look.

[HusseinAdeiza]

Reviewed on #842. The approach is right and the security argument checks out, including the part that forces a workspace-level fix: reqwest 0.12.22 pins hickory-resolver ^0.24, 0.12.24+ moved to ^0.25, and hickory-resolver 0.25 needs hickory-proto ^0.25, so 0.26.1 is out of reach for a downstream [patch].

Two gaps in the PR, both about not breaking existing users rather than about the resolver choice:

1. verifiable-api-server got no [features] block, so the released verifiable-api-server binary silently moves to the system resolver with no way to opt back in. opstack-server is fine, it is a [[bin]] inside helios-opstack which does have the feature.

2. CI never compiles the feature-off build, because cli enables the feature and unifies it across every workspace job. The default path for all library consumers is untested.

Details and a suggested CI job in the review.