Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jmhodges opened this issue Jul 5, 2017 · 5 comments

Comments

Projects
None yet
4 participants
@jmhodges
Copy link
Contributor

commented Jul 5, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2017

(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

This comment has been minimized.

Copy link
Contributor

commented Jul 5, 2017

@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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 5, 2017

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

@bradfitz bradfitz changed the title macOS DNS resolver is returning "Additional Section" entries as answers to host lookups net: macOS DNS resolver is returning "Additional Section" entries as answers to host lookups Jul 5, 2017

@bradfitz bradfitz added this to the Go1.10 milestone Jul 5, 2017

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Jul 5, 2017

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Sep 4, 2017

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Dec 1, 2017

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.

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Dec 14, 2017

@gopherbot

This comment has been minimized.

Copy link

commented Jan 1, 2018

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.)

@gopherbot gopherbot closed this Jan 1, 2018

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Jan 27, 2018

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Mar 16, 2018

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Apr 13, 2018

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Nov 9, 2018

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Nov 12, 2018

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Nov 14, 2018

@golang golang locked and limited conversation to collaborators Jan 1, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.