免费子域名，首先要分清“你拥有了什么”#

社区里常把“免费域名”“免费二级域名”和“免费 DNS”混在一起讨论，但这三者的控制权完全不同。材料中的 nya.je 服务，实际描述的是：用户注册账号后创建一个子域名，并在管理页面配置 A、AAAA、ALIAS、CNAME、SRV、TXT 等记录；同一账号只能注册一个子域名。这个模型更接近“平台分配的子域名空间”，而不是用户获得了一个可以自由转移、续费或设置注册局状态的独立顶级域名。

Zerexa Domains 的公开页面则把服务展示为“¥0 DNS”“30s DNS”，并提供中文和英文入口。这里能确认的是服务定位和公开的产品入口，不能据此推导出所有解析记录都具备相同的生效速度，也不能推导出平台对可用性、迁移、滥用处置或长期保留做出了什么承诺。工程上最重要的第一步，是把“注册成功”与“长期拥有控制权”拆开。

对于一个子域名，用户通常拥有的是某个名称下的记录编辑权，例如 app.example.tld，而平台仍然控制更高层级的 example.tld、权威 DNS 集群、账号策略和删除规则。平台一旦收回父域、调整 DNS 服务，或者改变注册资格，子域名使用者就没有独立的注册局申诉和转移路径。这就是免费服务最核心的信任边界。

一个子域名平台至少包含三个控制面#

可以把这类服务抽象成三个相互依赖的控制面。

第一层是身份与配额控制面。用户通过邮箱和密码完成注册，再进入 Dashboard 创建名称。社区材料提到某服务支持邮箱验证码，并限制一个账号只能创建一个子域名。这个限制不是简单的产品细节，而是平台治理的一部分：它决定了批量注册、抢注、滥用和资源回收的成本。邮箱验证能降低低成本脚本注册，却不能等同于实名、KYC 或稳定身份，因为材料并未证明平台采用了这些机制。

第二层是命名空间控制面。平台需要判断用户申请的标签是否已经被占用，并将该标签绑定到账号。这里至少存在三个工程问题：名称是否区分大小写；名称释放后是否立即重新开放；账号被封禁后记录是否仍保留。材料只明确了一账号一子域和“未被注册即可创建”的交互描述，未说明释放、转移和回收规则，因此这些都应该被视为未知风险，而不是默认能力。

第三层是 DNS 记录控制面。A 和 AAAA 记录分别指向 IPv4 与 IPv6 地址；CNAME 用于别名；SRV 可表达特定服务的主机与端口；TXT 常用于验证和策略发布；ALIAS 则通常是平台对根记录别名能力的抽象。用户界面列出记录类型，并不意味着每一种记录在所有递归解析器、验证器和下游服务中都具有相同的行为。尤其是 CNAME、ALIAS 与 HTTPS 证书验证之间，不能靠页面上的“支持”二字直接判断兼容性。

先验证权威链路，再验证业务可用性#

使用免费子域名部署网站、Webhook 或邮件相关服务时，建议先做一套与平台宣传无关的 DNS 验证。以下命令只依赖常见 DNS 工具：

1
# 查看当前解析结果
2
 dig +noall +answer app.example.tld A
3
 dig +noall +answer app.example.tld AAAA
4

5
# 查看权威委派链路
6
 dig +trace app.example.tld
7

8
# 直接询问系统配置的递归解析器
9
 dig app.example.tld CNAME
10
 dig app.example.tld TXT
11

12
# 从多个公共递归解析器观察结果
13
 dig @1.1.1.1 app.example.tld A
14
 dig @8.8.8.8 app.example.tld A

第一组命令验证记录是否存在，不能证明已经完成全球传播。+trace 的目标是观察从根、顶级域到权威服务器的委派过程；如果链路中出现超时、SERVFAIL 或权威服务器不一致，应先定位委派问题，而不是反复刷新业务页面。公共递归解析器的结果用于发现缓存差异，但它们同样不是绝对真相，因为 TTL、负缓存和区域策略都会影响观察结果。

如果平台提供 TXT 记录，最好把它用于一个无风险的验证域名，而不是立即绑定生产证书或关键回调。例如先发布随机值：

1
printf 'dns-check-%s\n' "$(date +%s)"
2
# 将输出内容写入 TXT 后，再执行：
3
 dig +short app.example.tld TXT

验证时应记录查询时间、查询服务器、返回内容和 TTL。这样即使后续解析异常，也能区分“平台没有保存记录”“权威服务器没有发布”“递归缓存尚未更新”和“业务服务本身不可达”。

“30 秒 DNS”不能替代可观测性#

Zerexa Domains 页面使用了“30s DNS”的产品表达。这个表达可以作为服务定位线索，但工程判断不能把它当作无条件的全球生效承诺。DNS 的可见性至少受四个因素影响：权威服务器何时加载变更、记录 TTL 如何设置、递归解析器是否已有旧缓存、查询者所在网络是否经过额外缓存层。

因此，验证“更新是否生效”时，不要只在浏览器里打开一次页面。更可靠的检查方式是保存旧值和新值，在不同时间点查询多个解析器，并同时检查权威回答。如果权威服务器已经返回新值，而公共解析器仍返回旧值，问题可能是缓存；如果权威服务器之间结果不一致，则更接近平台发布链路或区域配置问题；如果 DNS 返回正确但 HTTP 失败，则应转向证书、端口、源站或 CDN 检查。

这也解释了为什么 DNS 服务需要控制面和数据面分离。控制面负责账号、名称和记录变更；数据面负责把最终区域内容发布到权威服务器。一个页面操作成功，只能说明控制面接受了请求，不能自动证明数据面已经完成一致发布。

免费平台最容易忽略的失败边界#

第一种边界是名称归属变化。子域名通常依赖平台父域。一旦父域暂停解析、过期、被更换 DNS 提供商或遭到注册管理限制，用户即使保留账号也无法独立修复。对于博客、演示站点，这种风险可能可以接受；对于密码重置、支付回调、生产 API 或企业邮件，却不应把它作为唯一入口。

第二种边界是平台策略变化。材料显示某服务会限制账号配额，并提醒某些能力只是传闻、尚未实现。这个细节说明功能列表必须以当前可验证行为为准，不能把“听说会支持 NS”写进架构设计。NS 委派一旦没有被平台正式开放，用户就不能假设自己拥有下一级 DNS 的完整管理能力。

第三种边界是第三方平台兼容性。某些托管商要求用户控制独立域名、修改 NS、添加特定 TXT 或 CNAME；免费子域名只具备记录编辑权时，可能无法满足这些验证流程。即便证书签发成功，也不能推出未来的续期流程一定成功，因为验证记录、CAA 策略和平台访问控制都可能变化。

第四种边界是回收与滥用处置。免费资源通常需要平台控制垃圾邮件、恶意软件、钓鱼和批量占用。用户必须确认是否存在停用、申诉和数据保留机制。材料没有给出完整条款时，应把“没有看到限制”视为信息缺失，而不是“没有限制”。

一份部署前检查清单#

在把免费子域名接入任何真实服务前，可以按下面顺序检查：

1. 确认自己拿到的是独立注册域、平台子域，还是仅仅一条 DNS 记录；
2. 保存服务条款、注册时间、账号邮箱和当前记录快照；
3. 验证 A、AAAA、CNAME、TXT 等实际需要的记录，而不是只看界面选项；
4. 用 dig +trace 确认委派链路，并从至少两个递归解析器观察结果；
5. 测试删除、修改和再次发布记录，确认失败时是否有明确错误；
6. 不把该域名作为唯一的登录恢复、支付回调、邮件收件或 API 入口；
7. 为关键服务准备可迁移的备用域名，并把 DNS 记录以文本或配置文件保存；
8. 定期检查证书续期、解析结果、HTTP 状态码和平台账号通知。

其中最容易被跳过的是第七项。备用域名不是要求同时运行两套生产系统，而是确保平台失效时仍能发布迁移通知、切换客户端或恢复管理入口。对免费服务来说，迁移能力本身就是可靠性的一部分。

工程取舍：把它当入口，不要当根基#

免费子域名适合低成本个人主页、临时演示、测试环境、开源项目预览和一次性验证。它的优势是开通门槛低、无需先购买独立域名，并且可以快速验证 DNS 记录和部署流程。对于学习 DNS、自动化发布和证书申请，它也是一个足够真实的练习环境。

但它不适合承载不可替代的身份和长期资产。原因不是“免费一定不可靠”，而是控制权不完整：父域、权威服务器、账号策略和平台存续都由第三方决定。更稳妥的组合是：用免费子域名做开发与展示，用自己注册的独立域名做核心身份；在应用层通过配置管理域名，在 DNS 层保存可迁移记录，在监控层同时检查解析与业务响应。

这类服务真正值得观察的指标，也不是“注册按钮是否能点通”，而是控制面变更能否被验证、数据面发布是否一致、异常时有没有可解释的错误、资产能否迁移以及平台能否明确处理滥用。只要按照这套标准检查，免费子域名就不再是一个“能不能用”的二元问题，而会变成一个边界清晰、风险可分级的工程组件。

参考资料#

• 免费短域 nya.je 永久免费，大量两位前缀可注册
• nic.fj.kg