OpenDNS和Google DNS，不一定真的适合我们

为什么不用？用了解析速度快，能防ISP劫持，能翻墙，能这能那。真的是这样吗？

1.大家最关注的，翻墙，防止DNS被劫持。

资深不资深的玩家肯定都知道某墙的事情。用了OpenDNS之类后，真的能防止被某墙劫持域名吗？恐怕太小看某墙了吧。只要是DNS的UDP包经过旁路设备，直接就会被篡改。不信？看看结果

正常请求一个被劫持的域名，当然是劫持没商量了

$ dig hen.bao.li 
; <<>> DiG 9.6.0-APPLE-P2 <<>> hen.bao.li 
;; global options: +cmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50859 
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION: ;hen.bao.li. IN A 
;; ANSWER SECTION: hen.bao.li. 85697 IN A 78.16.49.15 
;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) 
;; WHEN: Mon Dec  7 23:18:48 2009 
;; MSG SIZE  rcvd: 44

$ dig hen.bao.li
; <<>> DiG 9.6.0-APPLE-P2 <<>> hen.bao.li
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50859
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;hen.bao.li. IN A
;; ANSWER SECTION:
hen.bao.li. 85697 IN A 78.16.49.15
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec  7 23:18:48 2009
;; MSG SIZE  rcvd: 44

然后再看用了Google Public DNS后，照样劫持你没商量

$ dig @8.8.8.8 hen.bao.li 
; <<>> DiG 9.6.0-APPLE-P2 <<>> @8.8.8.8 hen.bao.li 
; (1 server found) 
;; global options: +cmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15485 
;; flags: qr aa rd ra
; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION: ;hen.bao.li. IN A 
;; ANSWER SECTION: hen.bao.li. 86400 IN A 78.16.49.15 
;; Query time: 75 msec 
;; SERVER: 8.8.8.8#53(8.8.8.8) 
;; WHEN: Mon Dec  7 23:20:58 2009 
;; MSG SIZE  rcvd: 54

我们看看国外机器得出的真实结果

# dig @8.8.8.8 hen.bao.li 
; <<>> DiG 9.3.4-P1 <<>> @8.8.8.8 hen.bao.li 
; (1 server found) 
;; global options:  printcmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20845 
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION: ;hen.bao.li. IN A 
;; ANSWER SECTION: hen.bao.li. 14400 IN A 69.163.142.44 
;; Query time: 252 msec 
;; SERVER: 8.8.8.8#53(8.8.8.8) 
;; WHEN: Mon Dec  7 23:25:12 2009 
;; MSG SIZE  rcvd: 44

可以看到，此路不通。想靠换国外DNS来翻墙的可以醒醒了。 2.解析速度快 Google DNS解析速度是挺快的，但OpenDNS就未必了

$ dig @208.67.222.222 http://www.dnspod.com 
; <<>> DiG 9.6.0-APPLE-P2 <<>> @208.67.222.222 http://www.dnspod.com 
; (1 server found) 
;; global options: +cmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17404 
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION: ;www.dnspod.com. IN A 
;; ANSWER SECTION: http://www.dnspod.com. 600 IN CNAME http://www.dnspod.com.cdnudns.com. http://www.dnspod.com.cdnudns.com. 300 IN A 61.172.249.96 http://www.dnspod.com.cdnudns.com. 300 IN A 218.244.147.137 
;; Query time: 608 msec 
;; SERVER: 208.67.222.222#53(208.67.222.222) 
;; WHEN: Mon Dec  7 23:29:01 2009 
;; MSG SIZE  rcvd: 101

3.最重要的问题，访问网站真的快吗？

相信不少人一定记得之前QQ用户出现过一次“免费出国”，当然，现在这个情况也会出现在用了OpenDNS和Google Public DNS用户的身上。 大家都知道中国特色的互联网，南北分家，互访速度巨慢无比，网站的维护人员绞尽脑汁的想办法解决互联互通的问题，加速大家的网站访问速度。 网站加速访问有好几种办法，有钱的大公司就用BGP AnyCast，但并不是人人都做得起（有自己的IP段，做一次BGP广播X-XX万，要达到最佳访问效果必须要做N次BGP广播，最后费用有可能达到 XXX万）。没钱的公司就只能用智能DNS了，包括自建的DNS，或者直接用DNSPod这样的现成方案，其实原理都一样。

智能DNS其实并不是太智能，它靠的预先分配好几个区域，然后根据用户请求的IP来判断用户属于哪个区域，之后返回对应区域的服务器IP。正常情况下，用户在国内上网，用的是ISP自动分配的DNS，用户域名解析请求发给ISP的DNS，ISP的DNS又发给DNSPod这样的域名授权DNS。 DNSPod这时候拿到的IP地址基本是ISP的DNS地址，所以很方便的就能判断出用户所在的区域，并把结果返回给用户。 但如果这个时候，用户用的是OpenDNS或者Google DNS，因为这些服务器的IP地址是在国外，并且N多老外都在用，智能DNS就不好判断该怎么返回了。返回国外的IP，影响国内用户的访问速度。如果返回国内的IP，影响到其他老外的访问速度。并且如果返回国内的IP，那么该到底返回电信还是网通的IP呢？用户属于哪个省份？无从判断。那么最后只能人多决定人少，返回国外的服务器IP。 返回国外IP的结果是，用户被指向网站在国外的服务器，访问网站巨慢。 本来想找几个典型例子的，但找了一圈回来，发现国内的大公司在这上面烧钱可是一点都不心痛，全部是BGP。要么就是不搭理国外用户，没针对国外用户单独进行解析，一概解析到电信的服务器去。

拿Google来当例子吧。我是网通用户，使用网通自带的DNS，解析www.google.com得到以下结果

$ dig http://www.google.com
...省略部分内容...
;; ANSWER SECTION:
http://www.google.com.  48102 IN CNAME http://www.l.google.com.
http://www.l.google.com. 300 IN A 216.239.61.104

如果我用了OpenDNS的话，那么我得到下面的结果 

$dig @208.67.222.222 http://www.google.com
...省略部分内容...
;; ANSWER SECTION:
http://www.google.com.  30 IN CNAME google.navigation.op

4. 怎么使用？

那么到底这两个DNS服务器有没有办法是用呢？有！这是一个肯定的回答。

首先，被污染的域名返回的地址在一个范围内，据我自己的收集在10个IP左右。首先向本地的DNS请求，当返回结果在这些地址中时，再通过代理的方式取得结果

或者使用类似autoproxy的方式，匹配列表的域名通过代理，其余均直接使用本地服务器解析。而我自己开发的smartVPN就是使用这种方式工作，收到正确的地址后再加入到路由走VPN，达到最节省VPN流量的目的。

Read more »

UTF-8、Unicode和BOM问题

经常遇到的问题是，使用了BOM编码后，PHP脚本执行错误，或使用fileStream读取并转换为XML会报错"The markup in the document following the root element must be well-formed."。

一、介绍
UTF-8 是一种在web应用中经常使用的一种 Unicode 字符的编码方式，使用 UTF-8 的好处在于它是一种变长的编码方式，对于 ANSII 码编码长度为1个字节，这样的话在传输大量 ASCII 字符集的网页时，可以大量节约网络带宽。

UTF- 8签名（UTF-8 signature）也叫做BOM（Byte Order Mark），是UTF编码方案里用于标识编码的标准标记。BOM，是UTF编码方案里用于标识编码的标准标记，在UTF-16里本来是FF FE，变成UTF-8就成了EF BB BF。这个标记是可选的，因为UTF8字节没有顺序，所以它可以被用来检测一个字节流是否是UTF-8编码的。微软做这种检测，但有些软件不做这种检测， 而把它当作正常字符处理。微软在自己的UTF-8格式的文本文件之前加上了EF BB BF三个字节, windows上面的notepad等程序就是根据这三个字节来确定一个文本文件是ASCII的还是UTF-8的, 然而这个只是微软暗自作的标记, 其它平台上并没有对UTF-8文本文件做个这样的标记。也就是说一个UTF-8文件可能有BOM，也可能没有BOM。

只有一个BOM，是不会有问题的。如果多个文件设置了签名，在二进制流中就会包含多个UTF-8签名，也就是导致XML转换失败的"root element must be well-formed"原因。

二、查看和转换
既然一个UTF-8文件可能有BOM，也可能没有，那该如何区分呢？

只要用带十六进制编辑方式的软件，例如，用UltraEdit-32打开文件，切换到十六进制编辑模式，察看文件头部是否有EF BB BF。有，则为带BOM方式。Windows自带的notepad记事本，保存为UTF-8时，默认就带BOM。

转换的方法有很多，常见的UltraEdit-32或NotePad++都可以，以UltraEdit-32为例。打开文件后，选择“另存为”，在“格式”一栏中有如下选择：

另外，DreamWeaver CS3也有类似的选项，在“首选项”中，如果选择 Unicode (UTF-8) 作为默认编码，则可以选择“包括 Unicode 签名 (BOM)”选项，以在文档中包括字节顺序标记 (BOM)。否则，不带BOM：

三、其他知识
从http://blog.csdn.net/thimin/archive/2007/08/03/1724393.aspx 一文了解到：
所谓的unicode保存的文件实际上是utf-16，只不过恰好跟unicode的码相同而已,但在概念上unicode与utf是两回 事，unicode是内存编码表示方案，而utf是如何保存和传输unicode的方案。utf-16还分高位在前 (LE)和高位在后(BE)两种。官方的utf编码还有utf-32，也分LE和BE。非unicode官方的utf编码还有utf-7，主要用于邮件传 输。utf-8的单字节部分是和iso-8859-1兼容的，这主要是一些旧的系统和库函数不能正确处理utf-16而被迫出来的，而且对英语字符来说， 也节省保存的文件空间（以非英语字符浪费空间为代价）。在iso-8859-1的时候，utf8和iso-8859-1都是用一个字节表示的，当表示其它 字符的时候，utf-8会使用两个或三个字节。

一段关于BOM的更详细说明，来自这里：
在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输 字符"ZERO WIDTH NO-BREAK SPACE"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little- Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

Read more »

使用GeoIP在Wireshark中显示IP的地理位置

本来想直接贴视频，结果发现搞不定～～

那还是贴地址吧：
http://www.securitytube.net/Setting-up-GeoIP-to-Track-IP-Address-Locations-in-Wireshark-video.aspx

Read more »

Cisco ISP Essentials

思科网站上下载的免费电子书，不过我忘记下载链接了……囧

点击下载

Read more »