May 7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#24123 (verxkgiicjmcnxg): view internal: query: verxkgiicjmcnxg IN A + (1.1.1.1)
May 7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#29159 (epqoaqsayo): view internal: query: epqoaqsayo IN A + (1.1.1.1)
May 7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#27411 (qlllglwcjglu): view internal: query: qlllglwcjglu IN A + (1.1.1.1)
到某些Windows恶意软件。但是，最近我开始注意到它也来自Linux和Mac客户端。再次，我认为这可能是由于某些恶意的浏览器插件造成的。 // net-internals /＃dns，我在Chrome DNS统计信息页面中发现了类似的请求。
我的Chrome浏览器安装了相当无害的插件，并且没有明显的恶意软件迹象。
我真心怀疑这是否应该是恶意活动。
（发生在图中，如pnxcygqqemww，ryzypwbheguutkd和Chrome发出的snplueo DNS名称请求所示。）。
开启Chrome浏览器时，嗅探DNS活动，方法如下：
sudo tcpdump -n port 53
我能够看到以下DNS请求，以及10:20的随机请求： 34：
打开Chrome浏览器：
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
10:20:27.119736 IP 1.1.1.2.12568 > 1.1.1.1.53: 10990+ A? apis.google.com. (33)
10:20:27.119962 IP 1.1.1.2.34930 > 1.1.1.1.53: 13828+ A? disconnect.me. (31)
10:20:27.120078 IP 1.1.1.2.17860 > 1.1.1.1.53: 37420+ A? mxr.mozilla.org. (33)
10:20:27.120314 IP 1.1.1.1.53 > 1.1.1.2.12568: 10990 2/4/4 CNAME plus.l.google.com., A 216.58.214.174 (206)
10:20:27.120479 IP 1.1.1.1.53 > 1.1.1.2.34930: 13828 3/4/8 A 54.197.255.152, A 54.225.94.202, A 204.236.239.134 (339)
10:20:27.120666 IP 1.1.1.1.53 > 1.1.1.2.17860: 37420 1/4/5 A 63.245.215.42 (234)
10:20:27.123394 IP 1.1.1.2.51642 > 1.1.1.1.53: 58375+ A? ssl.gstatic.com. (33)
10:20:27.123658 IP 1.1.1.2.17933 > 1.1.1.1.53: 48570+ A? www.google.pt. (31)
10:20:27.123726 IP 1.1.1.1.53 > 1.1.1.2.51642: 58375 1/4/4 A 216.58.214.163 (192)
10:20:27.123897 IP 1.1.1.2.57779 > 1.1.1.1.53: 7559+ A? www.gstatic.com. (33)
10:20:27.123946 IP 1.1.1.1.53 > 1.1.1.2.17933: 48570 1/4/4 A 216.58.207.163 (193)
10:20:27.124192 IP 1.1.1.1.53 > 1.1.1.2.57779: 7559 16/4/4 A 194.210.238.166, A 194.210.238.170, A 194.210.238.174, A 194.210.238.176, A 194.210.238.177, A 194.210.238.181, A 194.210.238.185, A 194.210.238.187, A 194.210.238.144, A 194.210.238.148, A 194.210.238.152, A 194.210.238.154, A 194.210.238.155, A 194.210.238.159, A 194.210.238.163, A 194.210.238.165 (432)
10:20:27.432926 IP 1.1.1.2.29865 > 1.1.1.1.53: 62300+ A? clients4.google.com. (37)
10:20:27.433219 IP 1.1.1.2.28193 > 1.1.1.1.53: 23734+ A? translate.googleapis.com. (42)
10:20:27.433703 IP 1.1.1.1.53 > 1.1.1.2.29865: 62300 2/4/4 CNAME clients.l.google.com., A 216.58.211.238 (213)
10:20:27.464772 IP 1.1.1.1.53 > 1.1.1.2.28193: 23734 1/4/4 A 216.58.198.202 (201)
10:20:28.430622 IP 1.1.1.2.46792 > 1.1.1.1.53: 1963+ A? accounts.google.com. (37)
10:20:28.431046 IP 1.1.1.1.53 > 1.1.1.2.46792: 1963 1/4/4 A 216.58.201.141 (189)
10:20:32.348765 IP 1.1.1.2.16654 > 1.1.1.1.53: 39847+ A? www.google.com. (32)
10:20:32.349362 IP 1.1.1.1.53 > 1.1.1.2.16654: 39847 1/4/4 A 216.58.213.164 (184)
几秒钟后，上述随机DNS请求确实出现了：
10:20:34.159229 IP 1.1.1.2.5042 > 1.1.1.1.53: 47676+ A? kblxfid.xxx.xxx.xxx. (44)
10:20:34.159829 IP 1.1.1.2.63360 > 1.1.1.1.53: 55094+ A? weefjmw.xxx.xxx.xxx. (44)
10:20:34.159893 IP 1.1.1.1.53 > 1.1.1.2.5042: 47676 NXDomain* 0/1/0 (104)
10:20:34.160230 IP 1.1.1.1.53 > 1.1.1.2.63360: 55094 NXDomain* 0/1/0 (104)
10:20:34.160872 IP 1.1.1.2.29339 > 1.1.1.1.53: 22434+ A? luebcanqpumlaj.xxx.xxx.xxx. (51)
10:20:34.161290 IP 1.1.1.1.53 > 1.1.1.2.29339: 22434 NXDomain* 0/1/0 (111)
10:20:34.162489 IP 1.1.1.2.64592 > 1.1.1.1.53: 49055+ A? kblxfid.xxx.xxx.xxx. (44)
10:20:34.162859 IP 1.1.1.1.53 > 1.1.1.2.64592: 49055 NXDomain* 0/1/0 (104)
10:20:34.164105 IP 1.1.1.2.50225 > 1.1.1.1.53: 1276+ A? weefjmw.xxx.xxx.xxx. (44)
10:20:34.164386 IP 1.1.1.2.52389 > 1.1.1.1.53: 59022+ A? luebcanqpumlaj.xxx.xxx.xxx. (51)
10:20:34.164472 IP 1.1.1.1.53 > 1.1.1.2.50225: 1276 NXDomain* 0/1/0 (104)
10:20:34.164751 IP 1.1.1.1.53 > 1.1.1.2.52389: 59022 NXDomain* 0/1/0 (111)
在Chrome中打开新标签页：
10:20:44.106915 IP 1.1.1.2.26171 > 1.1.1.1.53: 14460+ A? clients2.google.com. (37)
10:20:44.139387 IP 1.1.1.1.53 > 1.1.1.2.26171: 14460 2/4/4 CNAME clients.l.google.com., A 216.58.211.238 (213)
根据@Gilles链接，使用代理时（ Squid）在Chrome中，当Chrome启动时，您可以在相应的Squid
access.log日志文件中看到随机DNS名称：1494276554.709 216 127.0.0.1 TCP_MISS/504 277 HEAD http://vgifrooogs/ - DIRECT/vgifrooogs text/html
1494276554.731 238 127.0.0.1 TCP_MISS/504 277 HEAD http://cbwknhka/ - DIRECT/cbwknhka text/html
1494276554.875 382 127.0.0.1 TCP_MISS/504 277 HEAD http://vtjhiag/ - DIRECT/vtjhiag text/html
#1 楼
我发现了一系列有关Chrome发出的随机DNS请求的帖子/错误报告。结论是，随机DNS请求既不是由恶意软件生成的，也不是由插件或附加组件生成的。请求是由Chrome完成的，以了解它是否可以处理从其地址栏中进行的搜索。
如果您输入单字搜索查询，chrome需要发送DNS
请求以检查它是否可能是单字主机名：对于
/>例如，“测试”可能是对“测试”的搜索，或者是对
“ http：// test”的导航。如果查询最终成为主机，则chrome会显示一个
信息栏，询问“您是否打算去'测试'”。出于性能原因，DNS查询需要异步。
现在，某些ISP开始显示不存在的域名的广告（
http://en.wikipedia.org/wiki/DNS_hijacking），这意味着Chrome浏览器将始终显示每个单字查询的信息栏。由于这很烦人，因此chrome现在会在启动时发送三个随机DNS请求，并且
如果它们都解析了（我认为是同一个IP），它现在知道不显示
您的意思是“信息栏，用于将
解析为该IP的单字查询。
超出Wikipedia条目中提到的ISP级别或恶意软件DNS劫持之外，某些付费无线网络访问点或强制门户也会劫持DNS。随机请求是按照看似随机的间隔进行的，而不仅仅是在启动Chrome时。至少在每次当前网络接口获得新的IP地址时，它们都会发生。
这里是@Gilles中与主题相关的另一个链接：来自Chrome的不寻常的HEAD请求指向废话URL。因此，向该问题添加了代理测试设置的主题。您最终会看到代理日志，因为配置代理后，请求是通过代理发出的；并且，由代理来解析DNS请求。
由于缺少在线上的详细信息，我使用以下命令下载并仔细阅读了Chromium源代码。
git clone https://chromium.googlesource.com/chromium/src
以下引用摘自Chromium源代码注释：
因为可以在启动过程中调用此函数，所以当启动
URL提取会占用20 ms的时间时，我们会延迟7秒钟，这是希望足够长的时间才能启动，但仍然可以快速返回结果。如果至少有两个重定向到相同的主机名，则表明ISP正在劫持NXDOMAIN，并且多功能框
在确定是否以提示方式提示用户时应将类似的重定向导航视为“失败”信息栏“
是您要导航的”
，用于某些搜索输入。生成一个7到15个字符的随机主机名。
我的结论是，这些随机DNS请求名不是恶意软件行为的表现；他们是Chromium（和Google Chrome）至少可以进行搜索的探针，以了解其功能。有关此功能的逻辑可以在文件
src/chrome/browser/intranet_redirect_detector.cc和src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc中找到。以下是
src/chrome/browser/intranet_redirect_detector.cc的摘录： .... 下面是文件
src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc的摘录：void IntranetRedirectDetector::FinishSleep() {
in_sleep_ = false;
// If another fetch operation is still running, cancel it.
fetchers_.clear();
resulting_origins_.clear();
const base::CommandLine* cmd_line = base::CommandLine::ForCurrentProcess();
if (cmd_line->HasSwitch(switches::kDisableBackgroundNetworking))
return;
DCHECK(fetchers_.empty() && resulting_origins_.empty());
// Create traffic annotation tag.
net::NetworkTrafficAnnotationTag traffic_annotation =
net::DefineNetworkTrafficAnnotation("intranet_redirect_detector", R"(
semantics {
sender: "Intranet Redirect Detector"
description:
"This component sends requests to three randomly generated, and "
"thus likely nonexistent, hostnames. If at least two redirect to "
"the same hostname, this suggests the ISP is hijacking NXDOMAIN, "
"and the omnibox should treat similar redirected navigations as "
"'failed' when deciding whether to prompt the user with a 'did you "
"mean to navigate' infobar for certain search inputs."
trigger: "On startup and when IP address of the computer changes."
data: "None, this is just an empty request."
destination: OTHER
}
policy {
cookies_allowed: false
setting: "This feature cannot be disabled by settings."
policy_exception_justification:
"Not implemented, considered not useful."
})");
// Start three fetchers on random hostnames.
for (size_t i = 0; i < 3; ++i) {
std::string url_string("http://");
// We generate a random hostname with between 7 and 15 characters.
const int num_chars = base::RandInt(7, 15);
for (int j = 0; j < num_chars; ++j)
url_string += ('a' + base::RandInt(0, 'z' - 'a'));
GURL random_url(url_string + '/');
std::unique_ptr<net::URLFetcher> fetcher = net::URLFetcher::Create(
random_url, net::URLFetcher::HEAD, this, traffic_annotation);
// We don't want these fetches to affect existing state in the profile.
fetcher->SetLoadFlags(net::LOAD_DISABLE_CACHE |
net::LOAD_DO_NOT_SAVE_COOKIES |
net::LOAD_DO_NOT_SEND_COOKIES |
net::LOAD_DO_NOT_SEND_AUTH_DATA);
fetcher->SetRequestContext(g_browser_process->system_request_context());
fetcher->Start();
net::URLFetcher* fetcher_ptr = fetcher.get();
fetchers_[fetcher_ptr] = std::move(fetcher);
}
}
void IntranetRedirectDetector::OnURLFetchComplete(
const net::URLFetcher* source) {
// Delete the fetcher on this function's exit.
auto it = fetchers_.find(const_cast<net::URLFetcher*>(source));
DCHECK(it != fetchers_.end());
std::unique_ptr<net::URLFetcher> fetcher = std::move(it->second);
fetchers_.erase(it);
// If any two fetches result in the same domain/host, we set the redirect
// origin to that; otherwise we set it to nothing.
if (!source->GetStatus().is_success() || (source->GetResponseCode() != 200)) {
if ((resulting_origins_.empty()) ||
((resulting_origins_.size() == 1) &&
resulting_origins_.front().is_valid())) {
resulting_origins_.push_back(GURL());
return;
}
redirect_origin_ = GURL();
}
....
// Returns true if |final_url| doesn't represent an ISP hijack of
// |original_url|, based on the IntranetRedirectDetector's RedirectOrigin().
bool IsValidNavigation(const GURL& original_url, const GURL& final_url) {
...
void ChromeOmniboxNavigationObserver::NavigationEntryCommitted(
const content::LoadCommittedDetails& load_details) {
load_state_ = LOAD_COMMITTED;
if (ResponseCodeIndicatesSuccess(load_details.http_status_code) &&
IsValidNavigation(match_.destination_url,
load_details.entry->GetVirtualURL()))
OnSuccessfulNavigation();
if (!fetcher_ || (fetch_state_ != FETCH_NOT_COMPLETE))
OnAllLoadingFinished(); // deletes |this|!
}
相关链接：混合大小写DNS请求-网络中存在恶意软件？。
稍微相关：为什么Chromium不能缓存DNS一分钟以上？
评论
@cat谢谢，因为您喜欢这个，所以您可能也想要这个unix.stackexchange.com/questions/363498/…
– Rui F Ribeiro
17年5月7日在14:17
“也有一些暗示，这些随机请求是在看似随机的时间间隔发出的，而不仅仅是在启动Chrome浏览器时发出的” –绝对正确。即使我基本上从不重启chrome，也可以在数据包日志中看到它们。
–凯文
17年5月8日在2:41
@Kevin“只要计算机的IP地址发生更改”，您的计算机就需要以看似随机的间隔与路由器续订DHCP租约，这将触发此情况。
–力争
18年7月26日在5:51
@Riking确实。我明确指出了这一点。但是，我不确定它是否在其他情况下发生。
– Rui F Ribeiro
18年7月26日在10:50
评论
从Chrome向废话URL发送HEAD异常请求请参阅Chromium Bugtracker上的以下相关问题：bugs.chromium.org/p/chromium/issues/detail?id=47262
@Pierz太棒了，谢谢！