New issue
Advanced search Search tips
Starred by 8 users
Status: Fixed
Owner:
Closed: May 2015
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
Remove AsyncDNS option in about:flags
Project Member Reported by cbentzel@chromium.org, Nov 11 2014 Back to list
about:flags is not meant to be used forever.

We've had async dns flags in there for a long time. At this point, I think the platforms that we will support have stabilized by default.

Let's remove it.

 
Should I leave the command-line flag?
I'd say just remove it.  If it were under active development, I'd be fine with keeping it, but since not, it's just more cruft.
We do occasionally debug issues with it; it might be useful to have.
Oh, if it's still actually in use, that's fine.
Project Member Comment 5 by bugdroid1@chromium.org, Jan 8 2015
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eabf1f5baba38d46921acd6edda594f942f7d6a1

commit eabf1f5baba38d46921acd6edda594f942f7d6a1
Author: ttuttle <ttuttle@chromium.org>
Date: Thu Jan 08 19:05:09 2015

Async DNS: Remove toggle from about:flags

Async DNS is fairly stable at the moment, so we don't really need the
toggle in about:flags anymore. (Note that the --enable-async-dns and
--disable-async-dns command-line flags will still work for now.)

BUG= 432236 

Review URL: https://codereview.chromium.org/840933003

Cr-Commit-Position: refs/heads/master@{#310552}

[modify] http://crrev.com/eabf1f5baba38d46921acd6edda594f942f7d6a1/build/ios/grit_whitelist.txt
[modify] http://crrev.com/eabf1f5baba38d46921acd6edda594f942f7d6a1/chrome/app/generated_resources.grd
[modify] http://crrev.com/eabf1f5baba38d46921acd6edda594f942f7d6a1/chrome/browser/about_flags.cc

Comment 6 by pennymac@google.com, Jan 15 2015
Labels: -M-41 M-42 MovedFrom-41
Moving all non essential bugs to the next Milestone.
Labels: -M-42 MovedFrom-42
[AUTO] This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
Comment 8 by Deleted ...@, Apr 25 2015
This flag isn't there in the latest stable (42.0.2311.90)... I guess I don't understand why the status is "Assigned".

Anyway. Can we bring this flag back?

There are plenty of people still effected by AsyncDns problems:
http://superuser.com/questions/623150/chrome-not-using-vpn-dns-everything-else-is
http://stackoverflow.com/questions/17777458/pow-domains-not-loading-in-chrome

My problem is I am using Pow proxy, which (combined with asyncDNS-enabled Chrome) causes 5 second DNS Lookups to domains that are in my /etc/hosts file.

And I'd rather not have to forever open Chrome from the command-line just to use this flag.
Comment 9 by mmenke@chromium.org, May 14 2015
Status: Fixed
Comment 10 by dgri...@gmail.com, Nov 24 2015
Sorry but I don't understand. This bug is fixed so what does it mean that the flag is back or removed forever.

Sorry but with many public WiFi the async DNS doesn't work at all.
Comment 11 by Deleted ...@, Dec 19 2015
Please put this flag back in. The async DNS client makes it incredibly difficult to use Chrome with parental controls enabled on OS X. Instead of approving sites, I have to approve IP addresses. This makes no sense. I would much rather my use Chrome than Safari but without the ability to easily disable the async DNS client, it just doesn't make sense for them to use Chrome. It's too frustrating for me and them.
You should bring back this flag. The built-in DNS server is bypassing regular DNS resolution which makes it very difficult to ensure that the correct DNS server is used. I'm currently trying to secure DNS resolution using dnscrypt and I have issues with chrome applying its own logic without taking in account the OS config. This should be configurable at least. The command line is not really a decent solution.
Comment 13 by eldo...@gmail.com, Jan 3 2016
I'm going to throw my hat in on this as well. 

We have a VPN for connecting to internal assets, and async DNS is completely bypassing the vpn assigned DNS server. 

This is a MAJOR issue.  

If it wasn't for a vendor that requires chrome to access their service, I'd already be moving users off of chrome. 
This is ridiculous. We are also having issues due to this while using a VPN.

You are breaking plenty of very valid setups with this.
Comment 15 by b...@tilford.info, Jan 22 2016
Yes chrome can't be used reliably on a VPN at all. Need this flag! DNS shouldn't be all fancy and different depending what app your using. 
Owner: juliatut...@chromium.org
We are experiencing the same issue with VPN. This is a real problem with split horizon DNS. Data that should have been transferred over the VPN now gets routed over the WAN; This looks like a security issue to me.
Which OS are people having VPN issues with? Is this consistently OSX or a different OS?
Comment 19 by nirvd...@gmail.com, Apr 26 2016
I'm seeing the problem with Ubuntu 16.04. For unrelated reasons, I've had to disable dnsmasq, so everything is being driven by /etc/resolv.conf -- a supported, but non-default configuration. My VPN DNS servers are being bypassed by Chrome and thus addresses that can be resolved publicly (e.g., wildcards addresses) but have different resolutions internally are rendering the wrong page.
This is causing problems with our network, as well. The internal chrome DNS resolver does not properly resolve internal IP addresses from our local DNS, sometimes resolving our records to the external IP, and sometimes to the internal IP.

It seems to happen randomly. Without the flag, we have to migrate users off of Chrome.
#20, please file a bug detailing the erroneous DNS behavior. We'd rather fix teh underlying problem than offer a workaround.
Comment 22 by ema....@gmail.com, Aug 30 2016
Does anyone know where --enable-async-dns and --disable-async-dns command-line flags have been documented as removed? On v52 win x64 they don't seem to work anymore.

This bug tracker is a nightmare. You have issues fixed and open and features added and removed all in a bunch. It's rare to know what isn't working and what isn't there anymore to actually warrant a concern if it's working or not.
Labels: Restrict-AddIssueComment-EditIssue
This issue is fixed because the flags were removed. If the async DNS resolver does not work for you, please file (or comment on) a bug related to that misbehavior.
Sign in to add a comment