自建权威DNS

上回书说到我最近在整理DNS的配置，其实当时这么做最早的诉求是把用来做ACME DNS-01验证（RFC 8555第8.4节）的域名单独拆出来，以改善其更新响应速度（因为大部分情况下权威DNS记录并不需要经常更新，我们更关注的是响应性能和可用性，而DNS-01验证则对更新时效性有比较高的要求）。

不过既然来都来了，索性把证书也顺手更新一下，从RSA换成ECC。由于我2015年就启用了DANE和TLSA，因此这意味着需要重新生成所有的TLSA记录；另外我也顺便给一些跑了SSH服务的域名补上了SSHFP记录。

这里记录一下所用的命令，供未来参考。

我的权威DNS跑在BIND 9上，采用Hidden Master架构，并开启了DNSSEC的inline-signing。

家里用不同的VLAN和网段做了隔离。早期规划时，我简单地把网段和子域做了一对一映射，每个子域都是一个独立的zone：

flowchart LR
    root["example.net<br/>（主域名）"]
    sjc["sjc.example.net"]
    
    root --> sjc
    sjc --> guest["guest.sjc.example.net"]
    sjc --> iot["iot.sjc.example.net"]
    sjc --> tiot["tiot.sjc.example.net"]
    sjc --> t["t.sjc.example.net"]
    sjc --> ut["ut.sjc.example.net"]

这些子域基本都由内网的DHCP服务器通过动态更新（RFC 2136）维护。这样，在内网访问某台机器时，不必去查它拿到了什么IP地址，直接用主机名加上所在的VLAN就行。不过时间长了，这套配置带来了很多不必要的维护负担：

1. 每个zone都有自己的一套DNSSEC密钥。我配置的dnssec-policy为每个zone生成一把Ed25519（RFC 8080）CSK，对应K*.key、K*.private、K*.state三个文件，目录里还堆满了各种.signed、.jnl和临时的.jbk文件。
2. 每多委派一个签名子zone，父zone就得多维护一组NS和DS记录。密钥轮换时，如果旧DS还在缓存里，对应的DNSKEY却已经撤下，验证就会失败，客户端看到的就是SERVFAIL。
3. named.conf里写满了大同小异的zone声明和ACL，Hidden Master后面的每台辅DNS服务器上，也都得再为它们各配一遍。

这些子域都由同一台DHCP服务器、用同一把TSIG密钥更新，拆成独立的zone在安全性方面没有必要。

今天花了些时间撤销这5个子域的独立zone和委派，把记录并进sjc.example.net。主机名不变，例如myhost.iot.sjc.example.net依然按原样解析，只是不再单独维护iot.sjc这个zone。

TL;DR：我的观点是现时（2023）大多数人都不应该自建DNS，而应该找一家比较可靠的供应商。

下面说说我的理由。

近期由于一些众所周知的原因，我做了一系列域名转移的操作。和2006年的这篇相比，这些年我也经历了不少域名注册服务提供商，并且积累了不少经验，是时候更新一下了。

域名服务是一项互联网基础服务，它提供了容易被人记忆和识别的在线地址。对于个人和企业来说，拥有自己的域名最大的好处在于能够掌握随时换一家供应商的议价权。集中式的平台，包括YouTube、Twitter、GitHub，也包括新兴的平台如TikTok、或是来自中国的小红书、喜马拉雅、B站等等，尽管也都是很好的产品，有些甚至可以为内容作者带来丰厚的回报，但是其上的个人或是企业无法很容易地离开这些平台。依赖这些平台，意味着在它们选择对内容作者采取某些行动，或是退出某项生意的时候，当事人可能没有任何其他选择，而必须在极短的时间内通知自己的受众去其他平台，这有时是很困难甚至不可能的。

对个人来说，邮件服务的运行成本是很高的（这里需要考虑的不仅是服务器本身的成本和运行费用，也包括需要投入的时间精力）。但即使不自己去运行邮件服务，也仍然有许多支持独立域名的邮件服务提供商，例如Google Workspace、Microsoft 365、Zoho Workplace等等。与单纯使用Gmail或outlook.com等等相比，拥有独立的域名意味着可以在这些服务之间随时进行转移，而无需逐个通知亲朋好友。

DNSSEC是一组针对DNS协议的扩展，其主要目的是为数据的权威性（或者说DNS数据确实来自于有权发布这些数据的人）提供一套验证机制。DNSSEC并不改善私密性，所有的查询依然是明文的。

目前最新的DNSSEC最佳实践指南是BCP 237（RFC 9364）。值得说明的是，如果没有特别的需要，使用DNS服务业者的DNSSEC实现可以避免踩很多的坑，尽管这样一来安全方面就完全要仰赖这些业者了，但对普通的域名所有者来说，这些服务要比自己架设和管理可靠不少。本文并不打算深入介绍DNSSEC及其部署，而只是关注于在进行域名转移时需要注意的问题，以备我个人未来进行参考。

📓 注意

Google Domains已于2023年被Squarespace收购，并于2024年7月10日完成全部域名迁移，该产品现已不复存在。不过，文中涉及的域名转让原则与操作步骤在绝大多数注册机构之间依然适用。

这里记录一下过程备忘。

我在2011年注册了一个比较技术宅的.org域名，但一直没有实际投入使用，最近宏观经济形势不太好，所以索性把不用的域名出一批来减少持续的花销，周四终于出现了一位愿意接手的朋友，于是我们找时间做了一次域名转让的操作。

长久不做 SA，所以有些事情变得没有以前那么敏感。昨天终于还是出事了，不过幸亏不是商业系统，如果是的话，我觉得绝对够得上是重大事故。记一笔，留个教训。

一般来说DNS和MX都需要做冗余。前者的冗余和容灾要求要高于后者。

DNS的冗余通常需要做到跨ISP，甚至跨大洲。由于安全和性能方面的理由，提供权威DNS解析的服务器都不应同时作为缓存DNS服务器；此外，实践上权威DNS服务器应该是受保护的管理服务器的slave，而不应直接在权威DNS服务器上操作（读、写分开），这样可以有效减少由于修改操作所导致的downtime。

📜 历史文件已不具备现实意义

本文写于2006年，文中关于域名注册商的格局、价格及评价均已过时，不再更新。最新内容请参见2023年6月的《再谈域名注册服务提供商的选择》。

转载请注明出处：https://blog.delphij.net

域名服务与邮件服务一样，是非常重要的互联网基础服务。与几年前动辄每年几十$，到现今最低至1.99$的注册服务，域名注册服务商能够从中获取的利润也越来越少。

为了解决利润的问题，多数域名注册服务提供商（Registrar）会捆绑销售一些其它的产品，例如虚拟主机、企业邮箱，乃至新兴的个人blog等等。透过这些服务，他们能够获取更多的利润，同时，这些服务也满足了一些不愿或不会自己架设域名、主页、邮件服务器的用户的需要。幸运的是，这些用户占全部用户总数中的绝大多数。

这里将要讨论的是愿意花费时间精力，并且有能力自己架设域名解析、主页和邮件等服务的用户的需求。首先，架设域名解析等服务器是需要有一些投入的，另一方面，在这种情况下，往往域名注册服务提供商提供的其它服务，例如虚拟主机等，就不再是必要或完全是多余的了，因此，此时价格、可靠性等就成了最大的决定性因素。