OpsKitPro logo
OpsKitPro_
Back to blog
模块2026-04-217 min

IP and DNS modules: turning raw lookup data into readable conclusions

The IP page confirms location and access context, while the DNS page cross-checks multiple resolvers.

This is the organized version on the main site. Use the article list below if you want to keep exploring.
Browse articles
IP and DNS modules: turning raw lookup data into readable conclusions
About the article

This page is organized as a main-site article, keeping the key points and structure easy to read.

Article body

IP 页要先给“可用结论”

01

IP 页的重点不是输出一大堆字段,而是先回答三个问题:我是谁、我从哪里来、我现在是不是在代理后面。为了做到这一点,页面优先展示地理位置、ASN、ISP、代理线索和当前连接来源。

当外部查询不可用时,页面也不会直接崩掉,而是返回结构化的部分结果。用户依然能继续往下看,也能知道哪些信息来自 Cloudflare Context,哪些信息来自外部回退。

Reference filessrc/app/api/ip/route.tssrc/app/tools/ip-lookup/IPLookupClient.tsxsrc/app/api/ip/__tests__/route.test.ts

DNS 页要做交叉验证,而不是单点查询

02

DNS 工具最重要的不是“查得到”,而是“查得一致”。所以我给它接了多个 resolver,并且把本地联查和远端接口结果一起展示出来。这样用户就能一眼看出问题是出在解析本身,还是出在某个节点。

同时,A、AAAA、CNAME、MX、NS、TXT、CAA 都被纳入标准记录类型里,避免“DNS 查询”只剩一个粗糙的 A 记录结果。

Reference filessrc/app/api/dns/route.tssrc/app/tools/dns-lookup/DnsClient.tsxsrc/app/tools/dns-lookup/components/DnsBatchResult.tsx

统一输出格式,才能让 UI 真正变轻

03

之前这两个模块最容易出问题的地方,是字段名和展示层口径不完全一致。后来我把 API 契约抽成了共享 schema,前端和后端都基于同一份类型来理解“结果应该长什么样”。

这样一来,页面上复制按钮、JSON 区、状态标签、提示语就能统一收口,不需要每个页面自己猜字段,也不会再出现同一项在不同页上叫法不同的情况。

Reference filessrc/lib/api-contracts.tssrc/app/tools/dns-lookup/components/DnsResultTable.tsxsrc/app/tools/dns-lookup/components/DnsHistory.tsx