DNS随笔3-脆弱的安全性

DNS系统的安全性简述

首先要界定这个DNS系统的范围，以用户的视角，完整的DNS系统应该是从域名所有者到域名使用者之间所有内容，从功能架构的角度看，这里DNS系统包括注册管理部分和递归查询。

其次这里的安全性指应用数据的安全，不包括应用服务的可用性。

安全隐患分析：

系统级的安全隐患总是有的，如果有授权服务器的权限，就可以直接篡改注册数据，如果有递归服务器的权限，也可以改变缓存域名的结果。这个不用讨论，不是应用级别的范畴。顺便提一句，国内运营商们对域名做手脚大部分都发生在递归服务器这个环节，它们是自己的大hacker。

应用级别的安全性问题其实发生在各个子系统的边界做数据交换的地方，包括

授权服务器（注册管理部分）

1. 上级节点开放给下级节点的注册数据写入接口。

2. 同级节点内不同服务器间做数据交换接口。

递归服务器（缓存部分）

3. 递归服务器访问授权服务器

4. 最终用户访问递归服务器（包括 缓存服务之间的请求）

隐患1其实不属于DNS协议范畴，上一级的注册商需要对下一级的注册商或者域名所有者进行身份认证，需要确保提交的数据真实可靠，需要的是一个独立于DNS的授权，认证，传输加密的管理系统。很多时候新闻里提到的DNS被黑了，域名被篡改了，其实是发生在这个阶段的事故，确切的说不是DNS被黑了，而是那个注册商的管理系统被黑了，或者是某个用户自己的认证出了问题。

隐患2其实就是数据更新的问题，一个分布式的数据库，一个存储节点上的数据动态更新，一个存储节点上出于可靠性（主从备份性质）或是吞吐量（读写分离，负载均衡）的原因还可能是多台物理服务器，需要数据同步。这些居然都在DNS协议中要解决，所以有TSIG，IXFR，AXFR等等乱七八糟的东西，所以DNS协议是一个典型的有违KISS原则的设计。这些东西不仅使系统臃肿复杂，而且效率低下。所以实际上，最好的方法就是不用这套机制，比如把DNS记录存储到独立数据库（关系数据库或者随便什么专业一点的数据库），使用数据库的同步机制做数据同步，用数据库的操作接口做增删改操作，授权服务器使用数据库的查询功能，对外提供DNS协议中的应用层面的请求。这样做简单，专业，可靠，唯一的问题就是只能在这个节点内部做数据更新，不能使用DNS协议中公用的接口来完成数据更新，不过绝大多数情况下，这是一件好事。

隐患3是指在通过递归方式查询数据库的时候，可能被人恶意伪造传输数据而得到错误的结果，在DNS领域被称为投毒（污染），黑客的投毒方式是用试错方式进行的，投毒能否成功是概率事件，我国功夫王(GFW)的投毒方式是监听干扰式的，百发百中。解决办法只能是数据加密，但是纳入DNS协议中的DNSSEC是个重量级的方案，进一步增加了协议的复杂性，并且使得程序在性能和可靠性上有潜在问题。一些土方法被一些程序实现，例如使用更多的端口，对查询域名使用随机大小写混排的方式传输等等，但是这些不能真正解决问题，也并没有被纳入DNS协议。DNSCurve是一个比较新的加密方案，但是按照DNSNEC的推行时间看，真正能用起来还遥遥无期。

隐患4其实可以看作是隐患3的外延，但是一般不会有黑客在这个地方下手，因为"性价比"比较低，所以在DNS协议中其实是没有足够安全的解决方案来保障。以功夫王为例，就算你把客户端的DNS服务器指向国外的递归服务器，你的解析一样会被改写。还有就是如果从网上不安全的渠道下载host内容，自己手工更新HOST，也存在这类隐患。