Thanks for providing feedback to us.

Chrome released stable 52.0.2743.82 on July 20, could you update your chrome version and see if it is still reproducible there? Unfortunately, I couldn't repro the issue on my machine as it's able to resolve the urls all the time. 

You might also want to provide with net-internals logging per https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details to help us investigate the issue. 

Thanks!

Thank you; I've emailed net internals to you.

[+juliatuttle]:  Are we using the async resolver on Linux, currently?  I could see that having trouble with this, though not sure why it would affect Chrome only, unless it's only enabled via a field trial.

Attached is the net-internals the reported send to me via email. Please take a look. 

Deleted: net-internals-log (1).json 222 KB

net-internals-log (1).json 222 KB View Download

According to the reporter: the net-internals were captured a few minutes after switching from one vpn to another. It showed there was failed attempt to connect to http://newweb.staging.execvision.io. However, the reported confirmed direct connecting to the IP directly (10.1.3.23) worked fine and curl can also connect to the url on the command line. 

I don't see any requests for newweb.staging.execvision.io or 10.1.3.23 in that netlog. Could you capture another log, and make sure you start capturing the netlog before attempting to reproduce. Probably would be best to start before doing the VPN switch.

The log does indicate the async dns resolver is in use, version is Google Chrome 52.0.2743.82. None of the active field trials look dns related, but I could be wrong.

There is a single HOST_RESOLVER_IMPL_JOB in the netlog, and it is using the dns server at 127.0.1.1.

The DNS info in the netlog lists the nameservers as:
10.0.0.2:53
127.0.1.1:53

That's all that seemed interesting from this log, we probably need a log that captures from before the VPN switch to see more.

rf@4rc.io:  I don't think we can make forward progress here without a more complete net-internals log.  Could you please provide one?  If not, we'll have to just close the bug.

Sorry to take so long on this; been busy.

Here's a net-internals capturing the switch between VPNs, and the failure to update Chrome's internal DNS.

Deleted: net-internals-log.json 980 KB

net-internals-log.json 980 KB View Download

rf@4rc.io:  Thanks, but I'm still having trouble even with your most recent log, it seems that some of the info is missing.  Could you possibly try one more time, only could you use --log-net-log to make sure your log has all events?   (refer to the "Logging on startup" section of  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details).

This is fixed for me on Ubuntu 16.10, now that systemd-resolved is being used. You might want to keep this bug open for systems not on systemd-resolved (whatever the prior mechanism was).

I take it back. Even after restarting systemd-resolved, chrome is currently in a state where it's unable to resolve the same staging server's domain name, even after restarting chrome multiple times (and killing the background chrome service). chromium on the other hand can get to it. What is the difference between how chrome and chromium handle domain name resolution?

Lot attached, using the command line --log-net-log.

Deleted: log 1.3 MB

log 1.3 MB View Download

I'm sorry, rf@, but it still doesn't look like a good log.  The only reference to newweb.staging.execvision.io is a successful URLRequest that looks like it was satisfied from cache.  Might you have accidentally taken a trace when you actually had a successful result?

Chrome and Chromium are pretty close to identical; it's far more likely that there's a version difference (or, since this behavior is flaky, that the difference is just luck) than an actual difference between the two.  Having said that, if by Chromium you mean a package installed from the linux distribution, some bets are off--those packages may incorporate changes to Chromium we have nothing to do with.  

@rdsmith - nope, I promise you that this log captured the behavior. There were zero chrome processes running; I started it with the command line --log-net-log. I opened a single tab and navigated to the URL, and got the verizon fallback for cannot resolve.

It is true that my ubuntu-packaged chromium (which, again, is working reliably on VPN network changes) is on 53.X rather than chrome's 54.X, so that may explain the difference. So, let's discount that as a red herring.

So to recap - 

a) The log apparently shows nothing wrong. 
b) The system DNS cache (somewhere in systemd-resolved) is flushed (by virtue of restarting it after switching VPNs). 
c) On the command line, dig returns the right IP address (which is an ELB). 
d) Other browsers (Firefox, Chromium) can get to it. 
e) Chrome cannot, even after restarting. 
f) This is intermittent behavior. Prior to restarting my computer a day or so ago, Chrome was working as expected (i.e. able to resolve the address after flushing the system DNS cache.)

What else do you want me to do to try to resolve this? If anybody's interested I'm happy to screenshare and attempt to debug in real time.

@rdsmith - I just read your response again and have a thought. 

You said "the only reference to newweb.staging.execvision.io is a successful URLRequest that looks like it was satisfied from cache".

Is it possible that the Verizon "could not resolve" page is being somehow cached by Chrome, and that Chrome hits it rather than going to the system DNS?

Deleted: screenshot_453.png 110 KB

	screenshot_453.png 110 KB View Download

@rdsmith - one more update. Left up overnight, chrome is now able to resolve the VPN provided urls. Something must have timed out / refreshed.

Huh.  That's an interesting point you raise (in c#14, about caching the Verizon page).  Willing to pop up an Incognito Window (easiest way to get a completely clean slate including an empty cache, and has the advantage of not messing with the state of your working profile) and give it another try?  

Reproduced this and confirmed that it may be cache related. The VPN connection had some sort of timeout over the weekend, so I reconnected and restarted systemd-resolved. Both chromium and chrome had been left running over the weekend also; in non-incognito tabs, chrome failed to load it and chromium managed. I then opened an incognito tab in chrome and was able to connect. 

I don't think this needs any more feedback?