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

Issue 432236 link

Starred by 8 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: May 2015
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Remove AsyncDNS option in about:flags

Project Member Reported by, Nov 11 2014

Issue description

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, Jan 8 2015

The following revision refers to this bug:

commit eabf1f5baba38d46921acd6edda594f942f7d6a1
Author: ttuttle <>
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:

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


Comment 6 by, 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:

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, May 14 2015

Status: Fixed

Comment 10 by, 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, 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, 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. 
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, 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, 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