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

Issue 265970 link

Starred by 34 users

Issue metadata

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

Sign in to add a comment

Built-in DNS resolver does not handle /etc/resolver configuration

Reported by, Jul 30 2013

Issue description

Chrome Version       : 28.0.1500.71 (Official Build 209842) 
URLs (if applicable) :
Other browsers tested:
     Safari 6: OK
  Firefox 20: OK

What steps will reproduce the problem?
1. Have a VPN setup with split-dns (i.e. when connected, queries for certain domains are to be handled by pre-defined internal servers instead of defaults)
2. Have separate DNS zones configured for internal (including VPN) and external queries on DNS server.
3. Have host ( configured in both internal and external DNS zones
4. Disconnect VPN
5. Attempt to visit in Chrome
6. Connect VPN (at this point, queries for * should go to internal DNS server)
7. Attempt to visit in Chrome

What is the expected result?
The cached result for (populated in step 5) should be replaced with new result.  This is what happens in all other browsers, and in Chrome with built-in DNS client disabled.

What happens instead?
Chrome attempts to visit using cached DNS result, not the one that would be retrieved over the established VPN connection.

Please provide any additional information below. Attach a screenshot if

Comment 1 by, Jul 30 2013

Labels: Cr-Internals-Network-DNS

Comment 2 by, Jul 30 2013

Status: Started
Built-in DNS does not handle split-dns (multi-domain resolv.conf).

This is related to  Issue 82772 .

The fix will not make it to M28. We should probably roll AsyncDNS back.

Comment 3 by, Jul 30 2013

 Issue 82772  has been merged into this issue.

Comment 4 by, Jul 30 2013

Summary: Built-in DNS resolver does not handle /etc/resolver configuration (was: Built-in DNS client cache and MacOS built-in VPN client issue)
res_state in libresolv does not include the extra nameservers.

However, dns_config_t in configd does. To support this, we need to pull configd as a  third_party dependency.

Comment 5 by, Jul 30 2013

Correction, the dependency we need is libdnsinfo. I believe libdnsinfo is bundled with OS X by default, but I'm not sure where we'd get the dnsinfo.h header.

Comment 6 by, Jul 31 2013

Work started in

Until available, workarounds are:
1) Disable NXDOMAIN helper. In OpenDNS:

2) Disable Built-in Asynchronous DNS in chrome://flags

Comment 7 by, Jul 31 2013

libdnsinfo.dylib is available starting in MacOSX10.7.sdk, but the minimum SDK version for building Chromium is 10.6.
NB: This is being discussed here:

A little more detail (I'm not a Mac Developer, but this is my understanding as a sysadmin what's going on)
If I recall correctly, MacOS X is phasing out /etc/resolv.conf and instead there is a library or framework one is supposed to call to get info about DNS servers.  The OS generates an /etc/resolv.conf based on the info it has, but it isn't always possible to translate the complexity it understands into the relatively simplistic resolv.conf syntax.  The /etc/resolv.conf file exists for legacy programs that (in Apple's way of thinking) should be rewritten to use their new way.  It seems like Chrome is paying attention to /etc/resolv.conf instead of querying the OS.  As a result, certain VPN systems (like, ohhh... the one built into OS X!) which can do a very sophisticated split-horizon configuration, creates a /etc/resolv.conf using the external DNS server IPs instead of the internal DNS server IPs.  Debate all you want, but Chrome's async DNS is going to need to up its game to support this kind of thing.  Otherwise, VPN users are stuck.  I doubt that Google employees use the Mac OS X built-in Cisco vpn driver, nor split-horizon, so they may be unfamiliar with how common these things are.

The workaround is to use Safari or Firefox.

Comment 9 by, Aug 16 2013

Chrome's built-in DNS resolver on Mac doesn't read /etc/resolv.conf, but relies on res_init (which does not read resolv.conf but uses configd's dnsinfo). A split-horizon configuration will be detected as soon as lands. In the future, I hope to move from res_init directly to dnsinfo.
Project Member

Comment 10 by, Aug 21 2013

r218617 | | 2013-08-21T03:25:19.269339Z

Changed paths:

Detect domain-specific resolvers on OS X and disable DnsClient

This CL also changes the handling of DNS configuration options not
yet fully implemented by DnsClient. Rather than DnsConfigService
failing to provide DnsConfig, the new field DnsConfig.unhandled_options
indicates to DnsClient that it should disable itself.

BUG= 265970 

Review URL:

Comment 11 by, Aug 23 2013

Status: Fixed
Fix available in M31.

Comment 12 by, Nov 1 2013

 Issue 314203  has been merged into this issue.

Sign in to add a comment