Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
10334009:
[net/dns] Turn DnsConfigService on by default. (Closed)
|
Created:
8 years, 7 months ago by szym Modified:
8 years, 6 months ago CC:
chromium-reviews, cbentzel+watch_chromium.org, darin-cc_chromium.org Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
Description[net/dns] Turn DnsConfigService on by default.
[email protected]
BUG=125599
TEST=net_unittests
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=139892
Patch Set 1 : . #Patch Set 2 : Check for rogue (DNSChanger) servers. #Patch Set 3 : Adds CreateDnsWatchingSystemHostResolver. #Patch Set 4 : Rebased after DnsConfigWatcher CL. #Patch Set 5 : Only check for rogue DNS once per session. #Patch Set 6 : Replace CreateSystemHostResolver with MockCachingHostResolver in TestURLRequestContext. #Patch Set 7 : Allow SerialWorker::Cancel after MessageLoop has been destroyed. #Patch Set 8 : Moved rogue DNS detection to another CL. #Patch Set 9 : 2x CreateSystemHostResolver -> MockHostResolver. Fix jingle_unittests:SingleLoginAttemptTest. #Patch Set 10 : Explicitly specify HostResolver::Resolve behavior. #Patch Set 11 : Rebased to http://codereview.chromium.org/10408067/ #
Total comments: 10
Patch Set 12 : Go back to using OnDNSChanged. Record AsyncDNS.HaveDnsconfig. #
Total comments: 7
Patch Set 13 : Responded to review. #
Total comments: 2
Patch Set 14 : Ignore watch-related signals in OnDNSChanged. Only AddDNSObserver on OS_LINUX. #
Messages
Total messages: 30 (0 generated)
This will enable DnsConfigService, and results will be visible in chrome://net-internals/#events although not /#dns. The plan is to add measurements of successful DnsConfig and detection of rogue configuration on top of this CL. I could do it in this CL as well.
On 2012/05/02 21:20:41, szym wrote: > The plan is to add measurements of successful DnsConfig and detection of rogue > configuration on top of this CL. I could do it in this CL as well. Patch Set 2 detects DNSChanger servers. I'm concerned about sampling bias: DNSChanger-affected hosts probably won't see DnsConfig changes, since the configuration is not provided by DHCP.
On 2012/05/02 22:07:44, szym wrote: > On 2012/05/02 21:20:41, szym wrote: > > The plan is to add measurements of successful DnsConfig and detection of rogue > > configuration on top of this CL. I could do it in this CL as well. > > Patch Set 2 detects DNSChanger servers. I'm concerned about sampling bias: > DNSChanger-affected hosts probably won't see DnsConfig changes, since the > configuration is not provided by DHCP. Hold off review on the DnsConfigService change. I forgot HostResolverImpl is created in many places other than io_thread.cc, and we don't want DnsConfigService there.
On 2012/05/02 22:18:11, szym wrote: > On 2012/05/02 22:07:44, szym wrote: > > On 2012/05/02 21:20:41, szym wrote: > > > The plan is to add measurements of successful DnsConfig and detection of > rogue > > > configuration on top of this CL. I could do it in this CL as well. > > > > Patch Set 2 detects DNSChanger servers. I'm concerned about sampling bias: > > DNSChanger-affected hosts probably won't see DnsConfig changes, since the > > configuration is not provided by DHCP. > > Hold off review on the DnsConfigService change. I forgot HostResolverImpl is > created in many places other than io_thread.cc, and we don't want > DnsConfigService there. In the long run we'd probably want these to use the same configuration. Would that be possible, or is this to deal with it in other processes?
On 2012/05/03 01:24:45, cbentzel wrote: > > HostResolverImpl is > > created in many places other than io_thread.cc, and we don't want > > DnsConfigService there. > > In the long run we'd probably want these to use the same configuration. Would > that be possible, or is this to deal with it in other processes? See http://crbug.com/126016 Current call-sites of CreateSystemHostResolver are... ConnectionTester (net-internals) net::URLRequestContextBuilder ^^^ not currently used, but could be problematic if each URLRequestContext owns an independent HostResolverImpl. Separate processes: content::ShellURLRequestContextGetter ServiceURLRequestContext remoting::URLRequestContext net::TestClient (curvecp) net::BaseTestServer fetch_client.c::main Test utilities: TestURLRequestContext net::::TransportClientSocketTest (transport_client_socket_unittest.cc) net::::RequestContext (proxy_script_fetcher_impl_unittest.cc) TestShellRequestContext So the only issue are the tests which call CreateSystemHostResolver not on a MessageLoop of TYPE_IO. I'm considering moving them to MockHostResolver.
On 2012/05/03 05:38:13, szym wrote: > On 2012/05/03 01:24:45, cbentzel wrote: > > > HostResolverImpl is > > > created in many places other than io_thread.cc, and we don't want > > > DnsConfigService there. > > > > In the long run we'd probably want these to use the same configuration. Would > > that be possible, or is this to deal with it in other processes? > > See http://crbug.com/126016 > So the only issue are the tests which call CreateSystemHostResolver not on a > MessageLoop of TYPE_IO. I'm considering moving them to MockHostResolver. I think using SystemHostResolver in a test setting is a bad idea, and using a DnsConfig which is not immediately available is also going to make the tests flaky. So I think we should either move them to MockHostResolver or add explicit: CreateTestHostResolver (without parameters) where we can swap the implementation out.
The issue of MessageLoop TYPE_* should resolve itself automatically after http://codereview.chromium.org/10377092/ lands. Consequently, I'll remove CreateDnsWatchingSystemHostResolver.
PTAL. After rebasing, this CL: 1) Enables DnsConfigService by default. 2) Checks for rogue DNS (once per session). 3) Updates TestURLRequestContext to use MockCachingHostResolver.
On Thu, May 17, 2012 at 12:14 PM, <[email protected]> wrote: > PTAL. > > After rebasing, this CL: > 1) Enables DnsConfigService by default. > 2) Checks for rogue DNS (once per session). > Maybe move 2 to a separate CL > 3) Updates TestURLRequestContext to use MockCachingHostResolver. > > > http://codereview.chromium.**org/10334009/<http://codereview.chromium.org/103... >
On 2012/05/17 16:18:43, cbentzel wrote: > > 2) Checks for rogue DNS (once per session). > > Maybe move 2 to a separate CL Done.
There are still issues in jingle_unittest. Hold off review on this one until further notice.
Since http://crrev.com/138413 HostResolverImpl is no longer used in test context, so this is now ready for review.
Sorry I didn't get back to you earlier. I have not yet had a chance to look over the tests. Just some comments about updating comments. http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver.h File net/base/host_resolver.h (right): http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver.h#n... net/base/host_resolver.h:189: // MockHostResolver from net/base/mock_host_resolver.h. Think a warning about using multiple SystemHostResolvers resulting in the system DNS config being read multiple times on network changes would be nice. http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... File net/base/host_resolver_impl.cc (left): http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... net/base/host_resolver_impl.cc:1933: void HostResolverImpl::OnDNSChanged(unsigned detail) { Hmm...This does change behavior a little. We no longer abort all in progress jobs when we can't read part of the config, and another part changes. http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... File net/base/host_resolver_impl.cc (right): http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... net/base/host_resolver_impl.cc:482: scoped_ptr<DnsConfigService>(NULL), This isn't exactly used much, but for consistency, might want to make it use a DnsConfigService, too. Or just have a comment about this. http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... net/base/host_resolver_impl.cc:1961: TryServingAllJobsFromHosts(); Think a comment that this won't do anything when dns_client_ is NULL would be nice, since it's not clear that this actually won't do anything, from context. Could also/alternatively add an explicit check for that in the if statement, though it's not needed for correctness. http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_impl.h File net/base/host_resolver_impl.h (right): http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... net/base/host_resolver_impl.h:215: // Attempts to serve each Job in |jobs_| from the HOSTS file. Both here and in ServeFromHosts above, think it's worth mentioning that dns_client_ (And dns_config_service_) must be non-NULL for them to do anything.
http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... File net/base/host_resolver_impl.cc (left): http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... net/base/host_resolver_impl.cc:1933: void HostResolverImpl::OnDNSChanged(unsigned detail) { On 2012/05/24 04:27:47, Matt Menke wrote: > Hmm...This does change behavior a little. We no longer abort all in progress > jobs when we can't read part of the config, and another part changes. Good point. I'm leaning towards trusting DnsConfigService to parse config and detect real changes. I'll do this in steps: first enable DnsConfigService for all and measure the fraction of requests for which it's out of service. Second, if the result is good, I'll make the complete switch from NCN::DNSObserver. WTYD? http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... File net/base/host_resolver_impl.cc (right): http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... net/base/host_resolver_impl.cc:482: scoped_ptr<DnsConfigService>(NULL), On 2012/05/24 04:27:47, Matt Menke wrote: > This isn't exactly used much, but for consistency, might want to make it use a > DnsConfigService, too. Or just have a comment about this. Good point. Considering that this is only used by ConnectionTester, would it make sense to convert it to: CreateHostResolverForConnectionTesting(/* no parameters */)? http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... net/base/host_resolver_impl.cc:1961: TryServingAllJobsFromHosts(); On 2012/05/24 04:27:47, Matt Menke wrote: > Think a comment that this won't do anything when dns_client_ is NULL would be > nice, since it's not clear that this actually won't do anything, from context. > Could also/alternatively add an explicit check for that in the if statement, > though it's not needed for correctness. If it's not obvious that this requires DnsClient, I'll move the check from within to here and add a DCHECK there.
I went back to OnDNSChange and added a UMA to asses how good DnsConfigService is. PTAL.
I'll get to this tonight. On Mon, May 28, 2012 at 9:23 PM, <[email protected]> wrote: > I went back to OnDNSChange and added a UMA to asses how good > DnsConfigService > is. PTAL. > > http://codereview.chromium.**org/10334009/<http://codereview.chromium.org/103... >
Looks pretty good, just some minor comments. http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... File net/base/host_resolver_impl.cc (right): http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... net/base/host_resolver_impl.cc:482: scoped_ptr<DnsConfigService>(NULL), On 2012/05/25 22:10:23, szym wrote: > On 2012/05/24 04:27:47, Matt Menke wrote: > > This isn't exactly used much, but for consistency, might want to make it use a > > DnsConfigService, too. Or just have a comment about this. > > Good point. Considering that this is only used by ConnectionTester, would it > make sense to convert it to: CreateHostResolverForConnectionTesting(/* no > parameters */)? The rename sounds reasonable to me, though probably want to at least take in the NetLog. http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_imp... File net/base/host_resolver_impl.cc (right): http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_imp... net/base/host_resolver_impl.cc:1438: 2); Not needed in this CL, but think it would also be nice to know where we fail: Watching DNS config, watching HOSTS, reading DNS config, reading HOSTS. Of course, how interesting that information is will depend on the no-config rate that this gives us, though may also be nice to know how often we fail when we have no config. http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_impl.h File net/base/host_resolver_impl.h (right): http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_imp... net/base/host_resolver_impl.h:216: // Attempts to serve each Job in |jobs_| from the HOSTS file if available. Still think the "if available" comments in all of these isn't terribly clear, since "available" could mean "present on the system". Also, OnDNSChanged tells us about successful HOSTS updates, which could be taken to imply a HOSTS file is available. I think "If HaveDnsConfig() is true" is a bit better, or better yet, "If we have a DnsClient with a valid DnsConfig". http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_imp... net/base/host_resolver_impl.h:259: // True if received valid config from dns_config_service_. Temporary, used to nit: |dns_config_service_| http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_imp... File net/base/host_resolver_impl_unittest.cc (right): http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_imp... net/base/host_resolver_impl_unittest.cc:1334: // Then we introduce valid DnsConfig. This comment implies we didn't have a valid one before, which is no longer true.
http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... File net/base/host_resolver_impl.cc (right): http://codereview.chromium.org/10334009/diff/27034/net/base/host_resolver_imp... net/base/host_resolver_impl.cc:482: scoped_ptr<DnsConfigService>(NULL), On 2012/05/30 03:51:50, Matt Menke wrote: > On 2012/05/25 22:10:23, szym wrote: > > On 2012/05/24 04:27:47, Matt Menke wrote: > > > This isn't exactly used much, but for consistency, might want to make it use > a > > > DnsConfigService, too. Or just have a comment about this. > > > > Good point. Considering that this is only used by ConnectionTester, would it > > make sense to convert it to: CreateHostResolverForConnectionTesting(/* no > > parameters */)? > > The rename sounds reasonable to me, though probably want to at least take in the > NetLog. Looked at ConnectionTester again and noticed that it uses custom values for |max_concurrent_resolves| and |max_retry_attempts|. I'll leave this out until I understand why. http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_imp... File net/base/host_resolver_impl.cc (right): http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_imp... net/base/host_resolver_impl.cc:1438: 2); On 2012/05/30 03:51:50, Matt Menke wrote: > Not needed in this CL, but think it would also be nice to know where we fail: > Watching DNS config, watching HOSTS, reading DNS config, reading HOSTS. > > Of course, how interesting that information is will depend on the no-config rate > that this gives us, though may also be nice to know how often we fail when we > have no config. I agree, but I'd do that as a separate UMA within DnsConfigService. Here, I would like to measure the effective fraction of time (measured in Jobs) that HostResolverImpl operates without DnsConfig. http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_impl.h File net/base/host_resolver_impl.h (right): http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_imp... net/base/host_resolver_impl.h:216: // Attempts to serve each Job in |jobs_| from the HOSTS file if available. On 2012/05/30 03:51:50, Matt Menke wrote: > Still think the "if available" comments in all of these isn't terribly clear, > since "available" could mean "present on the system". Also, OnDNSChanged tells > us about successful HOSTS updates, which could be taken to imply a HOSTS file is > available. > > I think "If HaveDnsConfig() is true" is a bit better, or better yet, "If we have > a DnsClient with a valid DnsConfig". Done. http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_imp... File net/base/host_resolver_impl_unittest.cc (right): http://codereview.chromium.org/10334009/diff/42001/net/base/host_resolver_imp... net/base/host_resolver_impl_unittest.cc:1334: // Then we introduce valid DnsConfig. On 2012/05/30 03:51:50, Matt Menke wrote: > This comment implies we didn't have a valid one before, which is no longer true. Done.
LGTM
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/10334009/49002
Try job failure for 10334009-49002 (retry) on mac_rel for step "browser_tests". It's a second try, previously, step "browser_tests" failed. http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/10334009/49002
Try job failure for 10334009-49002 (retry) on mac_rel for step "browser_tests". It's a second try, previously, step "browser_tests" failed. http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/10334009/49002
Try job failure for 10334009-49002 (retry) on mac_rel for step "browser_tests". It's a second try, previously, step "browser_tests" failed. http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...
CQ wouldn't get through mac_rel. The cause is FilePathWatcher on OS_MACOSX. http://codereview.chromium.org/10334009/diff/49002/net/base/host_resolver_imp... File net/base/host_resolver_impl.cc (right): http://codereview.chromium.org/10334009/diff/49002/net/base/host_resolver_imp... net/base/host_resolver_impl.cc:1560: NetworkChangeNotifier::AddDNSObserver(this); This change actually enables the DNS signals on OS_MACOSX and OS_WIN. It turns out that FilePathWatcher is very noisy on OS_MACOSX. There's an outstanding http://crbug.com/78045, so I'm not sure if we can trust it on OS_WIN either. This CL is useful without this change (DnsConfigService will receive the signals). So I moved it back into #ifdef.
https://chromiumcodereview.appspot.com/10334009/diff/49002/net/base/host_reso... File net/base/host_resolver_impl.cc (right): https://chromiumcodereview.appspot.com/10334009/diff/49002/net/base/host_reso... net/base/host_resolver_impl.cc:1560: NetworkChangeNotifier::AddDNSObserver(this); On 2012/05/31 18:44:10, szym wrote: > This change actually enables the DNS signals on OS_MACOSX and OS_WIN. It turns > out that FilePathWatcher is very noisy on OS_MACOSX. There's an outstanding > http://crbug.com/78045, so I'm not sure if we can trust it on OS_WIN either. > > This CL is useful without this change (DnsConfigService will receive the > signals). So I moved it back into #ifdef. Hmm...So we should probably also be gathering metrics on frequency of DNS changes as well, at some point. Even if we get smart enough to ignore them, they can result in significant resource usage. It's also not entirely clear how best to histogram them. A system may get a bunch of notices in a row when someone's changing networks, and then not get one for days.
Right. If the AsyncDNS.HaveDnsConfig histogram looks good, I will remove HostResolverImpl::OnDNSChanged, so DnsConfigService will be in charge of filtering spurious signals. But even then, we don't want DnsConfigService to spin reading the HOSTS file if it didn't actually change. On 2012/05/31 18:56:15, Matt Menke wrote: > https://chromiumcodereview.appspot.com/10334009/diff/49002/net/base/host_reso... > File net/base/host_resolver_impl.cc (right): > > https://chromiumcodereview.appspot.com/10334009/diff/49002/net/base/host_reso... > net/base/host_resolver_impl.cc:1560: > NetworkChangeNotifier::AddDNSObserver(this); > On 2012/05/31 18:44:10, szym wrote: > > This change actually enables the DNS signals on OS_MACOSX and OS_WIN. It turns > > out that FilePathWatcher is very noisy on OS_MACOSX. There's an outstanding > > http://crbug.com/78045, so I'm not sure if we can trust it on OS_WIN either. > > > > This CL is useful without this change (DnsConfigService will receive the > > signals). So I moved it back into #ifdef. > > Hmm...So we should probably also be gathering metrics on frequency of DNS > changes as well, at some point. Even if we get smart enough to ignore them, > they can result in significant resource usage. > > It's also not entirely clear how best to histogram them. A system may get a > bunch of notices in a row when someone's changing networks, and then not get one > for days.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/[email protected]/10334009/53002
Change committed as 139892 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
