New issue
Advanced search Search tips
Starred by 18 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2012
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

Issue 47262: Chromes startup random DNS queries tracked in, and polluting users Google Web History

Reported by, Jun 23 2010

Issue description

Chrome Version       : 6.0.437.3 (Official Build 50164) dev (additionally affecting all others)
URLs (if applicable) :
Other browsers tested: n/a

What steps will reproduce the problem?
1. Enable Web History on a Google Account, remain logged in
2. Launch Chrome (AFAIK, any version of Chrome)
3. Locate the three random DNS 'test' queries from Chrome in Web History

What is the expected result?
That Web History doesn't log these random queries from Chrome

What happens instead?
Web History records the random strings that were used in the query, consisting of random letters, 10 characters in length. Three entries appear for every launch of Chrome. (e.g. "ajqlzeehpg", "nziocqvtjx", "qshvkbdjqk")

I'm not sure exactly what Chrome is doing, however, it seems that maybe Google's "Did you mean" DNS hijacks may actually be causing the log to appear in Web History as a an actual Google Web Search on my behalf.

Please provide any additional information below. Attach a screenshot if

I finally found a post that confirms the source of the random 10 character strings in Web History; it happens to actually be another Google product, as opposed to spy-ware or some other unauthorised network activity.

From the following post on the chromium-discuss group explains the purpose of the random queries;

"If you type in a single-word search query, chrome needs to send a DNS 
request to check if this might be a single-word host name: For 
example, "test" might be a search for "test" or a navigation to 
"http://test". If the query ends up being a host, chrome shows an 
infobar that asks "did you mean to go to 'test' instead". For perf 
reasons, the dns query needs to be asynchronous. 

Now some ISPs started showing ads for non-existent domain names ( ), meaning chrome would 
always show that infobar for every single-word query. Since this is 
annoying, chrome now sends three random DNS requests at startup, and 
if they all resolve (to the same IP, I think), it now knows not to 
show the "did you mean" infobar for single-word queries that resolve 
to that IP. "

However, while it may seem like a 'smart' solution, it has issues. Whether there is some way to notify Web History not to log these queries, or just perform the ISP DNS hijack test using an alternate method (assuming there is one).

Comment 1 by, Mar 11 2011

This issue puzzled me for weeks  - I saw these queries in my Fiddler log and had no idea what they were. I had all sorts of wild theories, such as that my computer had gotten infected with a virus that was trying to connect to a master server to get commands. I finally got annoyed enough to figure out the cause and came across this bug report after a few searches. 

The bug report isn't quite accurate, at least with Chrome versions 9 or 10. Chrome sends 3 HTTP HEAD requests to random 10-letter hosts on startup; it does NOT send just DNS queries.

Anyway, if you use Fiddler, here's a snippet to add to your OnBeforeRequest method to terminate and hide these requests.

if (oSession.oRequest.headers.HTTPMethod == "HEAD" && !"."))
    oSession.oRequest.headers.Add ("X-Chrome-Issue-47262", "true");
    oSession.oRequest.FailSession(502,"Chrome  Issue 47262 ","is annoying");
    oSession["ui-hide"] = "true";

Comment 2 by, Jun 12 2011

I've also worried about those queries, and all the similar ones. Try switching your network connection, for instance to a different Wi-Fi AP. I see at least three sets of "A Record" standard queries, repeated twice each time for each of the three Google random hostnames, and duplicated for ipv4 and ipv6. On top of that there are at least ten sets of LLMNR A queries for each of the three names for ipv4 and ipv6, plus maybe ten sets of Windows NBNS queries for each name. NBNS is also looking for TALK.GOOGLE.COM, so maybe not all of this is due to Chrome itself. I do have the Google Talk plugin installed. 

I never see any of this in my browser history. I use OpenDNS and set it _not_ to reply to unknown queries with their search page - maybe that prevents history logging? 

This is the first clue I've been able to find that all this traffic is (probably) expected and not harmful. If Google could promote some user-level resource for people to discover such things, we wouldn't be in here bothering the developers...

Comment 3 by, Jun 24 2011

Labels: -Area-Undefined Area-Internals
+thakis, who seems to know about this.

Comment 4 by, Jun 27 2011

Labels: Feature-Privacy
pkasting implemented this I believe. I guess there's some header we can set to tell the google web history to not store these? Actually, we shouldn't send cookies with these requests, so they shouldn't show up in the web history at all?

+jochen for privacy

Comment 5 by, Jun 27 2011

Owner: ----
If we shouldn't send cookies with these, that's an easy flag to throw when constructing the URLFetcher requests.  But I don't know the other consequences of that, e.g. perhaps we will get different behavior from these cookie-less requests to the ISP than we do for standard searches that do send cookies.

Furthermore, I'm confused as to how these HEAD requests are ending up in web history at all.  AFAIK web history can only track your searches and pages visited from them unless you are using a browser that can run toolbar, which can hook deeper into the network stack.  Because Chrome doesn't support toolbar I don't know how Google would be seeing that it's performing network requests in the background to begin with.  I have no idea whom to ask about this.

Comment 6 by, Jun 28 2011

Something doesn't compute here...  I never see HEAD requests when starting Chrome. Just tried it again, and the only HTTP at all was two packets of the YoLink extension checking in. As I said above, I see DNS, LLMNR, and NBNS queries. As in the attached Wireshark capture. If you look through it, you see most of the activity is extensions, like Google Talk and LastPass. It isn't until packet 153 that you see the random queries. No HTTP involved. Where would you expect me to see the HEAD requests? 

As for how they get into history, as the original poster mentioned, many DNS servers now respond to unknown queries with a web page of "suggestions" or more likely useless ads. Presumably Chrome knows the user didn't originate those queries, and ignores the web pages (users would be screaming if it didn't), but maybe under some circumstance they get logged to history? 

Can my experience be so different from yours?
Chrome 13.0.782.32 (Official Build 89955) beta-m startup on Win7.pcap
49.5 KB Download

Comment 7 by, Jun 28 2011

@Loren, I see the three HEAD requests; they occur about 5 seconds after starting Chrome. My startup page is blank and I have no extensions installed. The contents of one of the HEAD requests is below; the other are identical except for the name of the host:

HEAD http://jdfhjnmlcx/ HTTP/1.1
Host: jdfhjnmlcx
Proxy-Connection: keep-alive
Content-Length: 0
User-Agent: Mozilla/5.0 (Windows NT 5.2) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.100 Safari/534.30
Accept-Encoding: gzip,deflate,sdch

Comment 8 by, Jun 28 2011

My apologies if this is getting too far off-topic...  

I'm not familiar with how using a proxy affects what goes out on "the wire". I see that Fiddler installs as a proxy server, and at 
I see an example of its response to a HEAD request:
HTTP/1.1 502 Fiddler - DNS Lookup Failed
Content-Type: text/html
Connection: close
Timestamp: 08:15:45.283

Fiddler: DNS Lookup for xqwvykjfei failed. No such host is known

So presumably if a Fiddler user captured the interaction of Fiddler with the external Internet, they would see the DNS queries instead of the HEAD requests. 

At <>
they say:
   In some cases a client does not have a DNS service available that
   will properly resolve the domain name, even if it actually is
   registered with an IP address.  This is usually the case when the
   client is located on an isolated network whose only access to the
   outside network is through an HTTP proxy.  In such cases, when the
   client would use a proxy to retrieve resources, the client can use an
   alternative validation method by performing an HTTP HEAD request
   instead of a DNS request to the full-domain in order to determine its
   status as a valid domain.

So am I correct that the fact of the Fiddler proxy being installed in the path to the outside world changes the behavior of Chrome, so it uses the HEAD requests instead of direct DNS lookups? I would expect my situation with no proxy involved is more common. But then why are the Google people talking only about sending HEAD requests instead of making direct DNS queries? Maybe "URLFetcher" is an earlier abstraction layer that looks for proxies and decides whether to use DNS or HEAD? 

At <>
they explain where the rest of what I see comes from - Windows:
When a single-label, unqualified name needs to be resolved, a computer running Windows Vista [or Win7] that is using both IPv6 and IPv4 (the default configuration) will do the following:

Perform normal DNS resolution by combining the single-label name with the primary DNS suffix of the computer and sending a DNS Name Query Request message to its DNS server. Windows Vista performs additional DNS queries as needed based on name devolution or additional search suffixes that have been configured.

If DNS name resolution is not successful (for example, the DNS server returns an RCODE=3), send up to two sets of multicast LLMNR Name Query Request messages over both IPv6 and IPv4.

If LLMNR name resolution is not successful and NetBT is enabled, broadcast up to three NetBIOS Name Query Request messages.

If the name being resolved is not a single-label name (or a hostname.local name), LLMNR and NetBT are not used. 

Apparently because the Google random requests do not include a .TLD, they trigger this gross expansion of queries by current versions of Windows. 

(Curiosity at least temporarily sated...)

Comment 9 by, Jun 28 2011

This is all way off-topic.  The only useful thing right now is information on how and why these sorts of requests could ever make it into Google Web History.  This isn't a bug for a general discussion of what requests Chrome makes, how, why, how they're transformed by proxies, how Windows satisfies them, etc. -- that all just distracts from taking any action here.

Comment 10 by, Jun 29 2011

I agree the original issue was limited to "pollution of history". But since you don't have any theory of how that could be happening, it seems exploration of the responses of other users' machines might be useful. 

If you'd like to keep this bug number strictly limited, could you duplicate it with a new number dedicated to the "startup random DNS queries" issues? If you explore a bit you'll see lots of users worried that they have acquired some mysterious malware, and expending lots of energy and forum space trying to figure out where the random queries come from. That seems to me to be a serious problem with Chrome, which is much more significant and thoroughly documented than the history pollution part.  

I could open a new bug, and copy/paste this one into it, but I understand you have much better tools for doing such things. Please?

Comment 11 by, Jun 29 2011

Making DNS queries is an inherent part of making HEAD requests.  It is not a bug and we have no plans to change it.  We can respond to user issues on our help forums.

Comment 12 by, Jun 13 2012

I randomly discovered this bug when doing a search for LLMNR. Was the issue with the search history ever resolved/reproed? 

Also agree that the discussion about DNS/LLMNR/NetBT is off-topic here.

Comment 13 by, Jun 13 2012

Status: WontFix
I don't think we ever confirmed this.

I don't know how these would have made it into the user's web history in the first place unless someone had some network configuration that somehow redirected these to Google and preserved cookies sent with the request.

However, as of March 2012, we don't send cookies with these requests either.  So even in that scenario it should now be impossible to pollute Web History.

Given this, I'm going to close as "no longer possible to reproduce".

Comment 14 by, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 15 by, Mar 10 2013

Project Member
Labels: -Area-Internals -Feature-Privacy Cr-Internals Cr-Privacy

Sign in to add a comment