net/http: TestTransportEventTraceRealDNS broken on one smartos buidler, mips64le

[bradfitz]

The recent commit 19619c2 broke one of the SmartOS builders.

It seems to resolve the hostname "dns-should-not-resolve.golang" to 127.0.0.1.

https://build.golang.org/log/31d47308bf9f4bfcc3ce7d6118ef51b9640726a3

--- FAIL: TestTransportEventTraceRealDNS (0.08s)
    transport_test.go:3344: expected substring "DNSDone: {Addrs:[] Err:" in output.
    transport_test.go:3350: should not see Connect events
    transport_test.go:3353: Output:
        DNSStart: {Host:dns-should-not-resolve.golang}
        DNSDone: {Addrs:[{IP:127.0.0.1 Zone:}] Err:<nil> Coalesced:false}
        ConnectStart: tcp 127.0.0.1:80
        ConnectDone: tcp 127.0.0.1:80 dial tcp 127.0.0.1:80: getsockopt: connection refused
FAIL
FAIL    net/http    10.005s

Why?

Fix the DNS there, or skip the test on that builder?

/cc @tombergan @4ad

[bradfitz]

It's also broken on mips64le:

https://build.golang.org/log/13451faa7356c872c5cf649dd27878671c96d20c

1 second passes in backend, proxygone= false
--- FAIL: TestTransportEventTraceRealDNS (0.24s)
    transport_test.go:3338: expected error during DNS lookup
FAIL
FAIL    net/http    57.971s

/cc @cherrymui

[cherrymui]

It seems my home network's dns somehow messed up:

$ ping dns-should-not-resolve.golang
PING dns-should-not-resolve.golang (92.242.140.2) 56(84) bytes of data.
^C

Change the dns server to 8.8.8.8 then the test passed. I'll fix my network configuration. In the meantime, you can ignore this error on mips64le builder.

[4ad]

Same for the smartos builder:

[aram@go-buildbox ~]$ ping dns-should-not-resolve.golang
dns-should-not-resolve.golang is alive

[4ad]

Problem fixed on SmartOS builder.

[bradfitz]

Thanks! I've wiped those failed builds from the dashboard and they're retrying.

[bradfitz]

@4ad what was the problem for future reference?

I want to make sure @zombiezen and I have it documented so future SmartOS builders aren't affected.

[4ad]

/etc/resolv.conf contained some funny servers. I set them to 8.8.8.8 and 8.8.4.4. This was a non-default configuration problem specific to the environment, it's unlikely to happen on other SmartOS systems.

[nand0p]

@bradfitz This issue can happen if there is a domain or search entry in /etc/resolv.conf, and this FQDN/TLD has a wildcard/catchall subdomain record. In my case, this was being pushed to me by DHCP server. Thought I should mention, in case you want to document this edge case.