[richard-ramos]

Summary

Add system DNS server discovery from /etc/resolv.conf on Unix and adapter configuration on Windows, with the existing public DNS servers as a fallback. Discovery skips unusable IPv6 link-local servers and down Windows adapters, and retries Windows adapter queries when the required buffer grows.

Keep platform discovery in separate POSIX and Windows modules with a common getNameServers entry point. The common module applies the fallback; dnsresolver re-exports the public discovery API.

Usage

Construct a resolver explicitly with DnsResolver.new(getSystemNameServers()) and pass it to withNameResolver(resolver). The caller retains ownership. DnsResolver has no persistent worker resources to start or stop.

Stack

1 of 3 — merge in this order:

1. This PR: system DNS discovery; base master.
2. #3384: system resolver worker pool and factory; base feat/system-name-resolver.
3. #3385: bounded multiaddress expansion; base feat/system-resolver-backend.

Validation

• Switch suites: 49 checks passed.
• Name-resolution suite: 12 checks passed.
• Nameserver discovery: 5 checks passed.
• Windows discovery tests cross-compiled successfully with MinGW; Windows runtime tests were not run.

References

Continues the DNS discovery work from #3114, originally authored by @nate-staked. Related: #3378.

[richard-ramos]

/review

[github-actions]

🔍 OpenCodeReview found 6 issue(s) in this PR.

• ✅ Successfully posted inline: 6 comment(s)

Model: qwen3.8-max
Review generated in: 45m 27s

[gmelodie]

Nit: maybe have linux/windows specific behavior on respective files, and a top-level files calls the common code that chooses which (also, maybe have similar procs be called the same in both)

[vladopajic]

there is to be key principle that Switch / SwitchBuilders are going to follow.

• when it comes to managing lifecycle of components created by user, they should be one to manage it. Switch should just use the interface it needs. if library does not need lifecycle, for it's own purpose, than library should not care about what user does. library only cares about interface it needs and depends on.

• building anything with SwitchBuilder's withXXX procs should only set config (they build configuration), and build finally builds everything into Switch. meaning user should not care about types. meaning withNameResolver() will set some property useNameResolver to true, then we create default name resolver. only if we want to allow custom implementations then there could be overloaded withNameResolver(resolver: NameResolverInterface), but in this case they will manage it (start/stop).

[vladopajic]

why is strat/stop added when all code here never use it? all are discard / raiseAssert?

[vladopajic]

@richard-ramos now i see that next PR in stack has start/stop. so likely all name resolver should have it...

also the way users should use this in SwitchBuilder should be via 2 procs

.withDNSNameResolver( nameServers: seq[TransportAddress] )
.withSystemNameResolver() 

then each of these will create appropriate NameResolver and hook it to Switch. user shouldn't care about state (because it is created by SwithcBuilder).

NameResolver should be treated as a service. So that Switch reuses same logic for starting/stoping.

For example, all NameResolvers could have method .Service() that will provide accessor this name resolver from Service interface, and SwitchBuilder would do services.add(nameResolver.Service()) in addition to what it does in this pr