DNS Server（BIND）
1、DNS服务器的主要风险
a> DNS信息泄露（通过DNS信息猜测网络架构）；
b> 非法取得DNS配置信息；
c> 通过BIND进程获得主机权限；
d> 入侵DNS可以轻易地进一步伪装自己的身份（比如说查找没被使用的IP，某些情况下使用这些IP就可以绕过某些使用网段的验证），所以这是一个很好的first stage；
2、对应的防御手段：
a> 使用TSIG（Transaction SIGnature）事务签名控制访问；
b> 限制zone文件的传输（master只能传给slave，slave不传给任何人，并且最好使用TSIG而非IP作为限制条件）;
c> 在权威DNS服务器上限制递归式DNS查询（bind默认就是禁止的，也可以配置成对内部机器开放），让专门的Local DNS Server去响应递归式查询，这样可以防止cache注入和name伪造攻击，而且对性能优化也是很有好处的。；
d> chroot BIND的进程（RHEL上的bind-chroot包提供此功能， 此包被@DNS Server包含。启用以后用ps -ef能看到named -t /var/named/chroot）；
e> 记录日志，必要的话记录到远端主机上（bind提供了非常灵活的日志功能，可以定义哪些信息category被记录到哪儿channel）；
3、BIND从版本9才开始支持DNSSEC和TSIG，重写了全部的底层代码，带来了更高的安全性和更低的性能（可参见）；
4、DNS服务的结构：
a> zone文件是一个DNS服务器可以响应的命名空间，一个zone文件中通常包含一个域名和此域名下的子域名；
b> master DNS服务器包含第一手的zone文件，slave服务器通过zone transfer从master取得zone文件；
c> master和slave给前来查询的客户端做出的属于自己的zone的响应被称作“权威应答”，而被cache在Local DNS的响应被称为“非权威应答”；
d> DNS查询分为递归式和迭代式；
e> 递归式查询。通常用于权威服务器。服务器在收到查询后，如果本身不是此查询的“权威域”，则会让客户端去向另一个DNS服务器去查询（通常是root DNS）；
f> 递归式查询。DNS服务器收到客户端查询后帮助客户端完成迭代查询后直接把结果返回给客户端。这样客户端只用“一跳”就完成了DNS查询。通常用于local DNS；
g> master和slave必须响应迭代式查询。对于递归式查询，它可以选响应或者不响应；
h> cacheing-only的DNS服务器不提供任何zone文件的权威数据。通常就是local DNS服务器。一般用于帮助客户端完成递归式查询；
5、DNS同时监听53 UDP端口和53 TCP端口，UDP的优先；
6、bind的进程名称是named；配置在/etc/named.conf（root可写，其它人可读）；zone存放在/var/named/（默认所有人可写）；
7、针对DNS的攻击：
a> 第一类攻击是遍历DNS信息，为下一次攻击做准备。攻击者也许只是不断地进行DNS查询，或是请求zone transfer（嗅探得到之），或者对IP地址进行PTR反查。用于猜测网络中存在哪些IP，以及它们扮演的角色。防御的手段是限制zone的传输和使用分离的命名空间；
b> 更危险的攻击是缓存注入（cache poisoning）或者名称欺骗（name spoofing）。前者是往local DNS的缓存中注入错误的解析地址（一般会设为很长的TTL），导致用户被引向错误的服务器。后者则是抢在真正的权威应答之前伪造一个应答回给查询者，或是干脆伪装成权威应答。解决此类问题的方法是限制递归查询， 并且部署DNSSEC（Domain Name System Security Extensions）（RFC2535描述）（在bind 9中实现）；
c> 第三类攻击最为危险。攻击者可能控制了更高一级的DNS Server（如root），由于较低级的权威DNS的控制者是更高一级的DNS Server指定的，如果更高级的DNS被控制了，那么较为低级的DNS Server也就被绕过去了（攻击者可以指定自己的机器作为权威的服务器）。