Zig DNS Resolver and TLS Client: Automatic Hostname Propagation for SNI and Verification
0 reputation · 29 Apr 2022, 13:25 UTC
0 reputation · 29 Apr 2022, 13:25 UTC
When developing a network client in Zig, a programmer typically resolves a hostname with std.net.DNSLookup and then establishes a TLS connection using std.tls.connect. The DNS resolver returns the IP address but does not automatically supply the resolved host name to the TLS layer for SNI or certificate hostname verification. The application must manually pass the same host string to std.tls.TLSContext and set the verifyHostname flag to enable validation. This separation creates a potential mismatch and leaves secure defaults to the caller, which is currently under discussion in the Zig repository.
verifyHostname default to true when a TLS context is created after a DNS lookup?35275 reputation · 30 Apr 2022, 00:37 UTC
The Zig standard library deliberately separates DNS resolution from TLS configuration. std.net.DNSLookup returns only IP addresses, and std.tls.connect requires the caller to supply the hostname for SNI and to set verifyHostname. Making the resolver automatically feed the hostname into the TLS layer would hide dependencies, break code that connects via raw IP addresses or uses custom SNI values, and contradicts the current design consensus in the Zig repository.
std.net.DNSLookup discards the original hostname after resolving to std.net.Address.std.tls.TLSContext has fields server_name (SNI) and verify_hostname; both default to empty/false.const addr = try std.net.DNSLookup.lookup(&allocator, "example.com", .default);const hostname = "example.com";).std.tls.TLSContext, set .server_name = hostname and .verify_hostname = true (after configuring a trusted CA store).std.tls.connect with the resolved address and the TLS context.To avoid repeating the manual steps, a convenience wrapper could be added (e.g., std.net.tlsConnectHostname) that:
server_name and verify_hostname = true,Such a wrapper would live in std.net or a higher‑level client module, leaving the low‑level DNSLookup and TLSContext unchanged so existing code continues to work unchanged.
Use comments to ask for clarification. Post a solution as an answer.
5,790 reputation · 29 Apr 2022, 15:18 UTC
DNSLookup currently returns only address data; the original query name is not retained in the result, so there is no hostname to propagate automatically to TLS without changing the resolver API.
That means automatic SNI and verification would require a new resolver return type or a higher-level connect helper that keeps the name alongside the addresses, rather than toggling defaults on TLSContext alone.
Version assumptions apply: std.net and TLS options have moved across Zig releases, so check zig version and the std source for server_name and verifyHostname before relying on defaults.