背景
平台跑起来之后，我意识到一个一直存在但被忽略的事实：DNS 记录里的 IP 是个裸值——它不知道该不该被用、有没有被回收、之前是谁在用。给"名字→IP"的映射建了平台，但"IP 本身"的账，还记在一本 Excel 上。
这一篇讲 IPAM（IP 地址管理）：为什么它是企业 DNS 的另一半，以及我为什么最后只做了一半的它。
三个事故
先说没有 IPAM 的代价，三个都真实见过：
流量串号。服务下线了，DNS 记录没删；IP 被回收，又分给了另一台机器。B 团队的调用还指着旧域名，流量直接打到了 C 的机器上。排查时两边都觉得委屈：调用方说"我走的是域名啊"，被打的机器说"我根本不认识这个服务"。
反向查人两小时。安全设备告警：某内网 IP 有异常外连。这个 IP 是谁的？翻 Excel（三个月没更新）、问群（没人认领）、查 CMDB（没有这台机器）。两小时后发现是某台临时测试机，主人早就休假了。
幽灵网段。要扩容，问"10.42.0.0/24 还有多少可用？“没人知道。段里注册的、实际在用的、早就不在但没删的，三个数字对不上，最后只能拍脑袋再申请一段。
三个事故的共同根源：IP 的分配、使用、回收没有账本，或者账本和现实早就脱节了。
IPAM 的数据模型
教科书式的 IPAM 有两个核心对象。
网段树。网段按层级组织：10.0.0.0/8 下面分地域/机房/用途。层级本身就是信息——权限可以继承（这个段归网络团队管），统计可以上卷（这个机房的利用率是多少）。
IP 状态机。每个 IP 有状态：available（可用）→ allocated（已分配）→ reserved（保留）→ deprecated（弃用冻结）→ 回到 available。特别说一下 deprecated 这个状态：删服务时 IP 不是立刻回收，而是冻结一段时间——防止"刚删就被分给别人"的串号事故。冻结期是对人性（或者说对缓存、对陈旧配置）的尊重。
与 DNS 的四个联动
IPAM 单独存在没有意义，它的价值全在和 DNS 的联动上：
- 建 A 记录时校验占坑：用户建
api.xx → 10.42.3.17，平台检查这个 IP 在 IPAM 里的状态——不是 allocated 或者不属于任何已知段，就提示确认。 - 自动生成 PTR：A 记录建好的同时，反向记录自动落好，不用人维护两份。
- 删记录时冻结回收：删除 A 记录，IP 进入 deprecated 冻结期，过了期限才回 available。
- 三路对账：这是灵魂，单独讲。
没有扫描对账的 IPAM，只是好看的 Excel
IPAM 最大的失败模式是台账和现实脱节——人登记的时候是真的，三个月后一半是假的。防脱节只有一个办法：对账，而且必须是三方互对：
IPAM 台账（人声明的） ←→ DNS 记录（系统在用的） ←→ 网络扫描（实际活着的）
- 台账有、扫描没有 → 幽灵记录，该清理
- 扫描有、台账没有 → 私接设备，该登记
- DNS 有、扫描没有 → 僵尸记录，进入回收流程
扫描手段可以很朴素：ping 扫段、ARP 表、交换机 MAC 表，按条件选。重点不是手段，是定期跑、出漂移报告。没有对账机制的 IPAM，只是一本更好看的 Excel——这句话我对所有宣称"我们有 IPAM"的团队都说过。
一个关键转折：A 记录就是 IP 使用声明
设计到这里，我突然意识到一个事实，它把整个方案砍轻了一半。
IPAM 的核心问题之一是"这个 IP 谁在用”。而我们的平台里，用户建一条 A 记录，本身就是一次 IP 使用声明：api.zhangsan.user.xx → 10.42.3.17 这条记录同时声明了名字、IP、owner（域名里带着 zhangsan）、时间（审计日志）。
也就是说，DNS 平台本身就是 IP 使用状态的天然数据源。再建一套 IP 级的实体台账，让用户在 DNS 里登记一遍、在 IPAM 里再登记一遍，是重复劳动——而重复登记的台账，必然脱节。
轻 IPAM：只管段，不管 IP
转折之后的最终形态是"轻 IPAM"：
- 段是主体：网段树照建，段级的用途、归属、容量规划数字化（本质是把原来那本 Excel 结构化）。
- IP 不建实体：不维护"每个 IP 一条记录"的数据库；IP 的使用状态从 DNS 记录实时推导。
- 两级反查链：查一个 IP 是谁的，先查 DNS 精确反查（有 A 记录就知道名字和 owner）；查不到再查段台账兜底（知道这个段归谁管，至少找得到人）。
- 零成本指标：段的"DNS 可见使用率"（段里有多少 IP 被 A 记录引用）直接算出来，不用扫描就知道大致水位。
对账因此也降级了：不做 IP 级的全网扫描，做段级的一致性检查——段的声明用途和实际 DNS 记录是否相符。扫描只做抽样，不当主机制。
一句话总结这个架构：
IPAM 的"IP"下沉给 DNS 记录，IPAM 本体只管"AM"——地址段的账本。
PTR 的技术坑
反向解析有几个内网特有的幸福点，值得记录：
- 非字节边界的委托很丑：公网做
10.0.0.0/8 的子段 PTR 委托，要走 RFC 2317 的 CNAME 技巧，非常难看。内网的幸福点是可以把 10.in-addr.arpa 整段拿在自己权威手里，想怎么分怎么分。 - 一个 IP 多个名字时 PTR 指主名字：PTR 只有一条，指向"这台机器的本名"，别名留在正向。
- IPv6 不做：内网 IPv6 还没铺开，PTR 的树深 128 位，第一期直接放弃。
最后
企业现实的底色要承认：大部分公司的 IP 管理就是一本 Excel，段的划分权在网络团队手里（生产段、测试段、DMZ 段）。轻 IPAM 不试图颠覆这个现实，只做三件事：把 Excel 结构化、把 IP 状态交给 DNS 推导、把对账做成定期的例行公事。
DNS 记录里的 IP 是裸值——它不知道自己该不该被用。
没有扫描对账的 IPAM，只是好看的 Excel。
Infoblox 的护城河其实是 IPAM，不是 DNS——商业 DDI 卖的就是这本账，这点在竞品篇还会回来。
IP 的账有了着落，接下来是更细的一个问题：从一条记录回溯"这是谁的、为什么存在"——PTR、TXT 和台账之间的分工，中间还包含一次我自己的设计纠偏。下一篇。