子域名是网站架构里非常常见的组织方式，比如把博客放在blog.ippipp.com，把接口服务放在api.ippipp.com，把管理后台放在admin.ippipp.com。这些子域名之所以能各自指向不同的服务器，靠的就是DNS解析配置。这篇文章把子域名DNS解析的原理、记录类型的选择、具体配置步骤以及常见坑逐一讲清楚。
一、先搞懂DNS解析的基本原理
DNS的本质是一个分布式的名称映射系统，它把人类容易记住的域名翻译成机器使用的IP地址。当你在浏览器里访问blog.ippipp.com时，整个解析过程大致是这样的：浏览器先检查本地缓存和操作系统的hosts文件，如果没找到，就把查询请求发给本地配置的递归DNS服务器（也就是运营商或者公共DNS如114.114.114.114）。递归服务器如果也没有缓存，就会从根服务器开始，一层一层询问.com、ippipp.com的权威DNS服务器，最终由ippipp.com的权威服务器返回blog.ippipp.com对应的记录。
理解这个过程对配置子域名很关键，因为子域名的解析权可以下放。ippipp.com的权威DNS服务器上保存着所有子域名的记录，你可以直接在主域名的解析控制台里添加子域名记录，也可以把某个子域名的解析权委托给另一组DNS服务器，这就是NS记录的作用。绝大多数场景用前者就够了，只有大型站点或多团队协作时才会用到解析权下放。
还有一个概念必须提前弄明白：TTL（Time To Live）。每条DNS记录都带一个生存时间，单位是秒，它决定了这条记录可以在递归服务器上被缓存多久。TTL设得长，解析查询量小、用户访问快，但修改记录后全球生效慢；TTL设得短，改动生效快，但查询压力增大。常见的默认值是600秒，如果计划近期切换服务器，可以提前把TTL调低到60秒甚至更短。
二、常见记录类型怎么选
添加子域名记录时，第一个要做的决定就是选记录类型。选错类型轻则解析异常，重则引发冲突。下面是最常用的几种：
- A记录：把子域名直接指向一个IPv4地址，比如blog指向1.2.3.4。这是最基础、使用最广泛的记录类型。
- AAAA记录：作用和A记录一样，只不过指向的是IPv6地址。目前国内IPv6普及率已经不低，建议有条件的服务器同时配置A和AAAA记录。
- CNAME记录：把子域名指向另一个域名，而不是IP。常见于接入CDN、对象存储、云服务商托管的场景。注意CNAME不能和A记录共存于同一个主机名，也不能出现在域名的顶端（zone apex）。
- MX记录：邮件交换记录，用于指定处理该域名邮件的服务器。一般配置在主域名上，子域名需要独立收信时才配置。
- TXT记录：存放任意文本，最典型的用途是域名所有权验证（比如申请SSL证书时的验证）和SPF、DKIM等邮件防伪配置。
- NS记录：把某个子域名的解析权委托给其他DNS服务器，前面提到的解析权下放就靠它。
举个具体例子来对比。假设你的服务器IP固定不变，直接给api子域名加一条A记录即可；如果站点接入了CDN，CDN服务商会给你一个类似xxx.cdn-provider.com的接入域名，这时就应该给子域名配置CNAME记录指向它。很多人图省事，本该用CNAME的地方硬填了一条A记录指向CDN的某个节点IP，结果CDN节点变更后站点直接打不开，这是典型的配置错误。
还有一种容易被滥用的配置叫泛解析，也就是主机记录填星号，让所有未明确配置的子域名都指向同一个地址。泛解析配合SSL证书的通配符域名使用确实方便，但它也意味着任何随意的子域名（比如被人恶意传播的链接）都能解析到你的服务器，建议仅在确实需要动态生成大量子域名的业务中使用，并且配合严格的服务端校验。
三、实战配置：从添加记录到验证生效
以主流域名服务商的解析控制台为例，配置一个子域名的完整流程如下。第一步，登录域名管理后台，进入DNS解析设置页面。第二步，点击添加记录，依次填写四项内容：
主机记录：blog （即 blog.ippipp.com 中的 blog 部分） 记录类型：A 线路类型：默认 记录值：1.2.3.4 （服务器的公网IPv4地址） TTL：600 （单位秒，10分钟）
保存后记录通常会立即写入权威DNS，但全球生效需要时间，具体取决于旧的TTL。配置完成后不要只靠浏览器访问来验证，浏览器自身的DNS缓存和操作系统缓存都可能干扰判断。更可靠的方式是用命令行工具直接查询权威服务器：
# Linux / macOS 使用 dig，@后面指定公共DNS服务器 dig blog.ippipp.com A +short # 指定从域名的权威服务器查询，绕过所有缓存 dig @ns1.ippipp.com blog.ippipp.com A # Windows 使用 nslookup nslookup blog.ippipp.com
如果dig返回的结果和刚配置的IP一致，说明权威侧已经生效；如果本地访问还是旧IP，那就是缓存问题，等TTL过期即可。Windows下可以用ipconfig /flushdns清空本地DNS缓存，macOS下对应命令是sudo dscacheutil -flushcache。
补充一个配置CNAME时的细节。子域名接入云服务时，有些服务商要求先完成域名归属验证，通常会要求你添加一条特定值的TXT记录，验证通过后CNAME才会正式生效。遇到这种情况不要省略验证步骤，否则功能会莫名失效且很难排查。
四、常见问题排查与避坑要点
实际配置中，子域名解析不生效是最常见的问题。排查时建议按固定顺序来：先确认记录已正确保存，再查询权威服务器是否返回预期结果，然后检查本地缓存，最后才怀疑网络链路。dig命令加上+trace参数可以看到从根服务器到权威服务器的完整查询链路，定位中间某一环的问题特别有用。
几个高频踩坑点值得单独强调。第一，CNAME与A记录冲突：同一个主机名下已经存在CNAME，再加A记录会被拒绝或产生未定义行为，修改前先删除旧记录。第二，TTL的误判：改了记录立刻测试发现没生效，就反复删了重加，这种操作只会让缓存更加混乱。正确做法是提前降低TTL，等旧缓存过期后再改记录值。第三，国内域名解析到境外服务器或者未备案的境内服务器，会涉及备案要求，不是技术问题但会导致访问被阻断，容易被误判为DNS故障。第四，公司内网环境里，子域名可能由内部DNS单独管理，公网上的配置和内网看到的结果可能完全不同，排查时要注意区分查询来源。
最后给一个通用的配置建议：生产环境的子域名尽量做到职责单一、命名规范，比如按用途划分为api、www、static、admin等，并在文档中维护一份解析记录清单。子域名数量一多，缺少清单的DNS控制台很快就会变成没人敢动的黑盒，那时候排查一次故障的成本会远远高于当初认真记录的几分钟。把DNS配置当作代码来管理，配合较低的TTL和清晰的记录命名，子域名解析这件小事就能长期稳定省心。