[New Feature] 为 DN42 成员专用于 DN42 基于本地 rDNS 信息的地理位置解析模式

[sjlleo]

基于目前没有任何路由跟踪工具提供了对 DN42 较好的支持，我们决定单独为 DN42 玩家开发一个专用于 DN42 网络路由跟踪的模式。

在这种模式下，所有的 rDNS PTR 匹配全部将由本地完成，我们将从现有 LeoMoeAPI 后端抽象出一个极度精简的判断模型，以帮助用户更好的显示自己的 DN42 路由结果。

该模式支持自行导入一个 CSV GeoFeed 文件，这样您可以自定义您的地理位置特征信息，方便 NextTrace 鉴别该 IP 的地理位置。

诚然这个模式也可以用于公网的自有 ASN 路由跟踪，因为它不会向 LeoMoeAPI 发送任何 IP 请求，所以一定程度上保护了您的骨干网隐私，并也加快了路由跟踪速度。

NextTrace Project Leo

[Diffused7245]

做了我一直想做的事，赞！ 据我的观察，rdns中命名的方式一般是所在城市的机场IATA 代码，比如洛杉矶是LAX，这样可以区分出来。然而对于东京这类的不通，东京的成田机场是NRT，和Tokyo八杆子打不着边，因此有缩写tyo或者tko的，另外还有公网上看到缩写ngy的，认识那些城市名字的人一看就知道是名古屋市，但是机器怎么去识别呢？可以自动从城市的英文名Nagoya匹配吗？ 至于国家级别就好匹配了，一般是2字母缩写，中国cn，美国us。未匹配到的以IP中填写的country字段显示到国家即可。比如v6。 如果要做，可以增加一个收集并上报rdns信息的功能，来自动完善DN42归属地数据库，IP所有者发现地理位置不对可以验证asn后修改。 网络名就以包含了胶水记录的那个域名来命名（如果站长有多个域名的话），例如我有marionic.dn42和in.dn42，主要的域名是前一个，就以它命名。

[tsosunchia]

据我的观察，rdns中命名的方式一般是所在城市的机场IATA 代码，比如洛杉矶是LAX，这样可以区分出来。然而对于东京这类的不通，东京的成田机场是NRT，和Tokyo八杆子打不着边，因此有缩写tyo或者tko的，另外还有公网上看到缩写ngy的，认识那些城市名字的人一看就知道是名古屋市，但是机器怎么去识别呢？可以自动从城市的英文名Nagoya匹配吗？

“据我的观察，rdns中命名的方式一般是所在城市的机场IATA 代码，比如洛杉矶是LAX，这样可以区分出来。然而对于东京这类的不通，东京的成田机场是NRT，和Tokyo八杆子打不着边，因此有缩写tyo或者tko的，另外还有公网上看到缩写ngy的，认识那些城市名字的人一看就知道是名古屋市，但是机器怎么去识别呢？可以自动从城市的英文名Nagoya匹配吗？” 至少这部分NT已经实现并已经应用了，其他的可能还需要owner来回答。 感谢您的建议

[sjlleo]

Hi Marionic0723,

感谢您的提出的建议，您提到的机场 IATA 的问题，我们目前维护了一张表，这张表会收录一些 T1 ISP 常见的写法，您可以在这里找到它^1，并且向我们提交 PR，这样我们系统就会 Merge 您的记录，在下次匹配时即可正常匹配，目前我们 LeoMoeAPI 后端的系统已经部署了这个功能，它能够很好地自动化校准一些 T1 的 IPv6 骨干网，帮我们节省了不少时间和精力。

关于 DN42 的 rDNS 解析的问题，因为考虑到很多玩家并不会和 T1 一样使用比较常见的方法标注自己的骨干网（事实上，如果把使用机场的 IATA 视为标准的话，很多 T1 的 rDNS 标注也不规范），所以我想在开发的时候提供一个 CSV 文件专用于存储自定义的 rDNS 信息。

当然我们会预先准备一些常见的 rDNS 数据硬编码于 NextTrace 中，如果 NT 可以找到用户自定义的 rDNS CSV 文件则优先使用 CSV 文件中的数据进行匹配，如果未能找到，再使用 NT 内置的常见 rDNS 数据表进行查询。

在做匹配的时候，最难的并不是匹配不上，而是匹配了错误的数据，也就是误匹配，我见过一些 DN42 玩家使用了奇怪的 PTR 记录来标注自己的 IP，比如 us-cnix.dn42，这种情况存在误将 cn 视为该跳地理位置的可能性，所以我想在匹配时多匹配一位，比如查看 cn 后面是否会是一个数字，或者是 "-", "." 特殊符号等等（即使用正则匹配）^2，来减少误匹配的情况，具体详见Paper，下面为示意图，如图 1 所示。

图 1

[Diffused7245]

Hi Marionic0723,

感谢您的提出的建议，您提到的机场 IATA 的问题，我们目前维护了一张表，这张表会收录一些 T1 ISP 常见的写法，您可以在这里找到它1，并且向我们提交 PR，这样我们系统就会 Merge 您的记录，在下次匹配时即可正常匹配，目前我们 LeoMoeAPI 后端的系统已经部署了这个功能，它能够很好地自动化校准一些 T1 的 IPv6 骨干网，帮我们节省了不少时间和精力。

关于 DN42 的 rDNS 解析的问题，因为考虑到很多玩家并不会和 T1 一样使用比较常见的方法标注自己的骨干网（事实上，如果把使用机场的 IATA 视为标准的话，很多 T1 的 rDNS 标注也不规范），所以我想在开发的时候提供一个 CSV 文件专用于存储自定义的 rDNS 信息。

当然我们会预先准备一些常见的 rDNS 数据硬编码于 NextTrace 中，如果 NT 可以找到用户自定义的 rDNS CSV 文件则优先使用 CSV 文件中的数据进行匹配，如果未能找到，再使用 NT 内置的常见 rDNS 数据表进行查询。

在做匹配的时候，最难的并不是匹配不上，而是匹配了错误的数据，也就是误匹配，我见过一些 DN42 玩家使用了奇怪的 PTR 记录来标注自己的 IP，比如 us-cnix.dn42，这种情况存在误将 cn 视为该跳地理位置的可能性，所以我想在匹配时多匹配一位，比如查看 cn 后面是否会是一个数字，或者是 "-", "." 特殊符号等等（即使用正则匹配）2，来减少误匹配的情况，具体详见Paper，下面为示意图，如图 1 所示。

吊，不愧是大佬。 DN42每个人都可以按照自己喜欢的命名方式来设置rDNS，而且没有任何标准，全靠机器识别，我觉得出错是免不了的。例如我用别人的bird的lg工具时候，发现反向的IP就容易识别错，那些自动标注IP和MAC地址的SSH终端也是，尤其是IPv6连续跟了两个冒号就错误了。

像我的IP，172.23.37.98，记录是pve.sub29.**98.37.23.172**.tyn1.cn.ip4.marionic.dn42，bird的lg却会匹配到29.98.37.23。 所以靠机器肯定做不到100%正确，还是需要人工维护数据库。v4就那点地址，维护起来还好。v6有rdns的也不多，没有的按照子网前缀（我喜欢每个/56分配一个地区，只有网关地址有PTR）识别归属地。 例如 fd21:129:81d2:100::1 的PTR是bgp-gw.sub56.0.0.1.0.tyn1.cn.ip6.marionic.dn42

归属地示例：中国 山西省 太原市 MARIONIC.DN42 | AS4242420351 （还需要做一个根据城市来确定省或州的功能；另外还要考虑到有人在PTR中已经标注了省或州，如LosAngeles1.ca.us.sun.dn42 (172.21.100.193)，CA很容易被识别成加拿大。人类可以一眼看明白，但是机器就会犯错了。

还识别不到的就以注册表中的country字段标注国家，这个是两位代码，不会错。

考虑到DN42还是小众，可以把相关的模块和数据库做成插件，与主程序分开打包，仓库也可以分开，这样需要的人自行装插件即可。 因为我不懂代码，所以也只能通过提issue做贡献啥的。可以设计成路由跟踪时自动反查DNS，然后先尝试本地匹配，并自动将收到的结果提交到数据库文件里（如果玩家愿意开启这个功能），然后由使用者来纠错。IP的注册者验证预留邮箱或者私钥签名后即可修改自己IP的归属地数据库。

[Diffused7245]

可以看到这些个肯定是靠机器识别的。 图一：运营商自己把多个区域用相同的IP地址，导致归属地显示错误。 图二：临近的IPv6段，有PTR的可以显示具体位置，其他的显示注册国家。如果真的是路由跟踪完一个一个人工判断的话，下面那几个IP也应该被标记位置，可是实际上没有，因此可以确定是机器识别的。

[sjlleo]

感谢您的回复！您说的很多的确是个问题，以下是我想的一些解决方案，想和您共同探讨一下~

吊，不愧是大佬。

您过奖了，我不是大佬233

DN42每个人都可以按照自己喜欢的命名方式来设置rDNS，而且没有任何标准，全靠机器识别，我觉得出错是免不了的。例如我用别人的bird的lg工具时候，发现反向的IP就容易识别错，那些自动标注IP和MAC地址的SSH终端也是，尤其是IPv6连续跟了两个冒号就错误了。

NT 在 DN42 模式目前设计的处理逻辑是这样的，它会先去拿到路由返回的 IP （并非从反查里面去提取），在 GeoFeed 中插在是否存在包含于这个段的最小段记录，如果找到了就不会再匹配 rDNS，直接输出。如果不存在 rDNS 就会继续匹配，对 IP 进行域名反查，尝试查找可能的国家、城市特征码，因为城市名必然是 [a-zA-Z] 的字符，所以前面纯数字的部分是不会干扰到的。

像我的IP，172.23.37.98，记录是pve.sub29.98.37.23.172.tyn1.cn.ip4.marionic.dn42，bird的lg却会匹配到29.98.37.23。 所以靠机器肯定做不到100%正确，还是需要人工维护数据库。v4就那点地址，维护起来还好。v6有rdns的也不多，没有的按照子网前缀（我喜欢每个/56分配一个地区，只有网关地址有PTR）识别归属地。

这种情况下可以手动添加 GeoFeed，比如

ip,asn,country,region,city
172.23.37.98/32,4242420351,Japan,Tokyo,Tokyo

这样整个段就会被定位在一个地方，而无需考虑再考虑 rDNS 匹配的事情

可以看到这些个肯定是靠机器识别的。 图一：运营商自己把多个区域用相同的IP地址，导致归属地显示错误。 图二：临近的IPv6段，有PTR的可以显示具体位置，其他的显示注册国家。如果真的是路由跟踪完一个一个人工判断的话，下面那几个IP也应该被标记位置，可是实际上没有，因此可以确定是机器识别的。

您说的是 Multi-Route 吧，像 Cogent 如果有这种情况会直接在 rDNS 标出，微软似乎不会，我不知道是不是 rDNS 解析的 PTR 记录也存在多个对应多个区域，BestTrace 基于 rDNS 自动校准是一个很不错的思路，现在我就在用这种思路来做自动化，但是他们会在获取 PTR 记录后把这些信息放在他们服务器的数据库中，您使用 BestTrace 跟踪时，反查其实是由 IPIP 的云端来完成，本地客户端不会进行 IP 反查。这部分数据因为不会经常性更新，所以 BestTrace 在抓取一次一行就缓存了，导致数据存在过时的情况。

有一种办法是基于历史 traceroute 数据（如用户或者监测节点的主动 traceroute 数据），把每次 traceroute 保存在数据库表中供查询，可以基本确定这个 IP 可能的地理位置，这个功能难度更大，我一直很想去做。

考虑到DN42还是小众，可以把相关的模块和数据库做成插件，与主程序分开打包，仓库也可以分开，这样需要的人自行装插件即可。

DN42 可以直接集成在里面，主要是考虑到并非只有 DN42 才会用到这些，一些用户试图使用 NT 作为企业内网的检测工具，这种情况下因为都是内网 IP，也需要用到这个功能。

谢谢！

[Diffused7245]

原来如此，又长知识了！

还说你不是大佬，Github里讲中文还用二次元头像的，基本全都是程序员大佬，搞得我这打酱油的一直不敢换萌妹子头像，啊哈哈！ 我也没打算让它从反向记录里寻找IP，那只是举个例子。我也路由跟踪很多次了，除了我的网内，基本上没看到还有人在反向记录里包含IP。而我的那段IP的反向DNS，还是例如pve.sub29.98.37.23.172.tyn1.cn.ip4.marionic.dn42之所以这么设计，就是想着以后肯定有人做归属地数据库，这样尽量遵守规范，也方便人工方便检索。V4还可以批量扫描，但是v6根本不可能扫，太多了，靠这样就可以方便别人结合后面的反向IP判断范围，知道网关就能得到其管理的整个子网范围了。

拿我那个v6地址fd21:129:81d2:100::1举例子，PTR是bgp-gw.sub56.0.0.1.0.tyn1.cn.ip6.marionic.dn42： 在这条记录中， bgp-gw是服务器名，这里代表边界网关。 sub56是代表CIDR/56网段内，属于<注册前缀>:0100::/56这段。如果是/128或者/32（v4）就不注明了。 后面是城市名+节点编号（太原市，1区，三位缩写来自武宿机场TYN，我这里的电信都是用的45.145.149.219.dial.ty.sx.dynamic.163data.com.cn这种拼音缩写格式。并不是东京哦，那个例子看起来很可行）、 ISO 3166两位的国家/地区名（中国cn）， 然后是IP版本v6、 网络名、 DN42 TLD。

另外说到ISO-3166规范，我还发现一个点，就是港澳台这种，它们都有自己的顶级域名，hk、mo、tw，但是按照我在那个ping的平台上看到的，有些人喜欢把香港标为CN，有的则喜欢用HK，这也可能引发识别错误。 香港和澳门这两个城市级别的小地方好说，台湾就有一个省那么大了，里面很多城市，如果有人标个台湾城市，后面跟着.cn，至少连人都不能立刻反应过来。例如有一回我看到个“中国桃园”就卡了半天才明白他在说哪，如果换成更加耳熟能详的“台湾桃园”就一看就懂了。

当然这里我不是故意提及那些不兴说的争议话题，在我看来，香港这三地方已经分配了专属的TLD，.HK，就用HK挺好，也方便和内陆城市区分，但是有人也给弄成CN，虽然能想明白他们为什么这么做，但偶尔就是会带来不方便。软件对于使用不规范的情况也要考虑到，免得机器也傻眼。

对于PTR查询，我觉得就是要靠软件跟踪的结果并且上报提交，靠人力搜索，至少对v6来说不现实。有些人就喜欢网关不是::1结尾，可能是::0，或者是什么FF:FE，如果不靠软件跟踪时发现那些节点，只靠人很难找，如果没有网络主人配合的话。

DN42 可以直接集成在里面，主要是考虑到并非只有 DN42 才会用到这些，一些用户试图使用 NT 作为企业内网的检测工具，这种情况下因为都是内网 IP，也需要用到这个功能。

这样也好，对于没有小数点部分的主机名，或者是内网TLD，比如.LAN、.HOME之类的来判断内网。

[tsosunchia]

原来如此，又长知识了！

还说你不是大佬，Github里讲中文还用二次元头像的，基本全都是程序员大佬，搞得我这打酱油的一直不敢换萌妹子头像，啊哈哈！

我也没打算让它从反向记录里寻找IP，那只是举个例子。我也路由跟踪很多次了，除了我的网内，基本上没看到还有人在反向记录里包含IP。而我的那段IP的反向DNS，还是例如pve.sub29.98.37.23.172.tyn1.cn.ip4.marionic.dn42之所以这么设计，就是想着以后肯定有人做归属地数据库，这样尽量遵守规范，也方便人工方便检索。V4还可以批量扫描，但是v6根本不可能扫，太多了，靠这样就可以方便别人结合后面的反向IP判断范围，知道网关就能得到其管理的整个子网范围了。

拿我那个v6地址fd21:129:81d2:100::1举例子，PTR是bgp-gw.sub56.0.0.1.0.tyn1.cn.ip6.marionic.dn42：

在这条记录中，

bgp-gw是服务器名，这里代表边界网关。

sub56是代表CIDR/56网段内，属于<注册前缀>:0100::/56这段。如果是/128或者/32（v4）就不注明了。

后面是城市名+节点编号（太原市，1区，三位缩写来自武宿机场TYN，我这里的电信都是用的45.145.149.219.dial.ty.sx.dynamic.163data.com.cn这种拼音缩写格式。并不是东京哦，那个例子看起来很可行）、

ISO 3166两位的国家/地区名（中国cn），

然后是IP版本v6、

网络名、

DN42 TLD。

另外说到ISO-3166规范，我还发现一个点，就是港澳台这种，它们都有自己的顶级域名，hk、mo、tw，但是按照我在那个ping的平台上看到的，有些人喜欢把香港标为CN，有的则喜欢用HK，这也可能引发识别错误。

香港和澳门这两个城市级别的小地方好说，台湾就有一个省那么大了，里面很多城市，如果有人标个台湾城市，后面跟着.cn，至少连人都不能立刻反应过来。例如有一回我看到个“中国桃园”就卡了半天才明白他在说哪，如果换成更加耳熟能详的“台湾桃园”就一看就懂了。

当然这里我不是故意提及那些不兴说的争议话题，在我看来，香港这三地方已经分配了专属的TLD，.HK，就用HK挺好，也方便和内陆城市区分，但是有人也给弄成CN，虽然能想明白他们为什么这么做，但偶尔就是会带来不方便。软件对于使用不规范的情况也要考虑到，免得机器也傻眼。

对于PTR查询，我觉得就是要靠软件跟踪的结果并且上报提交，靠人力搜索，至少对v6来说不现实。有些人就喜欢网关不是::1结尾，可能是::0，或者是什么FF:FE，如果不靠软件跟踪时发现那些节点，只靠人很难找，如果没有网络主人配合的话。

DN42 可以直接集成在里面，主要是考虑到并非只有 DN42 才会用到这些，一些用户试图使用 NT 作为企业内网的检测工具，这种情况下因为都是内网 IP，也需要用到这个功能。

这样也好，对于没有小数点部分的主机名，或者是内网TLD，比如.LAN、.HOME之类的来判断内网。

“当然这里我不是故意提及那些不兴说的争议话题，在我看来，香港这三地方已经分配了专属的TLD，.HK，就用HK挺好，也方便和内陆城市区分，但是有人也给弄成CN，虽然能想明白他们为什么这么做，但偶尔就是会带来不方便。软件对于使用不规范的情况也要考虑到，免得机器也傻眼。” 这是底线问题，我们会尽力优化，如显示为中国台湾省桃园市，但是绝对不会出现港澳台单列的情况。

[Diffused7245]

我看群里面已经有人用上了，不过我路由跟踪还是显示“局域网”，而且好像不会显示rdns。用的Windows版。 这个功能需要用什么命令开启吗？

另外还发现Enhanced版本里面，公网IP的归属地也可能会显示LAN的情况，发了个issue，不知道是不是检测到第一跳的rdns包含dn42，直接进入了这个模式？ https://github.com/OwO-Network/nexttrace-enhanced/issues/22

编辑：普通版，Windows平台也会出现上述错误。 NextTrace v1.0.9 2023-02-13T01:12:43Z 805e827

[sjlleo]

我看群里面已经有人用上了，不过我路由跟踪还是显示“局域网”，而且好像不会显示rdns。用的Windows版。

您看到的应该不是 NextTrace，NT 的 DN42 功能还没有发版，我们目前也没有开放给任何人测试。

另外还发现Enhanced版本里面，公网IP的归属地也可能会显示LAN的情况，发了个issue，不知道是不是检测到第一跳的rdns包含dn42，直接进入了这个模式？

服务端解析国内的 rDNS 解析速度慢（这不是我们的问题，通常是运营商托管 PTR 记录的服务器响应速度很慢或者故障），导致客户端超时从而出现 channel 拥塞，我们后续会在服务端解决这个问题。

[sjlleo]

另外，使用 DN42 功能需要更新 NextTrace 客户端才可以正常使用。此功能之所以开发缓慢，是因为 NT 有很多拥有公网 ASN 的 BGP Player，他们提出了很多宝贵的建议，我们人力有限，之前一直在忙于实现先前提出的众多功能特性，没办法 2 头都能兼顾。 我们的核心开发者只有 2 人，而 NT 只是我们的业余项目，日常我们需要为我们的生活而奔波，时间和精力都有限，请理解。

[sjlleo]

由于此功能已经完成，此贴讨论关闭，如有任何疑问欢迎在 Discussions 开启新的讨论，如果确认为 Bug，我们也同样会修复，除非您确定遇到的是 Bug，否则建议不要另开 issue。