DNS的SOA记录谁在填？131个站只有4个写了自己

摘要：把131个海外独立站的DNS区文件挨个翻开，那条SOA记录一共七个字段。能从中读出“上一次被人改动是哪天”的只有44个站，三分之一都不到；四个控制全网缓存行为的数字凑出39种组合，头三种就覆盖了73个站，85.3%的站用的是DNS服务商的出厂值一个字没改；而“出事找谁”那一栏里写着自己域名的，131个站里只有4个，其中还有一个填的邮箱域名压根收不了信。

你大概率给自己的域名加过A记录，改过MX，为了验证某个平台粘过一条长长的TXT。这些记录都住在同一份文件里，叫区文件。

而这份文件的第一条记录，多数人一次都没打开看过。它不指向任何服务器，不影响页面怎么显示，甚至在大部分DNS后台的界面上根本不给你编辑入口。但全世界每一个解析器在决定“这个域名的答案我能存多久”“查不到的时候我要记多久”“主服务器挂了我还能撑几天”的时候，读的都是它。

它叫SOA，起始授权记录。这一轮把131个海外品牌站的SOA全部取了下来，逐字段拆开看，又直连它们各自的权威服务器复核了一遍。结论有点尴尬：这条记录上写的东西，几乎没有一个字是这些品牌自己填的。

域名底下那份文件的第一行，到底写了什么？

先把话说明白。你在DNS后台看到的那些A、CNAME、MX、TXT，在协议层面是一份纯文本文件里的一行行记录，这份文件叫zone file，中文一般译成区文件。区文件的开头必须有一条SOA记录，这是RFC 1035定下来的规矩，没有它这个区就不成立。

SOA后面跟着七个值，挤在一行里，长这样：

ikea.com. 86400 IN SOA udns1.cscdns.net. premiumdns.support.neustar. 2019119718 28800 7200 1209600 86400

七个值各管一摊：

前六个字段的读者是你自己那几台服务器，影响面有限。真正影响全网的是最后一个MINIMUM——RFC 2308把它从“这个区的最小TTL”改成了“否定应答的缓存时长”，也就是说，别人查你一个不存在的名字，得到的那声“没有”，会被缓存这么久。你新加一条记录，如果之前有人查过、扑了空，那这些解析器要等这个时间过完才会重新来问。

这就是为什么值得把它翻出来看。它不管你的网站好不好看，它管的是你改一个东西之后，多久才算数。这件事在HTTP那一层有一整套缓存头在管，而在DNS这一层，管事的就是这七个数字。

这七个字段里，有几个是站主自己填的？

先看最容易检查的那一个：RNAME，管理员邮箱。

131个站里，这一栏写着自己域名的，一共4个：jysk.com写的是hostmaster@jysk.com，nespresso.com写的是dns-requests@nespresso.com，philips.com写的是ddi-authority@philips.com，montbell.com写的是root@dns.montbell.com。

剩下127个，写的全是服务商的通用信箱：

第三行那个jomax.net值得停一下。jomax.net是GoDaddy早年创立时用的旧域名，公司后来改了名，这个域名却留了下来。今天17个用GoDaddy解析的品牌，区文件里那栏联系邮箱印的还是它。这条记录就是这样一种东西：没人看，所以也没人改。

更有意思的是那4个“自己填了”的。把这4个邮箱的域名拿去查MX，montbell那个dns.montbell.com一条MX记录都没有。也就是说，131个站里唯一那批愿意留自己联系方式的，四分之一留的是个收不了信的地址。同样查不到MX的还有digicertdns.com（farfetch.com和underarmour.com在用）和alibabadns.com。

这个字段本来的用途是：别人发现你的解析出了问题，想通知你一声。现在它的实际状态是，绝大多数人通知不到你，而少数几个想被通知的，信箱是坏的。

SERIAL号称是版本号，为什么三分之二的站读不出改动日期？

SERIAL理论上是个好东西。它是区文件的版本号，改一次涨一次，业界流传最广的写法是YYYYMMDDnn——年月日加当天的第几次修改，2026年8月13日改第16次就写成2026081316。真按这个写法，任何人都能从外面读出你的DNS上一次被人动过是哪天。

实际扫下来，131个站的SERIAL分成四种形态：

看这张表的时候要注意，形态和品牌本身没关系，和它用哪家DNS有关系。33个用AWS Route 53的站，SERIAL全是1——不是巧合，Route 53压根不用这个字段做版本管理，它给每个区固定写1，永远不变。26个用Cloudflare的站全是24开头的十位数，是Cloudflare的内部计数，和日期无关。16个用GoDaddy的站则全是标准日期型。

于是就出现了这么个局面：“你的DNS上次被人改动是什么时候”这个问题能不能被回答，取决于你当初选了哪家解析服务，跟你自己改没改、改了几次，一点关系都没有。选AWS的那33个站，从外面看永远是一片空白；选GoDaddy的那16个站，改动日期对全世界公开。两边谁都没做过这个决定。这跟robots.txt分组不继承那件事是同一个道理：真正决定你处于什么状态的，是平台替你选好的那一档。

能读出日期的那批站，最后一次改动停在哪一年？

把日期型和Unix时间戳这两类凑起来，再剔掉下一节要讲的8个（那8个的日期是假的），剩下44个站的改动日期是能用的，占131个的33.6%。它们的分布是这样：

中位数是19天。大部分站的DNS确实是活的，这不奇怪——加个验证记录、换个邮件服务、排一次海外打不开的故障、上个新的CDN节点，都会碰到区文件。

值得看的是分布的形状：一个月内和五年以上这两头都很厚，中间那段几乎是空的。91天到3年之间，44个站里只有1个。这不是渐变，是两拨完全不同的状态：要么这个域名还在被人日常经手，要么它已经被彻底放下了，中间没有“偶尔想起来动一下”这种情况。

停得最久的几个：pandora.net停在2010年1月24日，babybjorn.com停在2013年11月23日，weber.com停在2016年3月21日，braun.com停在2018年4月30日，aliexpress.com停在2018年5月10日。这几个都不是小站。braun.com和aliexpress.com这种量级的域名，区文件八年没动过一个字节，说明它的解析配置早就定型，也说明没人在做定期复查——毕竟这八年里，行业换了两轮邮件安全标准，多了一堆平台验证方式。

顺带一提，这个空档期和站内之前那篇域名根上平均挂着14条验证记录的实测能对上：那些记录只增不减，正是因为没人回头看这份文件。

修订位写着88，真是那天改了88次吗？

看日期型SERIAL的时候撞上一件怪事。misen.com的SERIAL是2009010288，按YYYYMMDDnn读，是2009年1月2日改的第88次。

一天改88次区文件？理论上不是不可能，但对一个厨具品牌来说不合常理。把所有修订位大于30的挑出来，一共8个：

八个站有两个共同点。第一，日期位全都停在过去，最近的也是一年半以前。第二，没有一个用的是AWS、Cloudflare、GoDaddy这类自助平台，全部来自企业托管或者自建。

更合理的解释是：这串数字不是“日期加当天修订号”，而是一个从某个日期起步的纯计数器。当年迁移或者建区的时候把初始值设成了那天的日期加00，之后每改一次加1，日期位就再也没动过。按这个读法，misen.com不是十七年没改，而是从2009年那次建区之后，一共改了大约88次。

这个解释目前只是推测，服务商没有公开说明，本轮实验也没能在窗口内抓到其中任何一个发生变化。但它给出了一条可验证的判据：再观察一段时间，如果某个站的SERIAL加了1而日期位不动，那它就是计数器；如果日期位跳到当天，那它才是真日期。放到自己站上，这条判据一分钟就能验——改一条无关紧要的TXT记录，然后看SERIAL怎么变。

无论哪种解释，结论的方向是一致的：这8个站的SERIAL，都没有在回答“最后一次改动是哪天”这个问题。把它们留在统计里，会凭空造出8个“十几年没维护”的僵尸站。

四个控制缓存的数字，131个站只凑出39种组合

REFRESH、RETRY、EXPIRE、MINIMUM这四个数字，理论上应该按每个站自己的架构来定：从服务器多不多、跨不跨洲、改动频率高不高，都会影响该配多少。

实际上，131个站一共只凑出39种组合，其中27种只出现过一次。头三种就吃掉了73个站，占55.7%：

再按服务商拆开看遵从率，那张表更直白：

把样本量在3个以上的服务商合并起来算，102个站里有87个用的是本家出厂值，85.3%。

这张表里最值得琢磨的是最后一行和第一行的对比。Cloudflare的26个站，四个数字26份逐字相同，一个字节的差异都没有；而CSC的8个站，有7个都改过。这不是因为CSC的客户更懂DNS，是因为CSC卖的是企业级托管服务，配置本来就由服务方按客户情况定；而Cloudflare、Google、Azure DNS、阿里云这类自助平台，界面上根本不给你改这四个数的地方——你想改也改不了。这两家的文档里都写明了SOA由平台统一生成。

说得刻薄一点：“大家都用默认值”里面，有一半的情况是“大家根本没有选项”。而剩下那些真能改的地方，也确实没人去改。这一点在第三方脚本把域名悄悄拉进来那次实测里也出现过：配置的实际形态，往往是上游默认值的投影。

这些出厂值和RFC推荐区间对得上吗？

既然值都是服务商定的，那就该问下一个问题：服务商定得对不对。RFC 1912第2.2节给过一组推荐区间，RFC 2308给了否定缓存的建议上限。拿这两把尺子去量：

两处严重偏离，方向正好相反。

EXPIRE有68个站低于推荐下限，超过一半。推荐值是14到28天，而Cloudflare出厂给的是604800秒也就是7天，GoDaddy也是7天，阿里云更极端，86400秒整整一天。EXPIRE管的是“主服务器彻底联系不上之后，从服务器还能替你回答多久”。配成一天意味着，如果主服务器出了持续超过24小时的故障，从服务器就集体闭嘴，你的域名从全网消失。当然，这几家用的都是anycast架构，主从之间的链路本来就极其可靠，风险确实比传统主从架构低，但这个值和RFC的推荐差了一个数量级，是事实。

MINIMUM那一头更值得警惕：48个站高于推荐上限，其中45个站配到了24小时以上。AWS Route 53的出厂值86400秒就占了32个，MarkMonitor那4个站是172800秒，整整48小时。

这个数字的实际后果很具体。假设你要给某个平台加一条TXT验证记录，而在你加之前，那个平台的检查程序已经查过一次、得到了“没有”。接下来这24小时里，无论你把记录加得多正确，它那边看到的都还是“没有”。做过Google Search Console域名验证、或者配过邮件发信域名的人，多半都撞过这一下，只是当时没意识到卡住自己的是SOA里的最后一个数字。这也是SPF展开次数由上游决定那篇里同一类问题的另一个面：你以为在配自己的东西，实际生效的规则来自别人。处理这类延迟的思路和清多层缓存要留回执一样：不要相信“应该已经生效了”，要拿到一个能核对的读数。

根域和www的过期时间，为什么会差四千倍？

顺着缓存这条线往下，把每个站根域和www这两个名字的TTL都从权威服务器上取了一遍。TTL不写在SOA里，但它和MINIMUM是同一件事的两面：一个管肯定答案存多久，一个管否定答案存多久。

125个能干净比对的站里，41个给根域和www配了不一样的TTL，占32.8%。差距最夸张的几个：

这几个站的根域都配了极短的TTL，明显是接在全局负载均衡后面，需要随时切流量；而www那个名字被晾在一边，配了整整一天。问题在于，这些品牌对外用的主入口恰恰是www。真到了要紧急切换的时候，能秒切的是那个大多数用户不会输入的名字，而用户真正在访问的那一个，得等24小时才能全网换完。

这种不一致通常不是有意设计的，是历史遗留：根域后来接进了CDN或者GSLB，配置跟着新方案走；www那条老记录还躺在原地，谁也没想起来它。想验证自己站上有没有这个问题，两条命令就够了，做换主机搬家或者多域名合并之前尤其该跑一遍，不然切换窗口会比预期长一大截。

同一个域名问两台服务器，会不会得到两个答案？

本来这只是一步例行核对：既然要拿SERIAL当证据，就得确认从不同地方读到的是同一个值。这类核对经常有意外收获，之前把HEAD换成GET就多出五个响应头那次也是如此。结果这一步反而挖出了本轮最结实的几个发现。

先是公共解析器和权威服务器之间。用公共DNS读到的SERIAL，有7个站和权威值对不上，占5.3%。原因不难理解：SOA记录本身也有TTL，你从公共解析器拿到的可能是它缓存里几小时甚至几天前的版本。dreametech.com那次差得最多，公共解析器说是8月13日，权威服务器说是8月25日，差了12天。所以前面所有关于“最后改动日”的数字，严格说都是下界——真实的改动只会比读到的更新，不会更旧。这和用304判断内容有没有变会遇到的麻烦是同一种：你读到的是缓存的状态，不是源头的状态。

更要紧的是第二层：同一个域名的多台权威服务器之间，答案也未必一致。4个站中招：

前三个都在阿里云和万网体系里，两台服务器之间差了1到7天，是区文件同步滞后，属于可以自愈的状态。RFC 2182要求多台权威服务器之间保持一致，正是为了避免同一个问题拿到两种答案。

bigcommerce.com那一行完全是另一回事。它的NS里同时挂着NS1和Google Cloud DNS两家，而这两家给出的不是同一份区文件：

七个字段里有六个不同。这意味着解析器问到哪一台，就按哪一套规则缓存你的域名——否定应答存1小时还是5分钟，取决于运气。这不是同步没跟上，这是两套独立维护的配置各活各的。多家DNS并行是正经的高可用做法，但前提是两边的区文件真的一样；只把NS写上去，不等于做到了冗余。

陌生人能把你整份区文件下载走吗？

既然聊到区文件，就得问一句最老的那个问题：能不能整份要下来。

DNS协议里有个叫AXFR的操作，从服务器就是靠它把整个区文件从主服务器同步过来的。如果权威服务器没有限制来源，任何人都能发一条AXFR，把你所有子域名、内网主机名、测试环境地址一次性拉走。这是二十多年前的经典漏洞，现在写进各种安全基线。

131个站逐个试了一遍，开放的0个。

数字太干净的时候不能直接下结论——很可能不是大家都关了，而是我的探测代码根本识别不出“开放”。所以先拿zonetransfer.me验了一遍，这是安全圈里专门为了演示区传送搭的公开测试域。它的两台服务器都被正确识别为开放，各拉回35个节点，说明探针是有效的。

那这0个就是真的。131个站，包括那些区文件八年没动、联系邮箱是坏的、四个数字全是出厂值的站，在这一条上全部合格。原因也不神秘：AXFR的默认策略在现代DNS平台上就是关闭的，自助平台压根不提供打开的开关。

这条值得单独说一句，因为它是这篇文章里唯一的好消息，而且它和前面所有坏消息出自同一个机制：默认值决定了绝大多数站的实际状态。默认关闭的东西，全网都关着；默认宽松的东西，全网都宽松。区别只在于服务商当初把那个开关拨到了哪一边。

我的尺子错了三次，错在哪

这一轮的测量改过三次，其中两次改变了数字的量级，值得原样交代。这类问题在sitemap里那个修改时间到底记的是哪一刻那次实测里出现过一次，当时的教训是：一个字段叫什么名字，和它实际记录什么，完全是两件事。

第一次，把计数器读成了未来的日期。第一版的SERIAL分类器里，十位数如果落在Unix时间戳的合理区间就按时间戳解。结果decathlon.com的2019115278被解成2033年12月25日，ice-watch.com的2080998099解成2035年。区文件的版本号当然不可能来自未来。加一条“解出来的日期不能晚于今天”之后，被误判成时间戳的从13个降到4个，能读出日期的从61个收敛到52个。判据很朴素：一串数字有两种合理读法时，先用常识排除掉不可能的那一种。

第二次，把缓存里的剩余秒数当成了配置值。这次错得最狠。第一版TTL是从公共解析器读的，读到aliexpress.com是424秒、aboutyou.com是274秒、某个www是8秒。没有人会把TTL配成424秒——公共解析器返回的是“这条记录在我缓存里还剩多少秒过期”，是个一直在减的数。按这个数算出来的“根域和www的TTL不一样”，有87个站。

改成直连权威服务器之后降到46个。但权威值里还有297、301、136这种数字，于是又做了一次自基线：同一条记录隔几秒问两遍，一样的才算配置值。5个站的权威服务器每次返回的TTL都不同（bigcommerce、bolia、ikea、stokke、warbyparker），是权威侧动态生成的。只保留稳定的那批，最终数字落在41个。87到46再到41，一个发现在三次收敛里缩掉了一半多。这跟孤岛页面的抽样口径决定结论真假是同一件事：量之前先问清楚手里这把尺子量的到底是什么。

第三次是个被自己推翻的猜想。中途注意到stokke.com的SERIAL从2019103044变成了2019103046，当时的第一反应是“抓到活的了，这个站的日期位是死的、修订位在动”，几乎要当成结论写下来。复核之后发现，那两个值一个来自公共解析器、一个来自权威服务器，是缓存滞后，不是一小时内改了两次。猜想被自己的下一步验证打掉，比它成立更有价值——真按当时那个版本写，后面关于计数器的整节论证都会建在一个假观察上。

顺便说，最后那个关于“修订位大于30就是计数器”的判断，本身也还是推测，正文里已经标明。它和被推翻的那个猜想的区别在于：这一个给出了可证伪的判据，而且不依赖任何单次观察。

自己域名上这七个字段怎么查、哪些该动

查很简单，三条命令，不用装任何东西：

# 查自己域名的SOA
dig +short SOA example.com

# 绕开缓存直接问权威服务器（先取NS，再指定它问）
dig +short NS example.com
dig @ns1.example.com +noall +answer SOA example.com

# 比较根域与www两个名字的TTL
dig @ns1.example.com +noall +answer A example.com
dig @ns1.example.com +noall +answer A www.example.com

Windows下没有dig的话，用nslookup -type=soa example.com也能看到同样的七个值。

拿到之后按这个顺序判断：

还有一条不在表里但更要紧：既然SERIAL在多数平台上不能当变更日志用，就得自己留一份。谁在什么时候为什么改了哪条记录，记在工单或者版本库里。保哥给一家做户外装备的欧洲客户排查过一次邮件投递问题，症结是两年前有人为了测试临时改了MX的优先级，改完忘了回退——当时区文件在AWS上，SERIAL永远是1，从记录里查不出任何线索，最后是翻工单系统翻出来的。这个字段不能替你记事，那就别指望它。

顺着这份区文件往外看，同一个域名根上还挂着决定谁能给你签证书的CAA记录、一堆你可能已经忘了的子域名，以及页面上指着却早已不存在的第三方域名。这些东西和SOA一样，都属于建好之后就没人回头看的那一类。真要做一次彻底的清点，不妨从这份文件的第一行开始，往下一条条走。

常见问题解答

SOA记录会影响SEO排名吗？

不直接影响。搜索引擎不读SOA，它排名的依据里没有这个字段。但它间接影响两件事：一是MINIMUM决定了你新加的记录多久才被全网认，这会拖慢站点迁移、平台验证、结构化数据接入这类动作的生效速度；二是EXPIRE和NS配置关系到解析的可用性，域名解析不了的时候，抓取自然也就停了。所以它不是排名因素，是可用性因素。

SERIAL是1，是不是说明我的DNS有问题？

不是。AWS Route 53给每个区固定写1，这是它的设计，不代表你的区文件没改过，也不影响任何解析行为。它只是意味着你没法从外部通过SERIAL判断改动时间，需要另外记录变更历史。

为什么后台看不到修改SOA的地方？

Cloudflare、Google Cloud DNS、Azure DNS、阿里云这类自助平台默认不开放SOA编辑，因为这四个数字在anycast架构下已经没有传统主从同步的意义，平台统一管理更稳妥。要改只能换成支持自定义的服务，或者自建权威服务器。实测里Cloudflare的26个站四个数字完全一致，就是这个原因。

MINIMUM配大一点不是更省资源吗？

对解析器是省了，对你自己是麻烦。它缓存的是否定答案，配得越大，你新增记录的生效延迟就越长。131个站里有45个配到24小时以上，意味着这些站每次加新记录，都有可能面对最长一天的空窗。合理区间按RFC 2308是5分钟到3小时，要做变更之前提前调小是通行做法。

根域和www的TTL不一样要紧吗？

平时不要紧，切换的时候要紧。两者差一个数量级以上，意味着你做迁移或者故障转移时，两个入口的生效时间不同步，会出现一部分用户已经到新地址、另一部分还在老地址的窗口期。实测131个站里有41个存在这种不一致，其中5个差了两个数量级以上。

怎么确认自己的域名没开放区传送？

先用dig +short NS example.com拿到全部权威服务器，再对每一台执行dig @那台服务器 AXFR example.com。返回大量记录就是开放，返回Transfer failed或者空结果就是关闭。要逐台测，因为可能只有其中一台配错了。本轮131个站全部关闭，但这是因为主流平台默认就关，自建的服务器仍然需要自己确认。

多家DNS服务商并存，需要注意什么？

核心是两边的区文件必须真正一致，而不只是把两家的NS都填上。实测里bigcommerce.com同时挂着NS1和Google Cloud DNS，两家返回的SERIAL、联系邮箱和四个缓存数字全都不同，等于解析器问到谁就按谁的规则办。上线多家之后，应当定期对每一台权威服务器单独查询同一组记录做比对。

权威参考资料