Gradle Dependency Resolution ↔ JVM Networking Stack: DNS and TLS error visibility at the integration boundary

Goal is to clarify how DNS resolution failures and TLS certificate validation errors from remote Maven repositories surface in Gradle builds and what control Gradle exposes at the integration boundary between Gradle dependency resolution and the JVM networking stack used by the daemon.

Gradle delegates HTTP/S transport for dependency resolution to the JVM networking libraries used by the Gradle daemon. Certificate validation for HTTPS repositories uses the JVM truststore configured for the daemon process, and Gradle does not provide a first-class DSL to override trust material per repository without JVM arguments or system properties. DNS-related timeouts, retries and caching are governed by JVM and OS resolver settings rather than Gradle DSL properties. Behavior is JVM version and Gradle version sensitive, and daemon reuse can mask transient DNS changes and truststore updates.

What is the intended transparency model for JVM networking errors at this boundary? Does Gradle intend to remain transparent to underlying DNS vs TLS failures or surface them with distinct actionable messages? What is the supported integration boundary for controlling trust material and resolver behavior per repository without global JVM properties? How should build reproducibility be reasoned about when resolution failures depend on external resolver and truststore state?