New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 681959 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 617391
Owner: ----
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Incorrect IP resolved from DNS

Reported by dylan.ky...@gmail.com, Jan 17 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Attempt to access a domain that resolves to two different IP's based upon the nameserver in use. Let one be an internal IP resolved through a nameserver that's only accessible through a VPN and the other be a public IP that's accessed through publicly available nameservers.
2. Nameservers config from chrome://net-internals/#dns
<internal VPN dns 1>:53
<internal VPN dns 2>:53
<router/public dns>:53

What is the expected behavior?
I'd expect the dns to resolve from internal dns 1 or 2 like dig or firefox do. 

What went wrong?
Instead it will randomly resolve from the public dns. Sometimes it will get it right, but it seems like most of the time it's resolving from the public dns and even clearing the host cache on chrome://net-internals/#dns doesn't seem to help.

Did this work before? N/A 

Chrome version: 55.0.2883.87  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 24.0 r0

I have seen this work correctly in Chrome on OS X and in Firefox on Linux. I feel like this used to work correctly and stopped within the past 6 months, but I'm not 100% sure on that. 
This superuser question seems to almost exactly describe my issue http://superuser.com/questions/656938/does-chrome-use-a-different-dns-server-from-the-os?rq=1
 
It just occurred to me that this may be a caching issue with the internal DNS client. For instance, if the VPN connection hasn't been re-established after reconnecting to a WiFi network before a DNS request has been made, the VPN accessible nameserver won't be available. Am I also correct in assuming that the "Clear host cache" button doesn't clear Chrome's "internal dns client" cache?

Any way to force the use of the OS DNS resolving? Would switching to DNSMasq work better for me?

Also relevant, my resolv.conf:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTENa

nameserver <redacted internal ns1>
nameserver <redacted internal ns2>
nameserver 192.168.254.254
search <internal domain>

Comment 2 by mmenke@chromium.org, Jan 17 2017

Cc: juliatut...@chromium.org
Components: -Internals>Network Internals>Network>DNS

Comment 3 by mmenke@chromium.org, Jan 17 2017

Clearing cache does indeed clear the internal DNS cache (We also clear it on network changes and abort in-process DNS lookups, so it shouldn't be needed when reconnecting to WiFi, anyways).  I think we may just rotate DNS servers when using the internal client.
Okay, that gives me a little more insight into why it seems to be occurring so randomly. 
Labels: TE-NeedsTriageHelp
This issue seems to be out of TE-scope. Hence, marking label as TE-NeedsTriageHelp for further investigation.

Thanks...!!
Owner: mge...@chromium.org
Mergedinto: 617391
Owner: ----
Status: Duplicate (was: Unconfirmed)

Sign in to add a comment