Behavior: DNS resolver search list and options handling in k6 without --dns

Short answer

When --dns is omitted, k6 performs hostname lookups through Go's resolver, which on Linux reads /etc/resolv.conf — including the search list and options like rotate and timeout. So in the common case, yes: short hostnames that rely on a search suffix will resolve, and resolver options are read. The important caveats are (1) k6's per-VU DNS cache can mask rotation and mid-test changes, and (2) the exact resolution path depends on whether Go uses its pure-Go resolver or cgo, which varies with build and environment.

Likely explanation vs. confirmed facts

Confirmed, well-established behavior:

• k6 is written in Go. Go's net package on Linux parses /etc/resolv.conf itself when using the built-in (pure Go) resolver, honoring nameserver, search/domain, and options such as timeout, attempts, and rotate.
• k6 caches DNS results per VU for the VU's lifetime. A lookup that succeeded once for a hostname will be reused by that VU, so rotate round-robin effects are largely invisible within a single VU's iterations.
• Setting --dns (or the older per-run DNS config) overrides this path entirely with k6's own resolver configuration.

Likely, but not fully verified:

• Whether the pure-Go or cgo resolver is used depends on the build. Officially distributed k6 binaries are typically built in a way that favors the pure-Go resolver; locally built or statically linked variants may differ. With cgo, glibc's resolver applies, and behavior follows the C library instead.
• Reports that v0.44 changed DNS handling are plausible — k6 has reworked its DNS resolution code around that era — but the precise behavioral delta (search list application, option parsing) is not something I can confirm from documentation here. Treat version-specific claims as requiring empirical verification.

Why distributions differ

Distributions manage /etc/resolv.conf differently: NetworkManager or systemd-resolved may point it at a local stub (127.0.0.53), containers often get a synthesized file, and Alpine (musl) has its own resolver semantics — notably, musl historically ignores some options and queries nameservers in parallel rather than honoring rotate. If k6 runs with cgo on musl, option handling follows musl, not glibc. Inside Docker, the file is bind-mounted from the daemon's config, so the host's search list may not appear at all.

How to verify on your setup

Because caching hides per-lookup behavior, observe the wire rather than the script output:

# Watch which nameserver is queried and with what name
sudo tcpdump -i any -n port 53 &
k6 run script.js   # no --dns flag

Useful checks:

1. Search list: request a short hostname (e.g., http.get("http://myservice/")) and confirm in the capture that queries for myservice.<suffix> are attempted in search-list order.
2. rotate: with two nameservers listed, run several short tests (fresh VUs each time) and check whether queries alternate between servers. Within one long-running VU you will not see rotation due to caching.
3. timeout: point nameserver at a non-responsive address and measure time-to-failure with and without options timeout:1.
4. Resolver choice: GODEBUG=netdns=2 k6 run script.js makes Go log which resolver it selected and what it parsed from resolv.conf — the most direct way to settle the question for your binary.

Practical recommendation

If your test depends on a specific search suffix or deterministic nameserver behavior, don't rely on ambient resolv.conf state — use fully qualified names in the script, or pin resolution explicitly with --dns. If you need DNS changes picked up mid-test, be aware the per-VU cache prevents that regardless of resolver options.

One missing detail that would change this answer: whether you're running an official k6 release binary or a custom/xk6 build, since that determines the Go-vs-cgo resolver path. Version-specific differences around v0.44 should be treated as unverified until tested with the GODEBUG method above.