BIND是一款同时支持缓存和权威答复的DNS服务器，担负着现金互联网系统90%的DNS查询任务，然而很多喜爱DanBernsteian的TinyDNS的人却并不看好BIND。
本文将对两种DNS服务器作一个简要的对比，同大多数比较一样，结果并不一定非常客观。
本文中的观点最先由Brad Knowle提出，论文详见Name Server Comparison。该文主要着眼于权威和缓存域名服务器的性能，但是同样论及了其他的不同点。之后DJB撰写了Brad Knowles’s Slander，驳斥Knowles的观点。从事实中斟选出一个最好的DNS服务器是一件很困难的工作，何况对于”最好”的定义恐怕还要根据站点的事情情况来确定。
Bind 8
优点：
完整支持递归/缓存和授权域名服务
递归/缓存和授权域名服务可以共享IP地址
比Bind 9速度快
支持多种操作系统
统计数据以资源记录类型分类
支持IPv6
缺点：
基于传统的(spaghetti)代码
不支持多线程
区域传递由外部处理(fork()/exec())
即将被新版本取代
没有SERVFAIL统计
后续的SERVFAIL消耗过多的CPU资源（未证实）
Bind 9
优点：
完整支持递归/缓存和授权域名服务
递归/缓存和授权域名服务可以共享IP地址
重写了底层，提供更高的安全性
支持DNS安全技术──DNSSEC, TSIG
支持IPv6
多线程，多进程，充分利用多路处理器
支持增强版DNS协议，如IXFR, DDNS, Notify, EDNS0
遵循标准
分离了DNS和视图(Views)
高度可移植
内部区传递机制
可以以低权限身份运行，提高系统安全性
有针对SERVFAIL的统计
可以缓存SERVFAILS
缺点：
当负载打到几百递归查询的时候，系统响应相当迟缓（未证实）
当缓存数据超过250M时，可能会有数据库管理问题（未证实）
统计无法根据资源类型分类
多线程处理时可能会大量增加上下文切换等额外工作──仅在多线程状态下会表现，系统默认为单线程
djbdns(TinyDNS/DnsCache)
Knowle的文章对djbdns套件评价没有什么正面评价，尽管对djbdns好评的文章已经很多。TinyDNS的主要优缺点包括：
优点：
单一文件管理所有区，使得区管理非常简便
区文件格式比BIND设计的更加流畅
遵循UNIX哲学，小进程负责细分之后的任务，而不是一个庞大的进程负责全部
CDB格式的数据文件允许使用更快的机制实现区传递，例如基于ssh的rsync
设计之初便充分考虑安全性问题
为dnscache设置的简便的水平切分设置
ANSI-C编写，可以在几乎所有的unix平台上编译
CDR数据文件与平台无关，二进制的数据文件可以直接跨平台复制，使用（cdb和djbdns不是自由软件，作者不允许对起随意修改，所以自由的linux分发无法>包括该软件包）
缺点：
违反了部分RFC规范
默认不支持送交(referral)
不支持TCP协议（尽管可以通过axfrdns实现，另dnscache支持tcp协议）
对不完整请求或者不支持的请求的回复很奇怪（违背了”开放接收，保守输出”的原则）
没有第三方补丁，无法监听2个以上的ip地址
无法在同一IP同时绑定tinydns和dnscache(udp 53)
不支持DNSSEC, TSIG, IXFR, NOTIFY, EDNS0, IPv6
设计过分着眼于修订BIND8的问题，然而BIND9修正了绝大部分问题
可能会持续的丢弃一小部分请求（Knowles的文章）
没有好的从BIND迁移过来的转换工具（未证实）
性能不佳，作者宣称的高性能无法证实。Knowles的测试表示该服务性能不佳。
缓存解释器的比较：
BIND宣称作为缓存服务器的时候性能不如dnscache，而且有时会丢弃部分请求。BIND的默认缓存由缓存条目的生存期(TTL)决定，然而dnscache默认只有1M 。
BIND不会送出重复的请求，不易被归为不良服务器，然而dnscache没有相关的检查机制，并不限制未被缓存的条目的查询请求。
dnscache不支持多线程，所以无法利用多CPU，BIND尽管是多线程的，但多线程的实现依然有问题
在高负载的情况下dnscache貌似比BIND强一些。
BIND在有些特定情况下比dnscache反应迅速，因为dnscache会进行更广泛的查询，例如Akamai的负载均衡服务有大量的DNS条目，Yahoo使用其中一部分，试着用dig来分别从两种服务器查询yahoo.com，你会发现明显的速度区别。
很多人认为tinydns的数据文件格式比BIND更加易于理解。
