I have noticed unusual traffic coming from my workstation the last couple of days. I am seeing HEAD requests sent to random character URLs, usually three or four within a second, and they appear to be coming from my Chrome browser. The requests repeat only three or four times a day, but I have not identified a particular pattern. The URL characters are different for each request.

Here is an example of the request as recorded by Fiddler 2:

HEAD http://xqwvykjfei/ HTTP/1.1
Host: xqwvykjfei
Proxy-Connection: keep-alive
Content-Length: 0
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

The response to this request is as follows:

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

I have been unable to find any information through Google searches related to this issue. I do not remember seeing this kind of traffic before late last week, but it may be that I just missed it before. The one modification I made to my system last week that was unusual was adding the Delicious add-in/extension to both IE and Chrome. I have since removed both of these, but am still seeing the traffic. I have run virus scan (Trend Micro) and HiJackThis looking for malicious code, but I have not found any.

I would appreciate any help tracking down the source of the requests, so I can determine if they are benign, or indicative of a bigger problem. Thanks.

3 Answers 3


This is actually legitimate behaviour. Some ISPs improperly respond to DNS queries to non-existent domains with an A record to a page that they control, usually with advertising, as a "did you mean?" kind of thing, instead of passing NXDOMAIN as the RFC requires. To combat this, Chrome makes several HEAD requests to domains which cannot exist to check how the DNS servers resolve them. If they return A records, Chrome knows to perform a search query for the host instead of obeying the DNS record so that you are not affected by the ISPs improper behaviour. [1]

  • 4
    @Jacob: Almost always, in my experience anyway, if you call up business support and kick and scream for a while, they'll give you another set of upstream DNS servers that don't have that "feature" enabled. I know that Verizon and One Communications both have alternate servers, though they go out of their way not to advertise them.
    – Scrivener
    Feb 14, 2011 at 16:33
  • 3
    I'm glad to find out this is not some strange infestation on my machine. Thanks for the informative answer. Feb 14, 2011 at 18:46
  • 6
    @Jacob: You didn't hear this from me, and it might not the same for you as it was for me, but... changing the last octet of the DNS server from .12 to .14 removes the "DNS assistance feature".
    – Scrivener
    Feb 14, 2011 at 19:29
  • 5
    It would be nice if that was documented. Like, really nice.
    – chiggsy
    May 8, 2011 at 17:34
  • 5
    Would have been much nicer of them to embed chrome_dns_test in the URL. To the pessimistic, it looks like a virus ping.
    – crokusek
    Sep 10, 2014 at 22:06

In working with Microsoft regarding this issue and how IE9 behaves, we have found information from Verizon in how to opt out of this service. They call it "DNS Assistance". In working with another user on this issue who has BrightHouse ISP in FL,they have the same thing going on. But, they too, provide information on how to opt out of this service. I like how they call it a service. :)


Another possibility "could have been trojans checking to see if they're running in a VM" -- If those fake domains 'connect' because of the VM trying to record packets, the trojan will self-terminate.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .