什么是 IPv4 反向 DNS（PTR）？租赁期间由谁控制？

邮件队列越堆越长，退信理由写着 no PTR record。或者某个平台的验证表单要你填 IP 对应的主机名，纯 IP 死活提交不过去。再或者上游日志里你的地址永远是一串数字，看着就别扭。

三种情况最后都落到同一件事上：有人需要给一批地址配反向 DNS，而这批地址不在自己名下。

这时候有用的区分才冒出来——这张图里有两个东西，而大家嘴里的「记录」只是其中之一。

开篇定义： 反向 DNS 是把 IP 地址解析回域名的过程。IPv4 用 in-addr.arpa 域和 PTR 记录类型，两者都定义在 RFC 1035 里。要让一段地址的反向解析真正生效，需要两步：先把反向区委派给你的 DNS 服务器，再在这个区里发布 PTR 记录。租来的地址段，这两步通常不在同一方手里。

一句话说清：被问到的是 PTR 记录，决定你有没有资格回答的，是反向委派。

白脸小鹿用一把小钥匙打开上锁的抽屉，抽屉里已经放着的空白卡片一直没有被碰。

委派负责把区打开，PTR 记录是打开之后你往里放的东西。

1. 一分钟讲清反向 DNS 和 PTR

正向 DNS 是名字指向地址：mail.example.net → 203.0.113.25，存在 A 记录里。反向 DNS 反过来，而 DNS 又是按名字索引的系统，所以得先把地址改写成名字。

IPv4 的做法是把四个八位组倒过来，再接上 in-addr.arpa：

地址：      203.0.113.25
反向域名：  25.113.0.203.in-addr.arpa
PTR 记录：  25.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.net.

这里的 203.0.113.0/24 是 RFC 5737 保留的文档网段，实际使用时换成你自己的前缀。

PTR 记录本身没什么花样。RFC 1035 给它的定义只有一个字段——"A <domain-name> which points to some location in the domain name space"——并且特意指出 PTR "are simple data, and don't imply any special processing similar to that performed by CNAME"。它就是一根指针，不带权限，不带策略，也不做任何校验。

真正让 IPv4 反向 DNS 变得难伺候的是粒度。反向域名里每个标签对应一个八位组，所以最自然的委派单位就是一个 /24。RFC 1035 里有句话把这层设计讲得很清楚，值得记一下："The reversal, though awkward to read, allows zones to be delegated which are exactly one network of address space."

这一个设计决定，几乎解释了后面所有别扭之处：为什么一个 /22 要拆成四次委派，为什么小于 /24 的段不能照常规办、得另用一套机制，以及为什么反向 DNS 的粒度和大家实际部署的前缀粒度对不上。

IPv6 原理一样，只是粒度更细，用十六进制 nibble 反向拼在 ip6.arpa 下。下面仍然只讲 IPv4。

2. 反向委派和 PTR 记录是两件事

RIPE 自己的文档把这活拆得很直白：作为地址持有人，你要做两件事——"First, you have to configure your zone for reverse DNS. Second, you have to request reverse delegation of your zone. The second part is done by creating a domain object in the RIPE Database."

	反向委派	PTR 记录
解决什么	哪个 DNS 服务器对反向区有权威	某个具体地址对应哪个名字
存在哪	父区和 RIR 数据库	你自己的权威区文件
谁控制	对该地址段负责的注册表 maintainer	跑权威 DNS 的那一方
粒度	一个区一次委派；按字节边界切，最小是 `/24`	一个地址一条记录
出错表现	查询根本到不了你的服务器	查询到了，但返回不了有用内容

一个好记的模型：委派把整个互联网的目光引到你的 DNS 服务器上，PTR 记录是你的服务器被问到时的回答。区文件写得再完美、没有委派，也没人看得见；委派指向了服务器、服务器答不出东西，同样等于没有。

而委派要存在，得先有人有权创建它。在 RIPE Database 里，这项权限通过覆盖该地址段的 inetnum 对象上的 mnt-domains: 属性体现——那里写着的 maintainer，才有资格为这段地址创建和维护 domain 对象。这个属性决定「笔在谁手上」，也是租约本身不会自动带来反向 DNS 控制权的原因。

区还得按能用的粒度搭，而这里有两种情况经常被搅在一起。一次委派就是一个区，IPv4 能委派的最小单位是一个 /24：

比 /24 更大的地址块会覆盖好几个 /24 区，因此一个区要一次委派。一个 /22 会变成四个 /24 区、四个 domain 对象、四套要配对的名字服务器。
比 /24 更小的地址块没法按字节边界直接委派——/24 里面已经没有边界可切。但「不能按字节边界委派」不等于「不能委派」。RFC 2317 的做法是把它当作 classless 子区委派出去：父级 /24 区里放一条该范围的 NS 记录，再为范围内每个地址放一条 CNAME，把查询引到一个区名里带着这段范围的子区。详见下文 FAQ。

分配段：   203.0.112.0/22            →  四个 /24 区
反向区：   112.0.203.in-addr.arpa
           113.0.203.in-addr.arpa
           114.0.203.in-addr.arpa
           115.0.203.in-addr.arpa

子段：     203.0.113.64/26            →  没有按字节边界切的区
           改按 classless 子区委派：
           在 113.0.203.in-addr.arpa 里放 NS + 逐地址 CNAME
           （RFC 2317）

RIPE 的委派流程会跑自动检查，出现 ERROR 或 CRITICAL 就整单拒掉；更新成功之后，授权信息最长可能还要 24 小时才会体现在 DNS 里。

白脸小鹿拿着一串钥匙站在四只抽屉旁，最左边的抽屉下方还接着一只更小的子抽屉。

委派是按区走的：大于 /24 的块要拆成好几次，小于 /24 的块则按 classless 子区委派出去。

3. PTR 和正向 DNS 的关系

PTR 和 A 记录回答的是相反方向的问题，而且谁都不验证谁。

	A 记录	PTR 记录
方向	名字 → IP 地址	IP 地址 → 名字
存在哪	你的正向区	你的反向区，挂在 `in-addr.arpa` 下
回答	「这个域名是哪个地址？」	「这个地址是什么名字？」
通过主机名访问 IPv4 服务时需要吗	需要——名字就是靠它解析的	不需要
对端系统拿着地址想查出名字时需要吗	不需要	需要

把这两者串起来的常用做法叫前向确认反向 DNS（FCrDNS）：先查地址拿到名字，再用这个名字查回地址，看是否一致。两头都对上，比只看一头可信得多。至于某个收信系统到底会不会做这项检查、拿到结果后怎么用，那是它自己的策略——这项检查本身是可选的，各家的做法也不一样。

这里有两点实话得说清楚，因为预期往往就错在这。

PTR 记录不保证邮件送达。收信系统碰到缺失或不匹配的 PTR 怎么处理，是它自己的策略，而且它一般还要结合别的证据一起看：认证结果、发信历史、黑名单状态、投诉率、流量特征。PTR 干净是加分项，不是通行证。

PTR 记录修不好 IP 声誉。如果这批地址带着历史来的，改个名字并不会把历史抹掉。那是另一项核查，IPv4 租赁 IP 声誉核查清单讲的就是和这件事并行的检查项。

4. 租赁期间，谁做什么

这一节决定一份租约实际会产生多少工作量。而它最常被搞错顺序——等交付完了、邮件已经在退信了，才开始问。

最容易踩的坑，是以为「拿到了地址」就等于「有权限配反向 DNS」。不是。权限跟着委派权走，委派权跟着注册对象走。

事项	通常由谁持有
覆盖该前缀的注册对象	资源持有方 / LIR
创建 `domain` 对象的权限（`mnt-domains:`）	持有方，通过指定的 maintainer
跑权威反向区	由协议约定，双方都可能
决定 PTR 主机名	一般是客户——只有客户知道服务是干什么的
发布 PTR 记录	跑那个区的一方
提交反向委派变更	持有权限的一方
租约结束时撤销委派	同样是有权限的一方——这一条最常被忘

这三行里最要命的是：

反向委派不属于「拿到地址」的一部分。 租户能不能自己管 PTR，取决于持有方有没有把反向区委派给租户控制的 DNS 服务器。有的租约会这么做，有的按需开放，还有的把 PTR 管理留在持有方手里、通过变更申请收主机名。

自己管有个前置条件。 要接到委派，地址持有人得先在至少两台权威 DNS 服务器上把区配好，并通过注册库的检查。想自己跑反向区的客户，得先有能用的名字服务器，不是拿到委派之后再搭。

租约结束必须提前安排。 地址段还回去了、委派还挂在那里，等于前任租户的 DNS 服务器，对一批自己已经不再持有的地址仍然拥有权威。这种错误会一直存在，而且发生的那一刻不会立刻出问题，所以特别容易留下来。

白脸小鹿把一把钥匙递向一台小型服务器柜，旁边放着一张空白注册卡。

委派权和区域运营权可以分属两方——前提是分工写下来了。

5. 交付前要确认什么

之所以要提前确认，是因为反向 DNS 的依赖会出现在一堆看起来不像 DNS 的地方：邮件接收、某些监控和日志格式、第三方平台的验证步骤，以及任何要你填主机名而不是填 IP 的服务。

有六件事值得写进 Order 或交付材料：

1. 这段前缀的反向委派由谁管理
2. 客户能否直接维护 PTR 记录，还是必须走变更申请
3. 变更怎么提交，预期处理时长是多少
4. 是否有承诺的响应时限，还是尽力而为
5. 主机名命名格式，以及持有方是否要求套某个模板
6. 租约到期时，委派怎么处理

其中两条最容易被跳过，代价也最大。

处理时长。 依赖注册库更新的委派申请不是即时操作——RIPE 文档写明更新成功后最长 24 小时才生效，而区配错一次就得从头再来。项目如果卡着切换窗口，就得把委派这一步算进窗口里。

结束状态。 「以后再撤」不算方案。写清楚由谁撤销、什么时候撤、拿什么证据确认已经撤掉。

白脸小鹿在一张小清单卡上写字，最后一行被单独标出来，旁边放着一张日历。

变更路径和结束状态都属于交付范围，不是事后再补的东西。

SKNK 在 IPv4 地址租赁服务里把反向 DNS 列为可以按合同或 Order 定制的项目。要定的事就在这个层面：前缀、委派模式、变更路径、租约到期处理——和租赁里需要同步安排的 route、ROA、LOA 是同一个形状。

6. 怎么检查反向 DNS

检查也顺着搭建的那条线拆：先看委派有没有覆盖到这段前缀，再看每个地址实际返回什么。

# 1. 这个区有没有被委派出去，委派给谁
dig NS 113.0.203.in-addr.arpa +short

# 2. 单个地址返回什么
dig -x 203.0.113.25 +short

# 3. 前向确认：返回的名字还指得回来吗
dig +short A mail.example.net

结果怎么读：

反向区查不到 NS 记录，通常意味着委派从来没建过，或者建在了和你查询的区名不一样的区上。先确认区边界，再下结论。
NS 记录落在别的区名上，多半是地址块比 /24 大、横跨了好几个区。/22 里的某个 /24 单独被委派出去是正常的，你查到的可能正好是隔壁那个。
委派存在但什么也查不到，说明名字服务器对这个区是应答的，只是具体地址没有 PTR 记录。
PTR 和正向 DNS 对不上，说明至少有一边配错了。提交问题之前，两边都值得看一遍。

反向 DNS 查询与委派检查把第一步自动化了——它会告诉你某段前缀有没有委派、委派在哪些名字服务器上。它不替代对单条记录的核对：一个区已经委派出去、里面却一条 PTR 都没有，委派检查照样通过，而邮件服务器的反向查询照样失败。

白脸小鹿顺着一条指针线走，线在前方分出两条：一条通向敞开的闸门，另一条停在空白面板前。

委派覆盖和记录内容是两个检查，通过其中一个，说明不了另一个。

FAQ

每个 IPv4 地址都必须有 PTR 记录吗？

不需要。反向 DNS 是可选项。只需要发出请求、跑 VPN 或做内部服务的地址，没有 PTR 也照样工作。它在有人会去查的地方才重要：邮件接收、部分平台的验证步骤，以及那些期望拿到主机名的日志和工具。

PTR 记录能保证邮件送达吗？

不能。它只是若干信号之一。收信系统会把 PTR 和认证结果、发信历史、黑名单状态、流量行为一起看，用自己的一套策略判断。一份正确且前向确认过的 PTR，能消掉一个被拒的理由；它不会凭空造出一个被接收的理由。

租户能直接改 PTR 记录吗？

只有在持有方把反向区委派给租户控制的 DNS 服务器时才行。如果委派指向的是持有方的名字服务器，变更就得走持有方。具体适用哪种模式是合同和 Order 层面的问题，不能靠「地址在我手上」推断。

租约结束时，反向 DNS 会怎样？

委派应当被撤销或改指。区里的内容之后怎么处理，是双方约定的事，没有通用规则——有的安排会按约定留档一段时间，有的在终止时就清理，Order 里应该写明是哪一种。地址段还回去之后委派还留着，是实打实的配置错误：前任租户的服务器对一批已经不属于它的地址保持权威。这件事在签约前谈，别等到终止那天。

小于 /24 的前缀有什么不一样？

IPv4 反向区只能按字节边界切，而 /24 内部已经没有边界可切，所以小于 /24 的段没法照常规方式直接委派。但它仍然可以委派出去，作为 classless 子区处理。RFC 2317 讲的就是这套办法：持有父级 /24 区的一方在区里放一条该范围的 NS 记录，再为范围内每个地址放一条 CNAME，把查询引到一个区名里带着这段范围的子区（例如 64/26.113.0.203.in-addr.arpa），由这段地址的运营方自己控制的名字服务器来应答。前提还是那个 /24 区得先存在——子区的委派就挂在它下面。小前缀在路由侧是另一套限制，IPv4 小于 /24 的租赁里讲得很细。

结尾

PTR 记录是看得见的那部分，委派才是需要提前安排的那部分。

反向 DNS 看起来是一个开关，实际是一条链：注册表权限生出委派，委派指向名字服务器，名字服务器发布 PTR 记录，最后由某个收信系统决定拿这个结果怎么办。链上每一环都可能属于不同的人，而在租赁场景里，通常确实如此。

所以在租用期间，真正能推进的问题不是「我拿到反向 DNS 了吗」，而是「委派在谁手上、区由谁跑、变更怎么提」。这三个问题在交付前答完，把租约到期的处理放在同一轮沟通里，反向 DNS 就不会再以「切换两周后邮件发不出去」的形式冒出来。

Key Takeaways：

IPv4 反向 DNS 用 in-addr.arpa 域和 PTR 记录，两者都由 RFC 1035 定义；域名由地址的八位组倒序拼成。
配置分两步：先委派反向区，再在区里发布 PTR 记录。这两件事经常分属不同主体。
委派权限体现在注册对象的 maintainer 范围上——RIPE Database 里就是 mnt-domains: 属性。
IPv4 委派按区走，而区只能按字节边界切，所以常规情况下最小的区是 /24：更大的块要按区逐个委派，更小的块没法按字节边界委派，需按 RFC 2317 作为 classless 子区处理。
PTR 记录既不保证邮件送达，也修不好 IP 声誉；它只是消掉一个被拒的理由。
租约到期处理要提前定：委派还指向前任租户的名字服务器，是一个一直存续的配置错误。

一句话总结： 反向 DNS 分委派和记录两步走，租赁期间起决定作用的是委派——创建委派的权限握在保护该地址段注册对象的 maintainer 手里，不在使用这些地址的一方手里。

继续阅读：

什么是 IP Geofeed？ —— 租用地址段还会牵涉的另一条记录，以及发布它为什么改变不了路由。
IPv4 租赁 IP 声誉核查清单 —— 包含反向 DNS 和发信限制的签约前检查。
IPv4 小于 /24 的租赁 —— 前缀更小时，路由和委派分别有什么变化。
IPv4 租赁中的 route、ROA、LOA —— 和反向 DNS 并行的路由侧记录。
如何租用 IPv4 地址 —— 租赁转移了什么、没转移什么。
SKNK IPv4 租赁 —— 价格、范围，以及可以按 Order 定制的项目。

技术资料核对： RFC 1035（域名实现与规范）、RFC 2317（无类 IN-ADDR.ARPA 委派）、RFC 1912（常见 DNS 运维与配置错误）、RFC 5737（IPv4 文档保留网段）、RFC 3849（IPv6 文档保留前缀）、RIPE Database 反向 DNS 配置文档。