[TRIVIAL] Enable reqwest's async DNS resolution (hickory-dns)

[jmg-duarte]

reqwest's DNS resolution is blocking by default, using getaddrinfo from the OS, when the DNS resolution is slow, this leads to increased latency in services (especially the autopilot), the async resolution allows reqwest to play nicer with tokio

Enabling the feature will enable hickory by default:
https://github.com/seanmonstar/reqwest/blob/ea3d9ca6877620aa571cd67246c0c37a09fdd2e8/src/async_impl/client.rs#L369

The previous OTel reqwest unification allows everything on our stack that depends on reqwest to take advantage of the async DNS

Additionally, it bumps reqwest because 0.13.2 would depend on a vulnerable version of hickory (see GHSA-3v94-mw7p-v465 and GHSA-q2qq-hmj6-3wpp)

[claude]

Claude finished @jmg-duarte's task in 1m 23s —— View job

---

PR Review: Enable async DNS resolution (hickory-dns)

• Reviewed Cargo.toml feature change
• Reviewed Cargo.lock dependency additions
• Checked feature propagation across crates

Verdict: LGTM — small, well-scoped, low-risk change.

The hickory-dns feature on the workspace reqwest dependency switches reqwest's default resolver to the async hickory resolver, which avoids the blocking getaddrinfo calls that can stall the tokio runtime under slow DNS. Thanks to Cargo feature unification, this applies to all reqwest consumers in the graph (including the contracts crate that pins reqwest directly rather than via workspace), so the win is global as the description intends.

The Cargo.lock additions (hickory-resolver/hickory-proto, resolv-conf, ipconfig, enum-as-inner, and the critical-section/portable-atomic features pulled onto once_cell) are the expected transitive deps and look correct.

One non-blocking behavioral note posted inline re: in-process DNS caching / resolv.conf being read once for long-lived clients — worth a sanity check on prod metrics after rollout, but no change requested.

[gemini-code-assist]

Code Review

This pull request enables the hickory-dns feature for the reqwest dependency in Cargo.toml, updating Cargo.lock with the necessary transitive dependencies including hickory-resolver and hickory-proto. No critical issues were found, and there is no feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[claude]

Worth being aware of one behavioral difference vs. the OS getaddrinfo path: the hickory resolver reads /etc/resolv.conf once at client construction and then caches DNS records in-process per their TTL (via moka). Long-lived clients (e.g. the autopilot's, which are built once at startup) will therefore not pick up resolv.conf changes for the process lifetime, and will honor record TTLs for cache expiry rather than re-resolving every call the way glibc does.

In k8s this is almost always fine (and is largely the point of the change), but it's the kind of difference that can surface as stale upstream IPs after a backend redeploy if a record has a very long/absent TTL. Might be worth a quick sanity check in prod after rollout that connection-error/latency metrics look healthy.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	reqwest@​0.13.4

View full report

[AryanGodara]

Had to read up a bit on hickory 😅 , but LGTM 👌🏼