尧图网站建设 
OneUptime 域名监控Domain Monitor实战指南基于 RDAP/WHOIS 的域名到期与注册状态监控【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime域名是绝大多数在线业务的第一入口域名到期未续费导致的停服往往比服务器宕机更隐蔽、损失更大。OneUptime 提供的 Domain Monitor域名监控能够周期性地读取你域名的注册记录跟踪其健康状态并在到期前及时告警。本文以官方文档为主线结合 OneUptime 开源仓库中 Probe探针模块的完整实现系统讲解域名监控的创建流程、RDAP/WHOIS 查询机制、监控判定标准、配置参数与网络要求帮助你构建一套可落地的域名到期预警体系。一、Domain Monitor 是什么Domain Monitor 是 OneUptime 监控体系中的一种监控器类型。与 HTTP、Ping 等直接探测服务可用性的监控器不同它读取的是域名在注册局Registry中的注册记录registration record而不是解析或访问你的网站。OneUptime 的探针会周期性地向域名的权威数据源发起查询从而帮助你监控域名注册到期日期expiration date及时发现已过期或即将过期的域名追踪域名注册商registrar信息校验域名服务器nameserver配置是否正确监控域名状态码如 EPP 状态clientTransferProhibited。从实现上看该能力由探针Probe侧的核心模块驱动。OneUptime 将域名查询逻辑封装在 Probe/Utils/Monitors/MonitorTypes/DomainMonitor.ts 中每次检查会根据配置执行一次完整的注册记录查询并把结果在线/离线、响应时间、失败原因、注册信息快照等写回监控任务。二、创建域名监控在 OneUptime Dashboard 中创建域名监控的步骤如下进入 OneUptime Dashboard 的Monitors监控器页面点击Create Monitor创建监控器在监控器类型中选择Domain填写要监控的域名例如example.com选择查询方法Lookup Method默认保持Auto除非你有明确理由切换按需配置监控判定标准Monitoring Criteria决定域名在什么条件下被判定为在线Online、降级Degraded或离线Offline。其中查询方法决定了探针读取注册记录时走哪条协议它是域名监控最核心的配置项详见下一节。三、查询方法Lookup Methods深度解析域名的注册数据可以通过两种协议读取具体使用哪一种取决于该域名的顶级域TLD对哪种协议提供服务支持。三种方法的对比如下方法行为Auto默认选项。当该 TLD 在 IANA 发布有 RDAP 服务时使用 RDAP否则回退到 WHOIS。RDAP仅使用 RDAP。若该 TLD 未发布任何 RDAP 服务则直接报出明确错误。WHOIS仅使用 WHOIS。3.1 RDAPICANN 强制的 WHOIS 替代协议RDAPRegistration Data Access ProtocolRFC 9083是 ICANN 强制的 WHOIS 替代协议。它的关键优势在于服务发现机制每个 TLD 的权威 RDAP 服务器地址不是写死在客户端里的而是通过查询 IANA 的 bootstrap registryRFC 9224动态发现因此即使注册局迁移服务器客户端也能自动跟随最新地址。目前每个 gTLD通用顶级域都发布了 RDAP 服务。在 OneUptime 源码中这一机制由 Probe/Utils/Domain/RdapBootstrap.ts 实现探针从https://data.iana.org/rdap/dns.json拉取 IANA RDAP bootstrap 文档见IANA_RDAP_BOOTSTRAP_URL常量解析文档中的services数组按最长后缀匹配原则把域名映射到对应的 RDAP 服务 URLgetServiceUrlsForDomain会依次尝试a.b.example.com → b.example.com → example.com → com逐级匹配服务 URL 列表做了规范化优先使用 HTTPS并统一补全尾部/方便直接拼接domain/name请求路径bootstrap 文档一年只变化几次因此缓存 24 小时BOOTSTRAP_CACHE_TTL_IN_MS当拉取失败时探针会在 5 分钟内BOOTSTRAP_FAILURE_CACHE_TTL_IN_MS快速回退到 WHOIS同时保留旧的 registry 副本a stale registry still beats no registry网络恢复后自动重新启用 RDAP。拿到服务 URL 后Probe/Utils/Domain/RdapLookup.ts 会依次请求该 TLD 发布的每一个 RDAP 端点一个 TLD 可能列出多个镜像端点单个镜像宕机不会导致检查失败请求路径形如${baseUrl}domain/${encodeURIComponent(domainName)}。RDAP 服务器返回 HTTP 404 时探针将其解读为该域名未注册这一确定性答案DomainNotFoundError而不是继续尝试下一个镜像。3.2 WHOIS无发现机制的遗留协议及其坑WHOIS没有与 RDAP 等价的发现机制——客户端只能内置一份TLD → WHOIS 服务器主机的静态映射表而这些映射表会随注册局的迁移而过期。最典型的问题在于每个 Identity Digital 旗下的 TLD.digital、.email、.life、.today、.zone以及大约 290 个其他 TLD在大多数静态映射中仍指向已退役的主机whois.donuts.co这台主机现在对每次查询只会返回字面文本TLD is not supported.而不是注册记录。尽管如此WHOIS 依然是很多无 RDAP 服务的 ccTLD国家/地区顶级域的唯一选项例如.io、.co、.de、.ch、.jp等。OneUptime 的 WHOIS 实现位于 Probe/Utils/Domain/WhoisLookup.ts它有两个值得一提的工程细节字段别名映射whois-json库会把每行Key: value转成驼峰键但不同注册局的键名五花八门。源码中为每个字段维护了别名列表例如到期日期可能以registrarRegistrationExpirationDate、registryExpiryDate、expirationDate、paidTill、renewalDate、validUntil等十余种形式出现探针按最具体优先的顺序逐一尝试提取。跟随注册商跳转WHOIS 查询以follow: 2跟随注册局 → 注册商的引用链referral保证最终解析到的是信息最详尽的注册商记录而不是只有摘要的注册局记录。3.3 Auto 模式的完整决策链Auto 模式在探针中的执行逻辑见 DomainMonitor.ts 的lookupAuto为先尝试 RDAP失败后回退 WHOIS。其中有三个关键分支如果 RDAP 返回域名未注册DomainNotFoundError直接抛出该错误不再用 WHOIS 求第二意见——注册局自己的 RDAP 服务对域名是否存在拥有权威发言权再用 WHOIS 问一遍只会把明确答案变模糊如果该 TLD 没有发布 RDAP 服务bootstrap 返回空列表抛出不可重试的DomainLookupUnsupportedError并回退 WHOIS当 RDAP 与 WHOIS 都失败时探针会把两条协议各自的失败原因合并后抛出combineAutoFailures——WHOIS 没返回数据本身无法解释为什么没用 RDAP运维人员需要同时看到两个原因。若两条失败均为永久性则归类为DomainLookupUnsupportedError。需要强调的是RDAP 和 WHOIS 的尝试发生在同一次探测内lookupAuto因此不会把重试预算翻倍。3.4 失败时的判定语义如果一次查询无法产生注册数据——无论是因为该 TLD 的服务已退役还是因为域名根本没有注册——监控器会被报告为offline离线具体原因会显示在监控器的探针响应probe response上绝不会被当成健康的空到期日期处理。同理注册局明确回答该域名可注册例如 DENIC 的Status: free时会被判定为not registered未注册而不是健康记录。在源码中这一保证由 Probe/Utils/Domain/DomainRecord.ts 的hasRegistrationData与isNotRegisteredStatus实现free、available、notregistered、noobjectfound、nomatch、notfound、nonexistent等状态词都被视为此处没有注册而响应里连一个注册字段都没有如退役 WHOIS 主机返回的纯公告文本同样不被当作注册记录。3.5 国际化域名IDN支持国际化域名IDN两种写法都可以直接填入监控配置münchen.de会在查询前被自动转换为 A-labelASCII 形式xn--mnchen-3ya.de。这是因为注册局、IANA bootstrap registry 和 WHOIS 服务器都以 A-label 为键。该转换由 Probe/Utils/Domain/DomainName.ts 中的normalize方法基于 Node.js 的domainToASCII完成。该文件还负责清理用户输入——normalize会剥掉误粘贴进来的协议头https://、路径、查询串、片段、凭据和端口只留下可注册的主域名isValid则会校验标签长度每段 ≤63、总长 ≤253、至少两级、TLD 不能是全数字来拦截明显的配置错误例如输入一个 IP 地址或非法字符串。四、配置选项基本设置字段说明是否必填Domain Name要监控的域名例如example.com是Lookup MethodAuto、RDAP或WHOIS见上文查询方法是高级设置字段说明默认值Timeout (ms)单次注册查询的最大等待时间毫秒10000Retries首次尝试失败后的重试次数0 表示只尝试一次3这两项在源码中有明确的对应关系DomainMonitor.ts默认超时常量DEFAULT_DOMAIN_QUERY_TIMEOUT_IN_MS为 10000ms重试计数遵循首次尝试之后计数的语义配置 3 次重试意味着最多 4 次尝试配置 0 则单次尝试。若监控配置与调用方都未显式设置重试次数探针按 2 次兜底DEFAULT_RETRIES_WHEN_UNSET即最多 3 次尝试。重试策略的两个重要规则不可重试的失败直接上报那些重试也不会改变结果的失败——域名未注册、或你指定了 RDAP-only 但该 TLD 没有 RDAP 服务——会被立即报告而不是空等重试。这是因为重试只会以每次 1 秒的间隔Sleep.sleep(1000)把相同答案重复多遍。该分类由 Probe/Utils/Domain/DomainLookupError.ts 的isRetryable标记完成DomainNotFoundError与DomainLookupUnsupportedError均为永久性其余错误默认可重试。其余失败先重试包括 WHOIS 服务器有响应但不返回任何记录的情况被限流的注册商与已退役的注册商看起来一模一样只有重试耗尽后才能定性。超时同样被识别为可重试错误——isTimeout会匹配timeout、etimedout、econnaborted等多种底层异常名称。超时的作用范围timeout 作用于每一次查询。因此 Auto 检查在最坏情况下先试 RDAP 超时、再回退 WHOIS 又超时总耗时可达两倍 timeout。此外探针在重试失败后还会执行一次探针连通性检查OnlineCheck.canProbeMonitorWebsiteMonitors——但仅针对可能由探针自身网络导致的失败注册局已明确回答未注册的情况说明网络本身是通的不会因连通性门禁而丢弃这一真实结果。五、监控判定标准Monitoring Criteria你可以配置判定标准让监控器基于以下数据维度决定域名何时处于 online、degraded 或 offline 状态。可用过滤类型Filter Types过滤类型说明Is Online注册记录查询本身是否成功Is Request Timeout注册记录查询是否超时Domain Expires In Days距离域名注册到期还有多少天Domain Registrar域名注册商名称Domain Name Server域名的 nameserver 主机名Domain Status Code域名状态码EPP 状态名Domain Is Expired域名是否已过期两个重要的数据归一化行为由 DomainRecord.ts 与 RdapDomainParser.ts 落实状态码归一化为 EPP 名称无论哪个协议应答状态码都会统一为 EPP 名称形式如clientTransferProhibited。这是因为 RDAP 发布的是带空格的拼写形式client transfer prohibited而 WHOIS 直接给 EPP 名称并常附带 ICANN 状态 URL探针会剥掉 URL、把空格形式转成驼峰从而保证Auto 在 RDAP 与 WHOIS 之间切换时同一个判定标准依然持续生效。同时WHOIS 里一条被空格拼接的Domain Status:长串如clientDeleteProhibited ... clientTransferProhibited ...会被按 EPP URL 分隔符切分ccTLD 常见的拼写短语如paid and in zone则通过最长优先的短语表贪婪匹配还原。注册商名称不做归一化注册商名称是应答服务发布的原始内容两种协议之间可能有细微差异例如 RDAP 返回 jCard 中的fn/org字段WHOIS 返回registrar等键因此对Domain Registrar标准官方建议优先用Contains包含而非Equal To精确等于。日期归一化为 ISO 8601WHOIS 有十几种日期格式如YYYYMMDD、日在前带 4 位年份的16-11-2035RDAP 则发 RFC 3339。探针统一归一化为 ISO 8601无法解析的日期会被丢弃而不是存储——这样当注册局发布了无法解析的日期时到期判定标准会报告无法决定cannot decide而不会永远沉默地回答未过期。过滤条件Filter Conditions针对不同过滤类型可用的判定条件如下Is Online、Is Request Timeout、Domain Is Expired仅支持True/FalseDomain Expires In Days支持Greater Than大于、Less Than小于、Greater Than or Equal To大于等于、Less Than or Equal To小于等于Domain Registrar、Domain Name Server、Domain Status Code支持Contains包含指定文本Not Contains不包含指定文本Starts With以指定文本开头Ends With以指定文本结尾Equal To完全匹配Not Equal To不匹配值得一提的是探针返回的isTimeout字段永远是显式布尔值而非缺失值DomainMonitor.ts 中的注释说明了原因判定标准是对布尔值做比较一个undefined的isTimeout会让Is Request Timeout / False过滤条件无法判定进而在FilterCondition.All语义下卡住监控器永远无法恢复在线。配置示例域名 30 天内到期即告警Filter TypeDomain Expires In DaysFilter ConditionLess ThanValue30域名已过期则标记为离线Filter TypeDomain Is ExpiredFilter ConditionTrue注册记录读取失败则标记为离线Filter TypeIs OnlineFilter ConditionFalse校验 nameserver 配置正确Filter TypeDomain Name ServerFilter ConditionContainsValuens1.example.com这些判定最终作用于探针返回的结构化响应DomainMonitorResponse定义于 Common/Types/Monitor/DomainMonitor/DomainMonitorResponse.ts其中包含域名、注册商、注册商 URL、创建/更新/到期日期、nameserver 列表、DNSSEC 状态、域名状态码、响应时间、失败原因以及每次探测尝试probe attempts的记录。六、最佳实践官方文档给出了四条经过实战检验的配置建议设置提前告警——在到期前60 天配置降级degraded告警在到期前14 天配置离线offline告警。域名续费通常有宽限期但越早提醒越从容。覆盖查询失败场景——在离线判定标准中加上Is Online / False过滤条件确保注册记录读不出来不会被误判为健康记录。从本文档所述版本起新建的监控器默认自带该条件更早创建的监控器需要手动补充。监控所有关键域名——不仅包括主域名还包括单独注册的子域、以及用于邮件收发或 API 服务的域名。跟踪注册商变更——监控 registrar 字段以发现未经授权的域名转移unauthorized transfer。七、网络要求域名监控由 OneUptime 的探针Probe执行因此探针所在主机需要具备以下出站网络能力可访问https://data.iana.org/rdap/dns.json——IANA RDAP bootstrap registry获取后缓存 24 小时可访问各注册局的RDAP端点HTTPS443 端口可访问WHOIS服务器TCP 43 端口。代理行为差异值得注意RDAP 请求遵守探针的HTTP_PROXY_URL/HTTPS_PROXY_URL/NO_PROXY设置WHOIS 走裸 socketraw socket不经过这些代理设置。另外如果探针无法访问data.iana.orgAuto 模式会降级为 WHOIS并周期性重试拉取 bootstrap registry失败缓存 5 分钟BOOTSTRAP_FETCH_TIMEOUT_IN_MS为 15 秒且该拉取由所有域名监控共享、不会继承单个监控器较短的超时配置网络恢复后自动切回 RDAP。八、源码与测试验证以上行为均可在一整套单元测试中得到验证若你想深入阅读或自行验证Probe/Tests/Utils/Monitors/MonitorTypes/DomainMonitor.test.ts 覆盖了 Auto 模式的核心场景其中包括 issue #3046 的回归用例whois.donuts.co对.digital返回的TLD is not supported.应答只有数据库时间戳和 terms-of-use 文本没有任何注册字段会被正确识别为无注册数据监控器报告失败而非健康Probe/Tests/Utils/Domain/RdapLookup.test.ts 与 Probe/Tests/Utils/Domain/RdapDomainParser.test.ts 验证 RDAP 的 bootstrap 发现、多端点回退以及 RFC 9083 domain 对象到扁平记录的解析Probe/Tests/Utils/Domain/WhoisLookup.test.ts 与 Probe/Tests/Utils/Domain/DomainRecord.test.ts 验证 WHOIS 字段别名提取、EPP 状态码归一化与日期解析。底层类型定义位于 Common/Types/Monitor/DomainMonitor/DomainLookupMethod.tsAuto/RDAP/WHOIS 枚举与 Common/Types/Monitor/MonitorStepDomainMonitor.ts监控步骤配置结构可以作为理解整条数据链路的起点。小结OneUptime 的 Domain Monitor 通过RDAP 优先、WHOIS 兜底的 Auto 机制兼顾了 gTLD 的现代协议优势与 ccTLD 的存量现实配套的字段归一化、确定性失败判定与重试分类让域名到期告警既可靠又不会误报。按本文的配置步骤创建监控器配合 60 天/14 天的分层预警、Is Online / False 兜底条件和注册商变更跟踪即可把域名静默过期从业务事故清单中彻底移除。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OneUptime 域名监控（Domain Monitor）实战指南：基于 RDAP/WHOIS 的域名到期与注册状态监控
OneUptime 域名监控Domain Monitor实战指南基于 RDAP/WHOIS 的域名到期与注册状态监控【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime域名是绝大多数在线业务的第一入口域名到期未续费导致的停服往往比服务器宕机更隐蔽、损失更大。OneUptime 提供的 Domain Monitor域名监控能够周期性地读取你域名的注册记录跟踪其健康状态并在到期前及时告警。本文以官方文档为主线结合 OneUptime 开源仓库中 Probe探针模块的完整实现系统讲解域名监控的创建流程、RDAP/WHOIS 查询机制、监控判定标准、配置参数与网络要求帮助你构建一套可落地的域名到期预警体系。一、Domain Monitor 是什么Domain Monitor 是 OneUptime 监控体系中的一种监控器类型。与 HTTP、Ping 等直接探测服务可用性的监控器不同它读取的是域名在注册局Registry中的注册记录registration record而不是解析或访问你的网站。OneUptime 的探针会周期性地向域名的权威数据源发起查询从而帮助你监控域名注册到期日期expiration date及时发现已过期或即将过期的域名追踪域名注册商registrar信息校验域名服务器nameserver配置是否正确监控域名状态码如 EPP 状态clientTransferProhibited。从实现上看该能力由探针Probe侧的核心模块驱动。OneUptime 将域名查询逻辑封装在 Probe/Utils/Monitors/MonitorTypes/DomainMonitor.ts 中每次检查会根据配置执行一次完整的注册记录查询并把结果在线/离线、响应时间、失败原因、注册信息快照等写回监控任务。二、创建域名监控在 OneUptime Dashboard 中创建域名监控的步骤如下进入 OneUptime Dashboard 的Monitors监控器页面点击Create Monitor创建监控器在监控器类型中选择Domain填写要监控的域名例如example.com选择查询方法Lookup Method默认保持Auto除非你有明确理由切换按需配置监控判定标准Monitoring Criteria决定域名在什么条件下被判定为在线Online、降级Degraded或离线Offline。其中查询方法决定了探针读取注册记录时走哪条协议它是域名监控最核心的配置项详见下一节。三、查询方法Lookup Methods深度解析域名的注册数据可以通过两种协议读取具体使用哪一种取决于该域名的顶级域TLD对哪种协议提供服务支持。三种方法的对比如下方法行为Auto默认选项。当该 TLD 在 IANA 发布有 RDAP 服务时使用 RDAP否则回退到 WHOIS。RDAP仅使用 RDAP。若该 TLD 未发布任何 RDAP 服务则直接报出明确错误。WHOIS仅使用 WHOIS。3.1 RDAPICANN 强制的 WHOIS 替代协议RDAPRegistration Data Access ProtocolRFC 9083是 ICANN 强制的 WHOIS 替代协议。它的关键优势在于服务发现机制每个 TLD 的权威 RDAP 服务器地址不是写死在客户端里的而是通过查询 IANA 的 bootstrap registryRFC 9224动态发现因此即使注册局迁移服务器客户端也能自动跟随最新地址。目前每个 gTLD通用顶级域都发布了 RDAP 服务。在 OneUptime 源码中这一机制由 Probe/Utils/Domain/RdapBootstrap.ts 实现探针从https://data.iana.org/rdap/dns.json拉取 IANA RDAP bootstrap 文档见IANA_RDAP_BOOTSTRAP_URL常量解析文档中的services数组按最长后缀匹配原则把域名映射到对应的 RDAP 服务 URLgetServiceUrlsForDomain会依次尝试a.b.example.com → b.example.com → example.com → com逐级匹配服务 URL 列表做了规范化优先使用 HTTPS并统一补全尾部/方便直接拼接domain/name请求路径bootstrap 文档一年只变化几次因此缓存 24 小时BOOTSTRAP_CACHE_TTL_IN_MS当拉取失败时探针会在 5 分钟内BOOTSTRAP_FAILURE_CACHE_TTL_IN_MS快速回退到 WHOIS同时保留旧的 registry 副本a stale registry still beats no registry网络恢复后自动重新启用 RDAP。拿到服务 URL 后Probe/Utils/Domain/RdapLookup.ts 会依次请求该 TLD 发布的每一个 RDAP 端点一个 TLD 可能列出多个镜像端点单个镜像宕机不会导致检查失败请求路径形如${baseUrl}domain/${encodeURIComponent(domainName)}。RDAP 服务器返回 HTTP 404 时探针将其解读为该域名未注册这一确定性答案DomainNotFoundError而不是继续尝试下一个镜像。3.2 WHOIS无发现机制的遗留协议及其坑WHOIS没有与 RDAP 等价的发现机制——客户端只能内置一份TLD → WHOIS 服务器主机的静态映射表而这些映射表会随注册局的迁移而过期。最典型的问题在于每个 Identity Digital 旗下的 TLD.digital、.email、.life、.today、.zone以及大约 290 个其他 TLD在大多数静态映射中仍指向已退役的主机whois.donuts.co这台主机现在对每次查询只会返回字面文本TLD is not supported.而不是注册记录。尽管如此WHOIS 依然是很多无 RDAP 服务的 ccTLD国家/地区顶级域的唯一选项例如.io、.co、.de、.ch、.jp等。OneUptime 的 WHOIS 实现位于 Probe/Utils/Domain/WhoisLookup.ts它有两个值得一提的工程细节字段别名映射whois-json库会把每行Key: value转成驼峰键但不同注册局的键名五花八门。源码中为每个字段维护了别名列表例如到期日期可能以registrarRegistrationExpirationDate、registryExpiryDate、expirationDate、paidTill、renewalDate、validUntil等十余种形式出现探针按最具体优先的顺序逐一尝试提取。跟随注册商跳转WHOIS 查询以follow: 2跟随注册局 → 注册商的引用链referral保证最终解析到的是信息最详尽的注册商记录而不是只有摘要的注册局记录。3.3 Auto 模式的完整决策链Auto 模式在探针中的执行逻辑见 DomainMonitor.ts 的lookupAuto为先尝试 RDAP失败后回退 WHOIS。其中有三个关键分支如果 RDAP 返回域名未注册DomainNotFoundError直接抛出该错误不再用 WHOIS 求第二意见——注册局自己的 RDAP 服务对域名是否存在拥有权威发言权再用 WHOIS 问一遍只会把明确答案变模糊如果该 TLD 没有发布 RDAP 服务bootstrap 返回空列表抛出不可重试的DomainLookupUnsupportedError并回退 WHOIS当 RDAP 与 WHOIS 都失败时探针会把两条协议各自的失败原因合并后抛出combineAutoFailures——WHOIS 没返回数据本身无法解释为什么没用 RDAP运维人员需要同时看到两个原因。若两条失败均为永久性则归类为DomainLookupUnsupportedError。需要强调的是RDAP 和 WHOIS 的尝试发生在同一次探测内lookupAuto因此不会把重试预算翻倍。3.4 失败时的判定语义如果一次查询无法产生注册数据——无论是因为该 TLD 的服务已退役还是因为域名根本没有注册——监控器会被报告为offline离线具体原因会显示在监控器的探针响应probe response上绝不会被当成健康的空到期日期处理。同理注册局明确回答该域名可注册例如 DENIC 的Status: free时会被判定为not registered未注册而不是健康记录。在源码中这一保证由 Probe/Utils/Domain/DomainRecord.ts 的hasRegistrationData与isNotRegisteredStatus实现free、available、notregistered、noobjectfound、nomatch、notfound、nonexistent等状态词都被视为此处没有注册而响应里连一个注册字段都没有如退役 WHOIS 主机返回的纯公告文本同样不被当作注册记录。3.5 国际化域名IDN支持国际化域名IDN两种写法都可以直接填入监控配置münchen.de会在查询前被自动转换为 A-labelASCII 形式xn--mnchen-3ya.de。这是因为注册局、IANA bootstrap registry 和 WHOIS 服务器都以 A-label 为键。该转换由 Probe/Utils/Domain/DomainName.ts 中的normalize方法基于 Node.js 的domainToASCII完成。该文件还负责清理用户输入——normalize会剥掉误粘贴进来的协议头https://、路径、查询串、片段、凭据和端口只留下可注册的主域名isValid则会校验标签长度每段 ≤63、总长 ≤253、至少两级、TLD 不能是全数字来拦截明显的配置错误例如输入一个 IP 地址或非法字符串。四、配置选项基本设置字段说明是否必填Domain Name要监控的域名例如example.com是Lookup MethodAuto、RDAP或WHOIS见上文查询方法是高级设置字段说明默认值Timeout (ms)单次注册查询的最大等待时间毫秒10000Retries首次尝试失败后的重试次数0 表示只尝试一次3这两项在源码中有明确的对应关系DomainMonitor.ts默认超时常量DEFAULT_DOMAIN_QUERY_TIMEOUT_IN_MS为 10000ms重试计数遵循首次尝试之后计数的语义配置 3 次重试意味着最多 4 次尝试配置 0 则单次尝试。若监控配置与调用方都未显式设置重试次数探针按 2 次兜底DEFAULT_RETRIES_WHEN_UNSET即最多 3 次尝试。重试策略的两个重要规则不可重试的失败直接上报那些重试也不会改变结果的失败——域名未注册、或你指定了 RDAP-only 但该 TLD 没有 RDAP 服务——会被立即报告而不是空等重试。这是因为重试只会以每次 1 秒的间隔Sleep.sleep(1000)把相同答案重复多遍。该分类由 Probe/Utils/Domain/DomainLookupError.ts 的isRetryable标记完成DomainNotFoundError与DomainLookupUnsupportedError均为永久性其余错误默认可重试。其余失败先重试包括 WHOIS 服务器有响应但不返回任何记录的情况被限流的注册商与已退役的注册商看起来一模一样只有重试耗尽后才能定性。超时同样被识别为可重试错误——isTimeout会匹配timeout、etimedout、econnaborted等多种底层异常名称。超时的作用范围timeout 作用于每一次查询。因此 Auto 检查在最坏情况下先试 RDAP 超时、再回退 WHOIS 又超时总耗时可达两倍 timeout。此外探针在重试失败后还会执行一次探针连通性检查OnlineCheck.canProbeMonitorWebsiteMonitors——但仅针对可能由探针自身网络导致的失败注册局已明确回答未注册的情况说明网络本身是通的不会因连通性门禁而丢弃这一真实结果。五、监控判定标准Monitoring Criteria你可以配置判定标准让监控器基于以下数据维度决定域名何时处于 online、degraded 或 offline 状态。可用过滤类型Filter Types过滤类型说明Is Online注册记录查询本身是否成功Is Request Timeout注册记录查询是否超时Domain Expires In Days距离域名注册到期还有多少天Domain Registrar域名注册商名称Domain Name Server域名的 nameserver 主机名Domain Status Code域名状态码EPP 状态名Domain Is Expired域名是否已过期两个重要的数据归一化行为由 DomainRecord.ts 与 RdapDomainParser.ts 落实状态码归一化为 EPP 名称无论哪个协议应答状态码都会统一为 EPP 名称形式如clientTransferProhibited。这是因为 RDAP 发布的是带空格的拼写形式client transfer prohibited而 WHOIS 直接给 EPP 名称并常附带 ICANN 状态 URL探针会剥掉 URL、把空格形式转成驼峰从而保证Auto 在 RDAP 与 WHOIS 之间切换时同一个判定标准依然持续生效。同时WHOIS 里一条被空格拼接的Domain Status:长串如clientDeleteProhibited ... clientTransferProhibited ...会被按 EPP URL 分隔符切分ccTLD 常见的拼写短语如paid and in zone则通过最长优先的短语表贪婪匹配还原。注册商名称不做归一化注册商名称是应答服务发布的原始内容两种协议之间可能有细微差异例如 RDAP 返回 jCard 中的fn/org字段WHOIS 返回registrar等键因此对Domain Registrar标准官方建议优先用Contains包含而非Equal To精确等于。日期归一化为 ISO 8601WHOIS 有十几种日期格式如YYYYMMDD、日在前带 4 位年份的16-11-2035RDAP 则发 RFC 3339。探针统一归一化为 ISO 8601无法解析的日期会被丢弃而不是存储——这样当注册局发布了无法解析的日期时到期判定标准会报告无法决定cannot decide而不会永远沉默地回答未过期。过滤条件Filter Conditions针对不同过滤类型可用的判定条件如下Is Online、Is Request Timeout、Domain Is Expired仅支持True/FalseDomain Expires In Days支持Greater Than大于、Less Than小于、Greater Than or Equal To大于等于、Less Than or Equal To小于等于Domain Registrar、Domain Name Server、Domain Status Code支持Contains包含指定文本Not Contains不包含指定文本Starts With以指定文本开头Ends With以指定文本结尾Equal To完全匹配Not Equal To不匹配值得一提的是探针返回的isTimeout字段永远是显式布尔值而非缺失值DomainMonitor.ts 中的注释说明了原因判定标准是对布尔值做比较一个undefined的isTimeout会让Is Request Timeout / False过滤条件无法判定进而在FilterCondition.All语义下卡住监控器永远无法恢复在线。配置示例域名 30 天内到期即告警Filter TypeDomain Expires In DaysFilter ConditionLess ThanValue30域名已过期则标记为离线Filter TypeDomain Is ExpiredFilter ConditionTrue注册记录读取失败则标记为离线Filter TypeIs OnlineFilter ConditionFalse校验 nameserver 配置正确Filter TypeDomain Name ServerFilter ConditionContainsValuens1.example.com这些判定最终作用于探针返回的结构化响应DomainMonitorResponse定义于 Common/Types/Monitor/DomainMonitor/DomainMonitorResponse.ts其中包含域名、注册商、注册商 URL、创建/更新/到期日期、nameserver 列表、DNSSEC 状态、域名状态码、响应时间、失败原因以及每次探测尝试probe attempts的记录。六、最佳实践官方文档给出了四条经过实战检验的配置建议设置提前告警——在到期前60 天配置降级degraded告警在到期前14 天配置离线offline告警。域名续费通常有宽限期但越早提醒越从容。覆盖查询失败场景——在离线判定标准中加上Is Online / False过滤条件确保注册记录读不出来不会被误判为健康记录。从本文档所述版本起新建的监控器默认自带该条件更早创建的监控器需要手动补充。监控所有关键域名——不仅包括主域名还包括单独注册的子域、以及用于邮件收发或 API 服务的域名。跟踪注册商变更——监控 registrar 字段以发现未经授权的域名转移unauthorized transfer。七、网络要求域名监控由 OneUptime 的探针Probe执行因此探针所在主机需要具备以下出站网络能力可访问https://data.iana.org/rdap/dns.json——IANA RDAP bootstrap registry获取后缓存 24 小时可访问各注册局的RDAP端点HTTPS443 端口可访问WHOIS服务器TCP 43 端口。代理行为差异值得注意RDAP 请求遵守探针的HTTP_PROXY_URL/HTTPS_PROXY_URL/NO_PROXY设置WHOIS 走裸 socketraw socket不经过这些代理设置。另外如果探针无法访问data.iana.orgAuto 模式会降级为 WHOIS并周期性重试拉取 bootstrap registry失败缓存 5 分钟BOOTSTRAP_FETCH_TIMEOUT_IN_MS为 15 秒且该拉取由所有域名监控共享、不会继承单个监控器较短的超时配置网络恢复后自动切回 RDAP。八、源码与测试验证以上行为均可在一整套单元测试中得到验证若你想深入阅读或自行验证Probe/Tests/Utils/Monitors/MonitorTypes/DomainMonitor.test.ts 覆盖了 Auto 模式的核心场景其中包括 issue #3046 的回归用例whois.donuts.co对.digital返回的TLD is not supported.应答只有数据库时间戳和 terms-of-use 文本没有任何注册字段会被正确识别为无注册数据监控器报告失败而非健康Probe/Tests/Utils/Domain/RdapLookup.test.ts 与 Probe/Tests/Utils/Domain/RdapDomainParser.test.ts 验证 RDAP 的 bootstrap 发现、多端点回退以及 RFC 9083 domain 对象到扁平记录的解析Probe/Tests/Utils/Domain/WhoisLookup.test.ts 与 Probe/Tests/Utils/Domain/DomainRecord.test.ts 验证 WHOIS 字段别名提取、EPP 状态码归一化与日期解析。底层类型定义位于 Common/Types/Monitor/DomainMonitor/DomainLookupMethod.tsAuto/RDAP/WHOIS 枚举与 Common/Types/Monitor/MonitorStepDomainMonitor.ts监控步骤配置结构可以作为理解整条数据链路的起点。小结OneUptime 的 Domain Monitor 通过RDAP 优先、WHOIS 兜底的 Auto 机制兼顾了 gTLD 的现代协议优势与 ccTLD 的存量现实配套的字段归一化、确定性失败判定与重试分类让域名到期告警既可靠又不会误报。按本文的配置步骤创建监控器配合 60 天/14 天的分层预警、Is Online / False 兜底条件和注册商变更跟踪即可把域名静默过期从业务事故清单中彻底移除。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考