从 PIXIV 事件再谈 DNS 的解析

老鼠就不要对一只猫的仁慈抱有希望,尤其是那只猫曾经是老鼠 ——题记

写在前面

阅读本文可能需要关于 DNS 的基本知识,权威 DNS 和递归解析过程等参见先前的文章:浅谈 DNS 的解析

9月18日上午,各大社交网络开始盛传著名二次元同人画作社区 黄图网站 PIXIV 在大陆无法访问,各种说法甚嚣尘上,有说 P 站自主规制的,有说 P 站被墙的,也有认为是网络抽风的,实际上这个问题要判断到底是哪边的问题是比较简单的,所谓实践出真知,让我们来试着判断一下 P 站为什么会无法访问

关于 P 站情况的分析

首先来看看国内访问是什么情况:

mainland# dig pixiv.net @a.root-servers.net.

// 在不知道一个域名的权威的前提下,直接向 root server 查询是避免缓存影响的最直接办法

;; QUESTION SECTION:
;pixiv.net.         IN  A

;; ANSWER SECTION:
pixiv.net.      126 IN  A   243.185.187.39

;; Query time: 23 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Tue Sep 19 02:12:42 2017
;; MSG SIZE  rcvd: 43

这个响应有哪里不对呢?

  1. 向根服务器查询响应时间只有 23ms,你信吗(`dig @` 会直接向指定 name server 查询,不受本地 DNS 设置影响,大陆往返根域名服务器是不可能在 23ms 内完成的)
  2. 对一个域名的根域(没有前缀的裸域名)查询 A 记录,如果所查 server 是对应域的权限,则不仅会有根域的 A 记录还会有胶水记录,如果所查的 server 不是对应域的权威,则返回授权记录(AUTHORITY SECTION)告知下一步查询的 server,这种不符合协议要求的响应很可能是伪造的,关于域的授权和胶水记录和本文主要内容无关,可以参考鸟哥或自行搜索
  3. 这个 IP 是 RFC 规定的保留地址,理论上不会有任何路由器有指向它的路由,除非日本人脑子抽风,否则这个 IP 不应该出现在 DNS 解析结果里

我们来看一看正常的查询结果:

# dig baidu.com @a.root-servers.net.

;; QUESTION SECTION:
;baidu.com.         IN  A

;; AUTHORITY SECTION:
com.            172800  IN  NS  a.gtld-servers.net.
// 授权记录和胶水记录

;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800  IN  A   192.5.6.30

// 忽略部分输出减少篇幅

# dig baidu.com @ns4.baidu.com

;; QUESTION SECTION:
;baidu.com.         IN  A

;; ANSWER SECTION:
baidu.com.      600 IN  A   123.125.114.144
// 正常 A 记录返回

;; AUTHORITY SECTION:
baidu.com.      86400   IN  NS  ns4.baidu.com.

// 授权记录和胶水记录

;; ADDITIONAL SECTION:
ns4.baidu.com.      86400   IN  A   220.181.38.10

那么显然,P 站域名的响应是被劫持了的,尝试使用 TCP 解析:

mainland# dig pixiv.net @a.root-servers.net. +tcp
communications error to 198.41.0.4#53: connection reset

相信即使是不了解网络的人也很熟悉 connection reset 的梗了,不多解释

那么为了得到正确的解析结果,我们找来一台日本的 VPS 来查询(使用日本 IP 可以证伪所谓的“P 站屏蔽海外 IP”的说法,经过多次试验表明随便一台 VPS 只要没有受到错误的 DNS 缓存影响,解析结果和客户端 IP 无关,P 站根本没有 CDN 或是 DNSGSLB 这种东西):

outsea# dig +trace +tcp pixiv.net @a.root-servers.net. 

// 忽略模拟递归时的输出

pixiv.net.      240 IN  A   210.129.120.44
pixiv.net.      240 IN  A   210.129.120.41
pixiv.net.      240 IN  A   210.129.120.43
pixiv.net.      240 IN  NS  ns1.pixiv.net.
pixiv.net.      240 IN  NS  ns2.pixiv.net.

outsea# dig ns1.pixiv.net ns2.pixiv.net

;; QUESTION SECTION:
;ns1.pixiv.net.         IN  A
;; ANSWER SECTION:
ns1.pixiv.net.      239 IN  A   210.129.120.60

;; QUESTION SECTION:
;ns2.pixiv.net.         IN  A
;; ANSWER SECTION:
ns2.pixiv.net.      239 IN  A   210.129.120.62</pre>

我们现在拿到了正确的 P 站 IP,还拿到了 P 站的 NS( pixiv.net 域的权威 DNS 服务器),在海外尝试使用 TCP 解析:

outsea# dig pixiv.net @210.129.120.62 +tcp

;; QUESTION SECTION:
;pixiv.net.         IN  A

;; ANSWER SECTION:
pixiv.net.      240 IN  A   210.129.120.44
pixiv.net.      240 IN  A   210.129.120.43
pixiv.net.      240 IN  A   210.129.120.41

;; AUTHORITY SECTION:
pixiv.net.      240 IN  NS  ns2.pixiv.net.
pixiv.net.      240 IN  NS  ns1.pixiv.net.

;; ADDITIONAL SECTION:
ns1.pixiv.net.      240 IN  A   210.129.120.60
ns2.pixiv.net.      240 IN  A   210.129.120.62

一切看起来都很完美,没有伪造的响应,没有 RESET

所以 P 站到底怎么了?

TL;DR:

  • 大陆境内 UDP 查询会收到伪造响应
  • 大陆境内 TCP 查询会被 Reset
  • 境外对权威和根服务器查询得到的响应一切正常

综上所述有很大把握认为问题不出在 P 站自身而是 GFW

所以我该怎么访问 PIXIV?

对于仅仅是 DNS 污染这样的单一封锁手段,应对方式不少,也比较简单

  1. 使用抗污染 DNS 比如中科大的202.141.162.123(但是注意,DNSGSLB 的工作原理决定了使用这个 DNS 可能会导致你在访问正常网站的时候被调度到教育网的 CDN 节点)
  2. 修改自己的 hosts 文件,参见 pixiv-hosts on github,简单的讲遇到打不开的时候浏览器 F12 看一眼哪个请求失败,找个境外机器查一下 DNS 就行(简单粗暴但是不适用移动设备,且可能有时效性问题。
  3. 挂梯子,使用远程解析(适合移动设备,但是要求你有一个大流量的梯子)
  4. 自建 DNS 并进行分流(大概会做这个的也不需要我提醒了)

关于 DNS 污染的讨论

有趣的是,关于 DNS 污染,方校长有一篇06年的老论文,文中陈述了 DNS 污染的基本原理和基本防范手法,其中有一段印证了我们讨论的判断 DNS 污染的一个猜想:

欺骗应答包一般来说比较简单,通常只有一个应答域。这也正符合欺骗攻击者要尽快将欺骗数据包返回给客户端的初衷。而合法应答包的信息则比较丰富,除了可能有多个应答域之外,通常还带有授权域、附加记录域等

当前的 GFW 的 DNS 污染模式几乎和方校长描述的完全一致

西厢计划 GFW 技术评论 基于这篇论文进行了对 GFW 的 DNS 污染行为模式的研究,这么多年过去了 GFW 的几个基本行为模式依旧是当年模样,另外方校长提到的贝叶斯分类器在今天应该可以使用机器学习等方式进行分析,想必是一个有趣的事情

关于此次事件的一些讨论

“pixiv 十周年所以屏蔽了国外 IP”是不是真的

假的,这个说法的最广为流传的所谓证据应该是微博上的一张图:

V2EX也有讨论具体最早是不是这里我没查。

这个截图应该是搬瓦工家的 ping.pe,这类工具一般是用于测量某个网络到另一个网络的路由和延迟,对于某个特定网站和机器,ping 几乎不能说明任何问题,其一因为 ICMP 不是可靠协议且没有任何完整性和有效性保护,并不适合作为最终的判断依据,其二是生产环境服务器关闭了 ICMP 响应的情况是很常见的

magami 说的缓存是不是真的?

假的,向权威和根服务器查询是不会受缓存影响的(除非存在运营商劫持,但是实际上和墙是一个原理)

当然你要说他是真不懂还是鉴于岛风 go 的性质在装傻,这就只有他自己知道了

这么热闹的事情为什么这么久才说呢

因为白天太懒,关于 DNS 其实还是有很多可以讲的,需要一点时间

后记

每每有网站被墙,各大社交网站上总会有一场或大或小的争吵,药丸党和自有国情党慷慨激昂互问候家属。我相信中国自有国情在此,然而我不想看到猫捉老鼠的游戏里老鼠还会内斗,我希望看到这种事情出现的时候,更多的人能身体力行的去判断而不是在社交网站以讹传讹,甚至是直接宣扬王境泽式的“还是墙内网站香”、“XXXX活该被封”

你不能决定这个国家,但是你可以决定自己怎么想、怎么做

UPDATE 2017.09.20 雅虎日本紧接着被墙,sigh


本文链接:https://www.starduster.me/2017/09/19/from-pixiv-to-dns/
本站基于 Creactive Commons BY-NC-SA 4.0 License 允许并欢迎您在注明来源和非商业使用前提下自由地对本文进行复制、分享或基于本文进行创作。
请注意:受限于笔者水平,本站内容可能存在主观臆断或事实错误,文中信息也可能因时间推移而不再准确,在此提醒读者结合自身判断谨慎地采纳。

11 条评论




  1. 这次还算好的了,仅仅是污染了dns,没有ban掉ip
    台式机直接改hosts方便快捷
    移动端在台式机那挂了个CentOS虚拟机弄了个dns,现在在手机也能上网页版的了
    但是pixiv app仍无法加载,猜测是app端用的入口不一样
    本来想着用抓包工具分析下地址的,可是不知道linux下的抓包工具还有哪些
    索性直接装个squid,手机设置http代理
    查看日志后发现有这两个关键的地址:
    app-api.pixiv.net
    oauth.secure.pixiv.net
    在bing上搜了下得知为210.129.120.41
    直接写入dns的区域文件里,重启服务
    这样app端也能登上去了

    回复

    1. 我倒是觉得手机上改hosts比直接翻墙麻烦,至少对iPhone是这样的,所以客户端我都直接 *.pixiv 走代理出了

      回复

  2. 今天挂着SS都登不了日本雅虎了。。。

    回复

  3. 可能是我孤陋寡闻了,根服务器可以直接用来查询吗?我记得不是不可以的吗?

    回复

    1. 客户端的请求发到缓存服务器,缓存代为向权威查询,没有权威的记录就会往根去,你跳过缓存这一步直接请求递归结果就是直接往根查的,说白了还是因为DNS是一个分级系统,根不是不返回结果而是只返回下一级的域

      回复

  4. 请问查了dns后该怎么做(;´༎ຶД༎ຶ`)

    回复

回复 千千 取消回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据