Expected behavior

All DNS servers that are used by netty resolver are mostly reachable

Actual behavior

On Windows, netty resolver will use a DNS server that will never be reachable because the network card is not actually enabled.

Steps to reproduce

Not sure, but I think it would happen with Wifi and a LAN adapter on a laptop that both have DNS servers configured, one of them to a non-public DNS server (usually the LAN adapter).

Minimal yet complete reproducer code (or URL to code)

@Test
    public void testOneDnsServerDownFallsBack() {
        DnsNameResolver resolver = new DnsNameResolverBuilder(group.next())
                .channelType(NioDatagramChannel.class)
                .nameServerProvider(new SequentialDnsServerAddressStreamProvider(
                        new InetSocketAddress("10.123.234.1", 53),
                        new InetSocketAddress("8.8.8.8", 53)))
                .resolveCache(NoopDnsCache.INSTANCE)
                .authoritativeDnsServerCache(NoopAuthoritativeDnsServerCache.INSTANCE)
                .cnameCache(NoopDnsCnameCache.INSTANCE)
                .traceEnabled(true)
                .resolvedAddressTypes(ResolvedAddressTypes.IPV4_PREFERRED)
                .completeOncePreferredResolved(true)
                .build();
        try {
            InetAddress address = resolver.resolve("echo.jsontest.com").syncUninterruptibly().getNow();
            System.out.println(address);
        } finally {
            resolver.close();
        }
    }

It resolves, but takes forever since it continues to query and timeout against an unreachable DNS server - in the example the servers are set manually but with Windows it's easily possible to automatically have a similar configuration.

Netty version

HEAD of 4.1 branch

JVM version (e.g. java -version)

Tried 11, 8. Looked at openjdk code and see it hasn't changed even in 13.

OS version (e.g. uname -a)

Windows 10

This seems to be a somewhat known issue of the JDK. We would probably want to use a similar implementation to what chromium does instead of relying on JDK.

Details at #9161 (comment) - a fix would be similar to the native macos resolver helper, which used the more modern GetAdapterAddresses API through JNI (or JNA any thoughts on that?) to get live server addresses, not all configured ones.