net: macOS DNS resolver is returning "Additional Section" entries as answers to host lookups

[jmhodges]

This is go version 1.8.3 on MacOS 10.12.5.

While debugging a problem with https://github.com/bazelbuild/rules_webtesting code, I found that the return value of os.Hostname ("iMac", in this case) when passed to net.LookupHost will return the IP address of both the A record in the dig-equivalent Answer Section, but also A records in the dig-equivalent Additional Sectional. This is causing the rules_webtesting code fail when it tries to connect locally.

I think this is incorrect, but I'm not completely sure.

The DNS server in this case is a weird DSL modem thing that I can't control. In the Additional Section, the server is returning an A record with the same name as the A record in the Answer section but with an IP address pointing at the gateway machine. (I don't know why it does this, but I think its related to the weird way it sometimes it redirects you to a public site to configure it.)

The first IP address returned is the gateways, so the rules_webtesting code points its HTTP client at that and it, of course, fails.

This is the Go code: https://play.golang.org/p/epgikfuKRG

And it prints out:

192.168.42.1
192.168.42.67

And here's the equivalent dig commands:

$  hostname
iMac
$  dig iMac

; <<>> DiG 9.8.3-P1 <<>> iMac
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16099
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;iMac.				IN	A

;; ANSWER SECTION:
iMac.			172800	IN	A	192.168.42.67

;; AUTHORITY SECTION:
iMac.			172800	IN	NS	homeportal.

;; ADDITIONAL SECTION:
iMac.			172800	IN	A	192.168.42.1

;; Query time: 13 msec
;; SERVER: 192.168.42.1#53(192.168.42.1)
;; WHEN: Tue Jul  4 21:21:01 2017
;; MSG SIZE  rcvd: 82

[jmhodges]

(Using dig iMac @192.168.42.1 has the same result, so there's nothing like a local resolver screwing me up, I believe.)

[mikioh]

@jmhodges,

Can you please show us the output of the following:

• GODEBUG=netdns=cgo your-code-snippet-mentioned-above.go
• GODEBUG=netdns=go your-code-snippet-mentioned-above.go
• dig iMac.homeportal. a // please pass a FQDN instead of a partial label when using dig, drill or equivalent
• scutil --dns

a local resolver screwing me up

Sorry, I'm still tying to capture your point, but looks like 192.168.42.1 is the local recursive server. IIUC, you had some difficulty when you used some funny DNS recursive server, right? So what's wrong with specifying more better recursive DNS servers?

[jmhodges]

Thanks for the response!

To your questions: Oh, no, no, sorry, I meant "local resolver" as in "running on the same hardware" instead of "local to the network". Shouldn't have included any of that, really! A mental artifact of how I'd been debugging problems while getting to this issue that got jammed in there

Here's that output (it's a little interesting!):

$  GODEBUG=netdns=cgo go run foo.go
192.168.42.1
192.168.42.67

$  GODEBUG=netdns=go go run foo.go
192.168.42.67

$  dig iMac.homeportal

; <<>> DiG 9.8.3-P1 <<>> iMac.homeportal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64545
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;iMac.homeportal.		IN	A

;; AUTHORITY SECTION:
.			10800	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2017070500 1800 900 604800 86400

;; Query time: 53 msec
;; SERVER: 192.168.42.1#53(192.168.42.1)
;; WHEN: Wed Jul  5 02:49:26 2017
;; MSG SIZE  rcvd: 108

$  scutil --dns
DNS configuration
 
resolver #1
  search domain[0] : gateway.sonic.net
  nameserver[0] : 192.168.42.1
  if_index : 5 (en1)
  flags    : Request A records
  reach    : Reachable, Directly Reachable Address
 
resolver #2
  domain   : 272007727.members.btmm.icloud.com
  options  : pdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 150000
 
resolver #3
  domain   : local
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300000
 
resolver #4
  domain   : 254.169.in-addr.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300200
 
resolver #5
  domain   : 8.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300400
 
resolver #6
  domain   : 9.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300600
 
resolver #7
  domain   : a.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 300800
 
resolver #8
  domain   : b.e.f.ip6.arpa
  options  : mdns
  timeout  : 5
  flags    : Request A records
  reach    : Not Reachable
  order    : 301000
 
DNS configuration (for scoped queries)
 
resolver #1
  search domain[0] : gateway.sonic.net
  nameserver[0] : 192.168.42.1
  if_index : 5 (en1)
  flags    : Scoped, Request A records
  reach    : Reachable, Directly Reachable Address

[mikioh]

Sorry for being late.

I think this is incorrect [...]

Well, it looks like the situation is a bit complicated.

1. What os.Hostname returns
   It's a host name. Perhaps it may be suitable for DNS queries, perhaps not.
2. How net.LookupHost behaves
   As you reported (thanks), when GODEBUG=nedns=cgo it uses external functionality. In general it's hard to control the functionality; for example, we cannot prevent getaddrinfo implementations from returning additional records or dealing with the returned RRs heuristically.
3. Why xSP's umbrella-type name services
   Because it's their business; accommodating their customers with some convenient solutions.

#22826 might be a workaround for your specific, node-local scope issue, though I guess that there is nothing that we can do effectively and generally for now.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)