摘要

  • LOC 分别保存实体大小、水平与垂直误差，以及位置坐标。多写几位小数，不能替代对位置不确定性的说明。
  • 水平精度字段表示误差圈的直径。文本格式省略该值时，默认是一万米，而不是十公里半径，也不是一米的定位精度。
  • 从主机查询回退到网络位置，会改变结果描述的对象；DNS 缓存有效期和数字签名都不能证明坐标何时被实地测量。

十公里藏在省略号里

一条记录可以把实体大小写成一米，同时承认它的位置只能落在一个直径十公里的水平误差圈内。这不是格式自相矛盾，而是两条不同信息：对象可能很小，发布者对它在哪里却未必知道得很准。

1996 年 1 月的实验性文档 RFC 1876 为 DNS 定义了 LOC 记录。它的文本写法允许省略大小、水平精度和垂直精度，默认值依次是一米、一万米和十米。文档把这些选择与按邮政编码取得粗略地理位置的现实联系起来。

省略并不意味着信息消失了。转成零版本的二进制记录时，相应字段仍然存在，只是采用默认值。消费者若只提取经纬度，便可能把发布者原本保留的粗略程度一并丢掉。

因此，地图上的小针头不是协议承诺。它可以只是绘图软件选择的符号。若读者把符号的尖端当成一项精确测量，错误未必出在 DNS 回答的数字，而可能出在从回答到图像的那一步。

本地维护，全球能问

这个构想有清楚的历史背景。1994 年 11 月的实验性 RFC 1712 提出了 GPOS 记录，希望让地理信息由本地维护，又可以通过 DNS 被外界查询。

文档讨论的困难包括集中维护 UUCP 地图时的更新和核对问题。它也比较了 SNMP 的 sysLocation：这类描述常与具体代理、读取权限和房间位置有关；当时 X.500 的部署状况同样影响了方案选择。这些是九十年代设计者面对的条件，不能拿来当作今天各系统覆盖率的调查。

DNS 的吸引力不在于会测量，而在于已经有一套分散维护、按名字查询的机制。负责某个名字的人可以发布其位置描述，应用不必等待一张中央地图逐项更新。

但这只是把维护位置陈述的工作交给了本地，并没有把本地管理员变成测绘机构。谁能修改名字下的数据，与谁有证据证明设备在某处，是两种权力。

先要说清哪一条轴

GPOS 用三个可打印的数值字符串表示地理分量，不是把三个 IEEE 浮点二进制数直接放进 DNS。字符串可以写出许多小数位，但位数本身并不证明输入数字的来源。

更细小的历史问题藏在名称里：RFC 1712 原文对经度、纬度的名称与定义存在互换问题。2006 年报告的官方 勘误 541 指出了这一点，并提出保留数值次序、改正相应标签的办法。它目前的状态是 Held for Document Update，即留待文档更新处理，并非 Verified，也不能说原规范已经被正式改写。

这提醒读者，面对老格式，不能只看数字能否解析，还必须核对数字被解释为什么。这里不复写原文的坐标例子，也不把一项待处理勘误当成所有实现都已遵循的共同规则。

1996 年的 LOC 采取了另一种表示办法。不过，RFC 1876 并未声明废止 RFC 1712。IANA 的 DNS 参数登记表 仍分别列出 GPOS 的类型号 27 和 LOC 的类型号 29。两个编号的存在说明格式已登记，不能据此推断哪一个被广泛采用，或有多少运营者持续更新。

十六个字节不是一把尺

LOC 零版本的 RDATA 长十六字节。版本、实体大小、水平精度和垂直精度各占一字节；纬度、经度和高度各占四字节。这里的十六字节只指数据部分，不包含整条资源记录或整个 DNS 报文。

纬度和经度以千分之一角秒为单位，用带偏移的三十二位整数保存。二的三十一次方对应赤道或本初子午线，较大的值朝北或朝东。它不是通常那种把正负经纬度直接塞进有符号整数的写法。

精细的编码格子，只说明格式能够区分相邻数值。它没有说发布者使用了什么仪器，也没有说测量发生在什么时候。经度所对应的地面距离还随纬度变化，不能把一个角度单位随手换成处处适用的固定米数。

同样，版本号不是装饰。零版本规定了这一套布局，遇到不认识的版本，读取者必须检查，而不能假设后面的字节仍然具有相同意义。能够传输一串完整数据，不等于已经正确理解它。

大小、误差和显示比例

SIZE 描述能包住实体的球体直径，单位为厘米。水平精度描述水平误差圈的直径；垂直精度描述可能垂直误差的总范围。三者都不能随意当成“正负这个数”。若要换成相应的正负范围，应先理解总宽度与半宽度的区别。

这也不是一组统计置信区间。RFC 没有给这些字段附上某个概率水平，不能自行添加“百分之九十五落在圈内”的解释。误差圈记录的是发布者提供的精度描述，不是独立测量得出的分布模型。

三个字段采用紧凑的十进制表示：一个半字节保存一位有效数字，另一个保存十的指数，最终按厘米解释。各半字节只定义了零到九；零有效数字搭配非零指数的组合也没有定义。特殊的零乘十的零次方表示小于一厘米，不是数学意义上的绝对零误差。

这种编码让很小的对象和很大的范围都能写进有限空间，却不承诺任意多位有效数字。应用若为了界面整齐，把坐标输出到很多小数位，再把大小或误差隐藏起来，就可能增加视觉上的精确感，同时减少实际信息。

高度从哪一层算起

高度又有自己的参照。LOC 使用 WGS84 参考椭球面，并将存储基点放在该参考面以下十万米，以厘米计数。因此，相对椭球面零米的高度，编码数值是千万厘米。

这个偏移是表示方法，不是让现实中的设备突然升高一百公里。它也不意味着平均海平面就是参考椭球面。RFC 允许在相应调整高度或垂直精度的情况下使用海平面近似，但不能把不同基准直接混为一谈。

文本文件还有一个容易误读的边界：高度、大小和精度通常按米书写，线上的相关数值按厘米解释。正确的解析器应完成单位和基准的处理；读者不能因为两个数字表面相同，就认定它们描述同一高度。

查主机，答的是哪一个对象

LOC 不只描述主机，也可以描述网络和子网。RFC 1876 因而给应用提供了回退办法，但回退不是发现了同样精确的另一份主机测量。

从名字出发，应用先查询该名字的 LOC，按通常规则跟随 CNAME。没有直接位置时，可以借助相关 A 记录寻找网络或子网的位置。从 IPv4 地址出发，则先经 IN-ADDR.ARPA 反向查询得到名字，再查该名字的 LOC；不能简单地说 LOC 一律存放在反向地址名字之下。

可选的网络回退借用了 RFC 1101 的历史网络命名方法。该文档用特殊反向名字下的 PTR 和 A 形式数据组织网络、子网名称；其中某些 A 形式数据表示子网掩码，并不是服务正在监听的地址。

LOC 的过程据此收集网络与子网名称，再从更具体的名称向较宽范围寻找位置。它不是沿普通 DNS 父标签逐级向上，也不是 BGP 的最长前缀转发规则。这是一套带有当时 IPv4 和分类网络背景的办法，不应当直接包装成今天适用于 IPv6 的操作指南。

回退的用意是：没有细位置，也可以画出更粗略、更大的区域。但返回的网络位置仍然描述网络。把它贴成某台主机的实测地点，会改变陈述的对象。多地址主机还可能产生多个网络位置，规范把使用其中哪些、是否组合的选择留给应用，而不是保证只有一个天然正确的图钉。

还在缓存里，不等于刚测过

DNS 的时间也有边界。RFC 1035 的资源记录包含所属名字、类型、类别、TTL 和数据等部分。TTL 管的是缓存多久后应重新向来源取得数据，不是距离一次地理测量已经过去多久。

2005 年的 RFC 4033 又区分缓存一致性的 TTL 与 DNSSEC 签名的有效期。签名可以提供数据来源认证和完整性保护，却没有给 LOC 增加实地调查日期，也不提供保密性。

由此可以作出一个有限但重要的推论：一条来源真实、未被篡改的记录，仍可能使用陈旧坐标、错误单位或不恰当的对象范围。认证是谁发布了这句话，不能自动证明这句话对物理世界的描述正确。

LOC 曾被设想用于可视化 traceroute、网络管理地图等场景，但登记地点并不等于包实际经过的地点。一个 IP 跳点对应的名字与位置陈述，不能单独还原完整物理线路。

最后还有公开性的代价。RFC 1712 明说进入 DNS 的信息是公开信息；RFC 1876 提醒，高精度地理位置可能增加物理安全风险。文献中的警告不是某起攻击已经发生的证据，却说明“能发布多准”与“应该公开多准”从来不是同一个问题。