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

Jump to bottom

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
Closed

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

jmhodges opened this issue Jul 5, 2017 · 5 comments
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Go1.10

Comments

@jmhodges
Copy link
Contributor

jmhodges 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 jmhodges mentioned this issue Jul 5, 2017
Closed
@jmhodges
Copy link
Contributor Author

jmhodges 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
Copy link
Contributor

mikioh 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
Copy link
Contributor Author

jmhodges commented Jul 5, 2017 •
edited

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 the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label 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
localhost hack for macOS 10.12.5
5227bf3 
See bazelbuild#150 and
golang/go#20904
jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Sep 4, 2017
@jmhodges
localhost hack for macOS 10.12.5
8d45ffd 
See bazelbuild#150 and
golang/go#20904
@mikioh
Copy link
Contributor

mikioh commented Dec 1, 2017 •
edited

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.

@mikioh mikioh added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 1, 2017
jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Dec 14, 2017
@jmhodges
localhost hack for macOS 10.12.5
d8fb4a2 
See bazelbuild#150 and
golang/go#20904
@gopherbot
Copy link

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

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Jan 27, 2018
@jmhodges
localhost hack for macOS 10.12.5
1fa7dcd 
See bazelbuild#150 and
golang/go#20904
jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Mar 16, 2018
@jmhodges
localhost hack for macOS 10.12.5
39fc85a 
See bazelbuild#150 and
golang/go#20904
jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Apr 13, 2018
@jmhodges
localhost hack for macOS 10.12.5
b49b775 
See bazelbuild#150 and
golang/go#20904
jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Nov 9, 2018
@jmhodges
localhost hack for macOS 10.12.5
32a43ad 
See bazelbuild#150 and
golang/go#20904
jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Nov 12, 2018
@jmhodges
localhost hack for macOS 10.12.5
fb8eb02 
See bazelbuild#150 and
golang/go#20904
jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Nov 14, 2018
@jmhodges
localhost hack for macOS 10.12.5
f1bb929 
See bazelbuild#150 and
golang/go#20904
@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.
Assignees
No one assigned
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Go1.10
Development

No branches or pull requests
4 participants
@jmhodges @bradfitz @mikioh @gopherbot