Random segfault, trying to set "netdns=go"

This isn't a bazel problem, but I'm unsure how to trace the issue.

How would you go about setting netdns=go? Is that what the `pure flag is for?

I'm experiencing a random segfault in production. There's no specific point when it happens, it's completely random, as far as I can tell.

fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x15 pc=0x7fe189e40618]

runtime stack:
runtime.throw(0xfab41a, 0x2a)
	GOROOT/src/runtime/panic.go:608 +0x72
runtime.sigpanic()
	GOROOT/src/runtime/signal_unix.go:374 +0x2f2

goroutine 51 [syscall]:
runtime.cgocall(0xc85980, 0xc000287600, 0x29)
	GOROOT/src/runtime/cgocall.go:128 +0x5e fp=0xc0002875c8 sp=0xc000287590 pc=0x403b7e
net._C2func_getaddrinfo(0xc000236cc0, 0x0, 0xc000223440, 0xc0002280c0, 0x0, 0x0, 0x0)
	_cgo_gotypes.go:92 +0x55 fp=0xc000287600 sp=0xc0002875c8 pc=0x64b0d5
net.cgoLookupIPCNAME.func1(0xc000236cc0, 0x0, 0xc000223440, 0xc0002280c0, 0x2c, 0x2c, 0xc0002206c0)
	GOROOT/src/net/cgo_unix.go:149 +0x131 fp=0xc000287648 sp=0xc000287600 pc=0x6507f1
net.cgoLookupIPCNAME(0xc000236b10, 0x2b, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
	GOROOT/src/net/cgo_unix.go:149 +0x153 fp=0xc000287738 sp=0xc000287648 pc=0x64c693
net.cgoIPLookup(0xc0003748a0, 0xc000236b10, 0x2b)
	GOROOT/src/net/cgo_unix.go:201 +0x4d fp=0xc0002877c8 sp=0xc000287738 pc=0x64cd4d
runtime.goexit()
	GOROOT/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc0002877d0 sp=0xc0002877c8 pc=0x45a2e1
created by net.cgoLookupIP
	GOROOT/src/net/cgo_unix.go:211 +0xad

I can't reproduce it locally, only in prod. I'm trying to test different variations of the build with Bazel.

go_binary(
    name = "binary",
    embed = [":go_default_library"],
    static = "on",
    visibility = ["//visibility:public"],
)

# A Docker image for the service (Linux binary)
go_image(
    name = "image",
    binary = ":binary",
    visibility = ["//visibility:public"],
)

Start with the reported Go net cgoLookupIP path and the getaddrinfo call in the stack trace, then review the go_binary and go_image definitions shown in the issue. Compare the Bazel build variations involving static linking and the requested netdns=go behavior. The issue does not provide a reproducible case or a defined completion condition, so a fix cannot be confirmed from the payload alone.