djbdns 1.05 介绍与选型指南

djbdns 1.05 介绍与选型指南:Daniel J. Bernstein 开发的 DNS 软件套件定位、权威/递归分离架构、Public Domain 许可与版本取证,并与 BIND、CoreDNS、Unbound、PowerDNS 做量化对比,给出自托管选型建议。

djbdns域名服务网络DNS服务器2026/10/25

djbdns 1.05 介绍与选型指南

目标:帮读者在动手部署前判断「djbdns 是不是我要的东西」。本篇基于 Daniel J. Bernstein 官方站点 cr.yp.to/djbdns.html、tinydns.org 与公开仓库的联网溯源(查询日期 2026-10-25),讲清 djbdns 是什么、由哪些部件组成、与 BIND/CoreDNS/Unbound/PowerDNS 有何本质差异,并给出量化选型对比。部署、参数与 CLI 工具的逐步实测不在本篇展开。

一、环境信息与取材口径

本篇是选型篇,不包含本机部署实测;所有项目事实均来自可公开复核的来源,查询日期统一为 2026-10-25:

  • 官方主页:https://cr.yp.to/djbdns.html(Daniel J. Bernstein 个人站点)
  • DNS 原理科普站:https://tinydns.org/(由社区维护,讲解一次 DNS 查询从客户端到权威服务器的六站旅程)
  • 最新发布版:djbdns 1.05(发布于 2001 年,官方下载包 djbdns-1.05.tar.gz,MD5 3147c5cd56832aa3b41955c7a51cbeb2)
  • 许可证状态:公共领域(Public Domain)。DJB 于 2007-12-28 发表声明,将 djbdns 1.05 整体置入公共领域,不再受版权限制
  • 安全担保:DJB 个人提供 1000 美元悬赏,奖励第一个公开报告 djbdns 最新版可验证安全漏洞的人
  • 依赖组件:daemontools 0.70+(进程监管)、ucspi-tcp(TCP 客户端/服务器工具)

说明:djbdns 1.05 发布于 2001 年,至今没有更新的官方版本号。各 Linux 发行版打包时会附带维护补丁(如 Ubuntu 的 1:1.05-15fakesync1),但上游源码始终是 1.05。选型结论不依赖版本号的新旧,而依赖架构设计与适用场景。

二、软件概述

djbdns 是 Daniel J. Bernstein(DJB)开发的 DNS 软件套件,诞生于 1999 年前后,核心动机是替代当时漏洞频发的 BIND。它最具影响力的设计决策是把「权威应答」和「递归缓存」拆成两个完全独立的程序:

  • tinydns:权威 DNS 服务器,只回答自己负责的域名,不做递归
  • dnscache:递归缓存服务器,只替客户端做递归解析,不提供权威数据

这个拆分在 1999 年是激进主张,如今已成为行业共识(NSD、Knot DNS、PowerDNS Authoritative 都走「权威与递归分离」路线)。拆分的直接收益是缓存投毒无法污染权威数据:递归缓存被攻破时,攻击者拿不到权威区的原始数据。

除了两个核心服务,djbdns 还包含:

  • axfrdns:区域传送(AXFR)服务器,配合 tinydns 提供从服务器同步
  • walldns:反向 DNS 墙,对内网 IP 做受限反向解析
  • rbldns:实时黑名单(RBL)DNS 服务器,用于反垃圾邮件
  • tinydns-data:把文本格式的 data 文件编译成二进制 data.cdb,供 tinydns 高效查询
  • 一组 CLI 工具:dnsip、dnsname、dnsmx、dnstxt、dnsq、dnsqr、dnstrace、dnsfilter、random-ip 等

三、核心架构

3.1 权威与递归分离

djbdns 的架构核心是「一个程序只做一件事」:

程序职责不做什么
tinydns回答自己权威域的查询不递归、不转发、不缓存
dnscache替客户端递归查询并缓存结果不提供权威数据、不对外提供权威应答
axfrdns响应 AXFR 区域传送请求不回答普通查询

💡 技术拓展:DNS 服务器的两种角色。

角色职责代表实现
权威服务器持有某域的原始记录,直接应答tinydns、NSD、Knot DNS、PowerDNS Authoritative
递归解析器代表客户端从根开始逐级查询并缓存dnscache、Unbound、BIND(named)、CoreDNS

传统 BIND 把两种角色揉在一个进程里,djbdns 则强制分离。本文涉及的 tinydns 是权威服务器,dnscache 是递归解析器。

3.2 tinydns 的数据模型

tinydns 不使用 BIND 风格的 zone 文件,而是读取一个纯文本 data 文件,由 tinydns-data 编译成 CDB(常量数据库)格式的 data.cdb。CDB 是 DJB 设计的一种只读哈希数据库,特点是:

  • 构建后不可变,查询时无需加锁
  • tinydns 通过 mmap 直接读取,每次查询都是一次哈希查找
  • tinydns-data 原子替换 data.cdb,运行中的 tinydns 自动看到新数据,无需重启

data 文件每行一条记录,以特殊字符开头表示记录类型:.(NS+SOA)、+(A)、=(A+PTR)、@(MX)、C(CNAME)、'(TXT)、^(PTR)等。这种格式比 BIND zone 文件更易于程序生成和解析。

3.3 安全设计

djbdns 的安全设计贯穿始终:

  1. 特权分离:tinydns 和 dnscache 启动后立即 setuid 到非 root 用户运行,环境变量 $UID/$GID 指定降权目标
  2. 最小权限:通过 softlimit 限制内存、envuidgid 切换用户,进程不持有任何不必要的能力
  3. 不解析复杂输入:tinydns 只回答预编译好的记录,不做动态计算,攻击面极小
  4. 安全担保:DJB 个人悬赏 1000 美元寻找安全漏洞,截至 2026-10-25 未有人领取

四、功能特性

4.1 tinydns 权威服务器

  • 纯权威:只回答自己负责的域名,拒绝递归请求(响应中 rd 位被忽略)
  • CDB 数据库:从文本 data 编译而来,查询复杂度 O(1)
  • 支持记录类型:A、NS、SOA、MX、PTR、CNAME、TXT,以及通用记录类型(: 行)
  • 通配符:支持 *.fqdn 形式的通配符记录
  • 客户端位置视图:1.04+ 支持按客户端 IP 前缀返回不同答案(split-horizon)
  • 时间控制:支持 TAI64 时间戳,实现记录的定时生效/失效

4.2 dnscache 递归缓存

  • 纯递归:只做递归解析和缓存,不提供权威数据
  • 根服务器内置:自带 13 个根服务器 IP,开箱即用
  • 转发模式:可配置为转发到上游 DNS(servers/<域名> 文件指定)
  • 访问控制:root/ip/ 目录下以 IP 前缀命名的空文件控制允许递归的客户端
  • 缓存大小可调:通过 CACHESIZE 环境变量设置内存缓存上限

4.3 辅助服务与工具

  • axfrdns:基于 tcpserver(来自 ucspi-tcp)的 AXFR 服务器,支持 IP 访问控制
  • walldns:反向解析墙,对指定 IP 段返回固定的反向记录
  • rbldns:RBL 黑名单服务器,从文本数据构建
  • CLI 工具集:dnsip(正向查 A)、dnsname(反向查 PTR)、dnsmx(查 MX)、dnstxt(查 TXT)、dnsq(直接查指定服务器)、dnsqr(递归查)、dnstrace(追踪委派路径)、dnsfilter(批量反向查)、random-ip(生成随机 IP)

五、版本、许可与发布节奏

维度实测/实查结果取证方式
最新官方版1.05(2001 年发布,无更新版本)cr.yp.to/djbdns/install.html 下载链接
发行版维护版Ubuntu 22.04: 1:1.05-15fakesync1apt-cache show djbdns-conf
许可证公共领域(Public Domain),2007-12-28 起cr.yp.to/distributors.html 声明
依赖daemontools 0.70+、ucspi-tcp官方 install.html
源码体积85648 字节(djbdns-1.05.tar.gz)官方下载包实测
主要语言C源码包

发布节奏:djbdns 自 2001 年 1.05 发布后,上游没有再发布新版本。各发行版(Debian/Ubuntu 等)通过打包补丁维护,主要修复现代 Linux 下的编译问题(如 errno/TLS 链接错误)和安全补丁(如 2008 年 DNS 缓存投毒相关的源端口随机化补丁)。

选型提示:djbdns 是「完成态」软件——功能稳定、上游不迭代。这意味着没有新特性惊喜,也很少有破坏性变更。适合追求稳定、可预测的场景;需要 DNS-over-HTTPS、DNS-over-TLS、DNSSEC 签名等现代特性的场景,应考虑其他方案。

六、快速开始(官方最小流程)

官方文档给出的最小可用流程如下(命令取自 cr.yp.to/djbdns/install.html,完整实测部署步骤见本站后续发布的部署篇):

# 1. 安装依赖
apt install daemontools ucspi-tcp

# 2. 下载并解压源码
wget https://cr.yp.to/djbdns/djbdns-1.05.tar.gz
tar xzf djbdns-1.05.tar.gz
cd djbdns-1.05

# 3. 编译(现代 Linux 需加 errno.h 补丁)
echo "gcc -O2 -include /usr/include/errno.h" > conf-cc
make
make setup check

# 4. 配置 tinydns 权威服务器(监听 10.0.0.1)
useradd -r tinydns
useradd -r dnslog
tinydns-conf tinydns dnslog /etc/tinydns 10.0.0.1

# 5. 配置 dnscache 递归缓存(监听 127.0.0.1)
useradd -r dnscache
dnscache-conf dnscache dnslog /etc/dnscache 127.0.0.1

这段流程有三个容易被忽略的前置条件:

  1. errno 补丁:现代 Linux(glibc 2.34+)下直接 make 会因 errno 的 TLS 定义不匹配而链接失败,必须在 conf-cc 中加 -include /usr/include/errno.h
  2. daemontools:djbdns 设计上由 daemontools 的 supervise 监管进程,run 脚本中使用 envuidgid、envdir、softlimit 等 daemontools 工具
  3. IP 分离:tinydns 和 dnscache 不能监听同一 IP 的 53 端口,通常 tinydns 监听对外 IP、dnscache 监听 127.0.0.1

七、适用场景与限制

7.1 适合的场景

  • 小型权威 DNS:为几个到几十个域名提供权威解析,配置简单、资源占用极低(tinydns 内存通常 < 1MB)
  • 内网递归缓存:为局域网客户端提供递归解析,内置根服务器,无需额外配置
  • 安全敏感环境:特权分离 + 最小权限 + 安全担保,适合对 DNS 服务安全要求高的场景
  • 嵌入式/低资源设备:二进制体积小(tinydns 约 31KB)、内存占用低,适合路由器、IoT 网关
  • 需要可编程 DNS 数据:data 文件格式简单,易于用脚本/数据库生成后编译

7.2 不适合的场景

  • 需要 DNSSEC:djbdns 不支持 DNSSEC 签名和验证,且无上游计划
  • 需要 DoH/DoT:不支持 DNS-over-HTTPS、DNS-over-TLS 等加密传输
  • 大规模托管:没有动态数据库后端,所有记录需预编译到 data.cdb,百万级域名场景运维成本高
  • 需要现代递归特性:如 QNAME minimization、Aggressive Use of DNSSEC-Validated Cache 等
  • 动态 DNS 更新:不支持 RFC 2136 DNS UPDATE,需通过外部脚本改 data 文件后重编

八、同类选型对比

维度djbdns 1.05BIND 9CoreDNSUnboundPowerDNS
产品定位权威+递归分离的轻量套件全功能 DNS 套件云原生 DNS/服务发现递归解析器权威+递归套件
许可证Public DomainMPL 2.0Apache 2.0BSDGPLv2
权威+递归分离(两个进程)单进程可兼任单进程可兼任仅递归分离(authoritative + recursor)
DNSSEC不支持支持支持支持支持
DoH/DoT不支持支持支持支持支持
数据后端文本文件→CDBzone 文件多种插件(etcd/k8s/file)本地缓存+转发多种(MySQL/PgSQL/BIND/pipe)
内存占用极低(<1MB)中低-中低中
配置复杂度低(data 文件简单)高(named.conf + zone 文件)中(Corefile)中(unbound.conf)中
上游活跃度极低(1.05 后无更新)高高中高
安全模型特权分离+悬赏成熟但历史漏洞多插件化特权分离成熟

关键差异解读:

  1. djbdns 与 BIND 的差别在「哲学」而非「功能」。BIND 是全功能瑞士军刀,权威、递归、DNSSEC、DoH/DoT 一应俱全,但配置复杂、历史漏洞多;djbdns 是「够用就好」的极简主义,只做核心功能,安全模型严格。如果只需要给几个域名做权威解析、给内网做递归缓存,djbdns 的复杂度远低于 BIND。

  2. djbdns 与 CoreDNS 的差别在「部署场景」。CoreDNS 是云原生时代的 DNS,主打 Kubernetes 服务发现、插件化扩展,适合集群编排环境;djbdns 是传统单机 DNS,适合物理机/虚拟机上的稳定权威/递归服务。CoreDNS 功能更强但更重,djbdns 更轻更稳。

  3. djbdns 与 Unbound 的差别在「职责范围」。Unbound 是纯递归解析器,支持 DNSSEC 验证,是当今递归缓存的主流选择之一;djbdns 的 dnscache 同样是递归缓存,但不支持 DNSSEC。如果只需要递归缓存且关心 DNSSEC,Unbound 更合适;如果同时需要权威服务器且追求极简,djbdns 一套搞定。

  4. djbdns 与 PowerDNS 的差别在「扩展性」。PowerDNS 支持多种数据库后端、DNSSEC、REST API,适合大规模 DNS 托管;djbdns 只有文本文件后端,适合小规模。PowerDNS 功能全面但运维复杂,djbdns 简单但功能有限。

  5. 许可证差异要提前确认。djbdns 是 Public Domain,使用和分发无任何限制;BIND 是 MPL 2.0,CoreDNS 是 Apache 2.0,Unbound 是 BSD,PowerDNS 是 GPLv2。商用分发时需注意 PowerDNS 的 GPL 传染性。

九、结论

如果你的需求是「用最少的配置和资源,给少量域名提供权威解析 + 给内网提供递归缓存」,并且不需要 DNSSEC、DoH/DoT 等现代特性,djbdns 1.05 是一个极佳选择:Public Domain 许可、安全模型严格、内存占用极低、配置格式简单。

如果需要 DNSSEC、加密传输、动态数据库后端、Kubernetes 服务发现等现代特性,应选择 BIND、CoreDNS、Unbound 或 PowerDNS。djbdns 的「不迭代」既是稳定性的保证,也是功能停滞的代价——选型时应明确自己是否需要那些它没有的特性。

十、参考资料