当前位置：首页 > news >正文

intodns：终端里的DNS与邮件安全自动化审计工具

news 2026/4/28 8:13:43

1. 项目概述：一个终端里的DNS与邮件安全“体检中心”

如果你负责过线上服务的运维，或者自己折腾过个人网站，大概率都经历过域名解析出问题、邮件发不出去或者被当成垃圾邮件的糟心时刻。排查这些问题，往往需要在不同的在线工具之间来回切换，查DNS记录、验证DNSSEC、检查SPF/DKIM配置……过程繁琐，信息分散。今天要聊的这个工具，intodns，就是来解决这个痛点的。它本质上是一个命令行工具，或者说是一个“技能”（Skill），让你能在终端里，用一条命令，完成对一个域名从DNS基础记录到邮件安全协议，再到IP信誉的全面“体检”，并在3秒内给你一份带评分的详细报告。

这个项目最初是作为一个Claude应用（在ClawHub或MoltBot这类平台上）的技能出现的，但其核心价值让它迅速衍生出了独立的NPM CLI工具、GitHub Action，甚至提供了完整的公开API。它的目标很明确：将复杂的域名安全审计平民化、自动化、集成化。无论你是一个想检查自己博客配置的开发者，还是一个需要为数十个企业域名做定期巡检的运维工程师，intodns都能让你把这件事变得像ping一个域名一样简单。

它的核心功能覆盖了五大块：DNS记录（A， AAAA， MX等）、DNSSEC（域名系统安全扩展）、邮件安全（SPF， DKIM， DMARC， MTA-STS， BIMI）、IPv6就绪状态以及安全最佳实践与黑名单检查。最终它会给出一个从A+到F的评分等级，并明确指出哪里配置错了，更关键的是，它通常会提供可以直接复制粘贴的修复建议。

2. 核心功能与检查项深度解析

intodns的检查不是简单的“有”或“无”，而是基于一系列行业最佳实践和RFC标准进行的深度分析。理解它检查什么以及为什么检查这些，能帮助我们在日常运维中建立更完善的安全意识。

2.1 DNS记录健康度（权重20%）

这是域名正常工作的基石。intodns会系统性地检查以下记录：

A/AAAA记录：确保你的域名有正确的IPv4和IPv6地址指向。对于Web服务，它会检查是否同时配置了www子域名和根域名的记录，避免常见的“www站点无法访问”问题。
MX记录：邮件交换记录，定义了接收邮件的服务器。它会检查记录是否存在、是否有效，以及优先级设置是否合理。一个常见的坑是MX记录指向了一个没有运行邮件服务软件的服务器IP。
NS记录：权威域名服务器记录。它会验证你设置的NS记录是否在全球范围内都能被正确解析，并且这些NS服务器本身是否工作正常。NS记录设置错误是导致域名“完全失联”的元凶之一。
SOA记录：起始授权机构记录，包含域名的核心管理信息（主NS、管理员邮箱、序列号、刷新间隔等）。intodns会检查序列号格式、刷新/重试/过期时间设置是否符合常规，避免因SOA配置不当引发的区域传输问题。
CAA记录：证书颁发机构授权记录。这是一个重要的安全记录，它指定了哪些CA（证书颁发机构）可以为该域名签发SSL证书。没有CAA记录，任何CA都可以为你签发证书，存在潜在风险。intodns会检查你是否设置了CAA记录来限制证书签发。
CNAME记录：别名记录。它会检查CNAME指向的目标是否有效，并特别注意CNAME与其他记录（如MX、NS）冲突的情况（根据RFC标准，CNAME记录不能与其他任何记录共存于同一主机名）。

注意：DNS记录的检查不仅仅是存在性检查。例如，对于A记录，它可能还会检查是否指向了保留地址（如127.0.0.1）或广播地址；对于MX记录，会检查是否指向了CNAME（这是不符合RFC标准的）。

2.2 DNSSEC验证（权重15%）

DNSSEC通过为DNS数据添加数字签名，防止缓存投毒和DNS欺骗攻击。intodns的检查非常彻底：

DS记录链验证：从根域（.）开始，沿着域名层级（如 .com -> example.com -> www.example.com）逐级验证DS（Delegation Signer）记录是否完整且正确。任何一级的DS记录缺失或错误都会导致验证链断裂。
RRSIG签名验证：检查域名各资源记录集（如A记录集、MX记录集）的RRSIG（资源记录签名）记录是否存在，并且签名是否有效、是否在有效期内。过期的签名是DNSSEC失效的常见原因。
算法检查：验证使用的签名算法（如RSASHA256， ECDSAP256SHA256）是否是当前推荐的安全算法，避免使用已被认为脆弱或不安全的旧算法（如RSASHA1）。

实操心得：很多域名注册商或DNS服务商虽然提供了DNSSEC“一键开启”，但后续如果更换了DNS服务商或私钥滚动（Key Rollover）操作不当，很容易导致DNSSEC验证失败，使域名无法解析。定期用intodns检查是预防此类“静默故障”的好习惯。

2.3 邮件安全协议套件检查（权重30%）

这是intodns的重头戏，也是邮件能否顺利送达、不被标记为垃圾邮件的关键。它检查的是一个完整的现代邮件安全生态。

SPF（发件人策略框架）：intodns会严格遵循RFC 7208。
- 记录解析：检查SPF记录的语法是否正确，是否存在重复的spf1版本标识等低级错误。
- DNS查询次数：这是SPF的一个硬性限制。一个SPF记录在评估过程中，其包含的include、a、mx等机制触发的DNS查询总数不能超过10次。超过此限制，接收方邮件服务器可能会直接拒绝该SPF记录。intodns会模拟评估过程，精确计算查询次数。
- 机制有效性：检查ip4、ip6、include、a、mx等机制指向的目标是否可解析、有效。
DKIM（域名密钥识别邮件）：DKIM的难点在于“发现”，因为选择器（selector）是自定义的。
- 选择器发现：intodns内置了20多个常见的选择器名称（如default，google，selector1，k1，dkim等），会主动查询像selector1._domainkey.yourdomain.com这样的TXT记录，尝试发现已配置的DKIM公钥。
- 记录格式验证：检查发现的DKIM记录格式是否符合RFC标准，公钥（p=）字段是否完整。
DMARC（基于域的消息认证、报告和一致性）：
- 策略分析：检查_dmarc.yourdomain.com的TXT记录，解析策略（p=：none， quarantine， reject）、报告URI（rua=）等。
- 对齐检查：这是DMARC发挥作用的核心。它会检查“Header From”域名与SPF的认证域名（SPF alignment）以及DKIM签名域名（DKIM alignment）是否对齐。只有对齐了，DMARC才能判定一封邮件是否通过认证。
MTA-STS（邮件传输代理严格传输安全）：
- 策略文件获取：检查是否存在_mta-sts.yourdomain.com的TXT记录，其内容是否包含有效的_mta-sts策略ID。
- HTTPS策略服务：根据TXT记录的ID，尝试通过HTTPS获取https://mta-sts.yourdomain.com/.well-known/mta-sts.txt策略文件，验证其内容格式和mx指令是否有效。这确保了邮件在传输层（TLS）是加密的。
BIMI（品牌标识信息识别）：
- 记录验证：检查default._bimi.yourdomain.com的TXT记录，验证其指向的徽标URL。
- 徽标文件验证：获取徽标文件（通常为SVG），并验证其是否符合BIMI要求的SVG Tiny 1.2 Portable/Secure子集规范。这是一个较新的标准，用于在支持它的邮件客户端显示品牌徽标，提升可信度。

2.4 IPv6就绪状态（权重15%）

随着IPv4地址耗尽，IPv6支持越来越重要。intodns会检查：

AAAA记录：你的域名（以及常见的www子域名）是否配置了IPv6地址。
双栈就绪：评估你的服务是否做好了同时服务IPv4和IPv6用户（即“双栈”）的准备。仅有AAAA记录但对应服务器未开启IPv6监听，会导致IPv6用户无法访问。

2.5 安全与黑名单检查（权重20%）

这部分检查域名的“声誉”和配置安全性：

IP黑名单检查：工具会将被域名A记录解析到的IP地址，提交到6个以上的公共DNSBL（DNS黑名单）或邮件黑名单中进行查询，例如Spamhaus， SURBL等。如果你的服务器IP因为历史发送垃圾邮件或其他滥用行为被列入黑名单，会严重影响邮件送达率。
最佳实践：包括检查是否启用了防止域名滥用的安全扩展，如是否缺少CAA记录（前文已提），SOA记录中的管理员邮箱是否是泛用的hostmaster@domain.com格式（避免使用个人邮箱，减少信息暴露和垃圾邮件）等。

3. 多种使用方式与实战操作指南

intodns最大的优势就是灵活，你可以把它集成到工作流的任何环节。

3.1 作为Claude应用技能使用（原始场景）

在支持ClawHub或OpenClaw这类平台的Claude应用中，你可以直接通过自然语言触发扫描。

用户：/intodns myproject.com Claude（集成intodns技能）：正在为 myproject.com 运行全面DNS安全扫描... （约3秒后） Claude：扫描完成！评分：B (85/100)。主要问题：缺少DMARC记录，且SPF记录包含的DNS查询次数过多（12次，超过10次限制）。建议...

这种交互方式非常适合在聊天环境中快速诊断问题，无需离开当前上下文。

3.2 作为NPM CLI命令行工具（最通用）

对于开发者或运维人员，这是最直接的方式。

安装与基础使用：

# 全局安装 npm install -g intodns # 或直接使用npx（无需安装） npx intodns example.com

运行后，终端会输出一个格式清晰的彩色表格报告，一目了然。

进阶用法：

# 输出JSON格式，便于集成到其他脚本或自动化工具中 npx intodns example.com --json # 设置最低合格分数线，如果评分低于80分，则命令以非零状态码退出，可用于CI/CD流水线中的强制检查 npx intodns example.com --fail-below 80 # 结合jq工具进行更精细的JSON结果过滤 npx intodns example.com --json | jq '.categories[] | select(.score < 100)'

3.3 集成到GitHub Actions（自动化巡检）

对于托管在GitHub上的项目，你可以将域名安全检查作为CI/CD流水线的一环，确保每次部署或定期检查时，域名配置都是健康的。

# .github/workflows/dns-check.yml name: DNS Security Audit on: schedule: - cron: '0 9 * * 1' # 每周一早上9点运行 push: branches: [ main ] workflow_dispatch: # 允许手动触发 jobs: dns-audit: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 - name: Run DNS Security Scan uses: RoscoNL/dns-security-scanner/github-action@main # 使用官方Action with: domain: 'your-production-domain.com' fail-below: 85 # 如果分数低于85分，则此步骤失败 # json-output: 'report.json' # 可选：输出JSON报告 - name: Upload Report (Optional) if: always() # 即使扫描失败也上传报告 uses: actions/upload-artifact@v4 with: name: dns-scan-report path: report.json # 对应上一步生成的报告

这样，任何导致评分下降的配置变更（如误删了SPF记录），都会在合并到主分支或定期检查时立即暴露出来。

3.4 调用公开API（构建自定义工具）

intodns提供了无需认证、无需密钥的公开API，非常适合集成到内部监控面板、运维仪表盘或自定义脚本中。

基础扫描API：

curl "https://intodns.ai/api/scan/quick?domain=example.com"

这个端点返回最全面的信息，包括总分、等级和各分类详情。

针对性检查API：当你只需要特定信息时，可以使用细分API，减少响应数据量，提高效率。

# 只检查邮件安全配置 curl "https://intodns.ai/api/email/check?domain=example.com" # 只检查DNSSEC状态 curl "https://intodns.ai/api/dns/dnssec?domain=example.com" # 获取所有DNS记录 curl "https://intodns.ai/api/dns/lookup?domain=example.com"

生成报告和徽章：

# 获取PDF报告链接（可直接下载） curl -I "https://intodns.ai/api/pdf/example.com" # 会返回重定向到PDF文件的地址 # 获取SVG格式的评分徽章（可用于README） # 徽章URL: https://intodns.ai/api/badge/example.com # Markdown格式: [![DNS Health](https://intodns.ai/api/badge/example.com)](https://intodns.ai/scan/example.com)

将徽章添加到项目README，能给访客一个直观的域名健康度印象，体现项目的专业性。

4. 典型问题排查与修复实战

光知道问题在哪不够，关键是如何修复。下面结合intodns常见的报错，给出实战排查步骤和修复命令示例。

4.1 问题：SPF记录导致“Too many DNS lookups”

intodns报告提示：SPF: FAIL - Too many DNS lookups (12/10)

原因分析：你的SPF记录里使用了太多的include机制。例如，如果你使用了Google Workspace (include:_spf.google.com)、SendGrid (include:sendgrid.net)、Mailchimp (include:servers.mcsv.net)等多个第三方邮件服务，再加上自己的IP列表，就很容易超限。SPF评估时，每解析一个include、a、mx、ptr机制都可能产生多次DNS查询。

排查与修复步骤：

获取当前SPF记录：

dig TXT yourdomain.com +short | grep -i "v=spf1"

或者用intodns的API：

curl -s "https://intodns.ai/api/email/spf?domain=yourdomain.com" | jq '.record'

分析并简化：常见的优化策略是使用redirect机制。你可以创建一个专门的SPF记录用于整合。
- 错误示例（易超限）：
```
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ip4:192.0.2.1 ~all
```
- 优化方案： a. 为子域名spf.yourdomain.com创建一条整合记录：
```
# spf.yourdomain.com 的TXT记录 v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all
```
  b. 将主域的SPF记录改为redirect，这本身只算一次查询：
```
# yourdomain.com 的TXT记录 v=spf1 redirect=spf.yourdomain.com ip4:192.0.2.1 ~all
```
  注意，redirect会完全替代当前记录，所以主记录里额外的ip4需要放在redirect前面，或者也整合到子域名的记录里。
验证修复：修改DNS记录并等待生效（TTL时间过后），再次运行intodns检查。

4.2 问题：DNSSEC验证链断裂

intodns报告提示：DNSSEC: FAIL - No DS record found at parent或DNSSEC: FAIL - RRSIG signature expired

原因分析：

DS记录缺失：你在你的域名注册商或DNS服务商处启用了DNSSEC，并获得了DS记录（一串由KSK公钥生成的摘要），但没有将这个DS记录提交到你的域名注册局（如.com， .net的管理机构）。DNSSEC的信任链是从根域自上而下传递的，父域没有你的DS记录，链就断了。
签名过期：DNSSEC的签名（RRSIG）有有效期。如果DNS服务商没有正确配置自动签名轮换，或者轮换过程出错，就会导致签名过期。

排查与修复步骤：

检查DS记录状态：
```
# 使用dig检查父域（如.com）是否有你的DS记录 dig DS yourdomain.com +trace +short # 或者使用专门的在线工具如 verisign labs 的 dnssec-debugger
```
如果确认缺失，你需要登录域名注册商的后台（如GoDaddy， Namecheap， Cloudflare Registrar），找到DNSSEC设置页面，将你的DNS服务商提供的DS记录（通常有4个字段：Key Tag， Algorithm， Digest Type， Digest）添加进去。
检查RRSIG有效期：
```
dig yourdomain.com ANY +dnssec | grep -A1 -B1 "RRSIG"
```
查看输出中的expiration时间。如果已过期，你需要联系你的DNS服务商（如Cloudflare， AWS Route 53）支持，检查其DNSSEC签名服务的状态。通常这是服务商端的全托管服务，你需要确保它正常运行。

重要提示：在修复DNSSEC问题时，尤其是添加或更新DS记录，需要密切关注域名的解析情况。错误的DS记录会导致所有启用DNSSEC验证的解析器（如Google Public DNS 8.8.8.8， Cloudflare 1.1.1.1）无法解析你的域名，造成严重故障。建议在业务低峰期操作，并提前了解如何快速撤销DS记录。

4.3 问题：邮件安全协议配置不全

intodns报告提示：DMARC: FAIL - Record not found或DKIM: WARNING - No common selectors found

原因分析：这是新域名或刚配置邮件服务后最常见的问题。DMARC记录根本不存在，DKIM记录因为选择器名称不常见而未被工具发现。

修复步骤：

配置DMARC： DMARC记录是TXT类型，主机名是_dmarc.yourdomain.com。一个基础的、监控模式的DMARC记录如下：
```
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1
```
- p=none：策略为“不采取任何操作”，仅用于收集报告。
- rua：指定聚合报告发送的邮箱。
- ruf：指定取证报告（关于失败邮件的详细报告）发送的邮箱（可选）。
- fo=1：报告生成选项，建议设置。你可以先使用p=none运行几周，分析收到的报告，确认SPF和DKIM都工作正常后，再将策略逐步升级为p=quarantine（隔离）或p=reject（拒绝）。
确认并发布DKIM：
- 首先，在你的邮件服务商（如SendGrid， Mailgun，自建Postfix with OpenDKIM）后台找到生成的DKIM公钥和指定的选择器（例如selector1）。
- 然后，在你的DNS服务商处，添加一条TXT记录。
  - 主机名/名称：selector1._domainkey.yourdomain.com（将selector1替换为你的实际选择器）
  - 值/内容：v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...（很长的一串公钥）
- 添加后，可以使用intodns的专用API检查：
```
curl "https://intodns.ai/api/email/dkim?domain=yourdomain.com"
```
  如果工具没发现，但你知道选择器，可以手动验证：
```
dig TXT selector1._domainkey.yourdomain.com +short
```

4.4 问题：域名或IP被列入黑名单

intodns报告提示：Security: FAIL - IP 192.0.2.1 listed in 2 blacklist(s)

排查与修复步骤：

确认黑名单来源：intodns的报告通常不会列出具体是哪个黑名单。你需要使用更专业的黑名单查询工具，如mxtoolbox.com的Blacklist Check或whatismyipaddress.com/blacklist-check，输入你的服务器IP，查看具体被哪些名单收录。
分析原因：常见原因包括：服务器曾被入侵并发送垃圾邮件、同一IP段的邻居有不良行为（共享IP常见）、IP地址是动态分配（住宅IP）却被用于发邮件。
申请移除：
- 访问列出你IP的黑名单项目官网（如Spamhaus， Barracuda）。
- 找到其移除（Delist）页面，通常需要你提供IP地址、说明情况（例如，问题已修复，服务器已加固）。
- 按照指引提交移除申请。有些是自动的，检查通过后几小时内移除；有些需要人工审核，可能需要1-2个工作日。
根本性解决：
- 使用专用IP：对于重要的邮件发送服务（如交易邮件、通知邮件），建议使用云邮件服务商（如Amazon SES， SendGrid）或购买独立的、干净的静态IP。
- 配置反向DNS（PTR记录）：确保你的邮件服务器IP有正确的反向DNS解析，指向你的邮件域名。这对于建立发件人信誉至关重要。
- 遵循发送规范：控制发送频率、清理邮件列表、设置退订机制，避免被收件方系统判定为垃圾邮件。

5. 将intodns融入日常运维与开发流程

工具的价值在于被使用。以下是一些将intodns深度集成到工作流中的思路：

1. 预发布检查清单：在将新域名或子域名指向生产环境前，将其加入一个检查脚本：

#!/bin/bash DOMAINS=("staging.newapp.com" "api.newapp.com") MIN_SCORE=90 for domain in "${DOMAINS[@]}"; do echo "Checking $domain..." SCORE=$(npx intodns $domain --json 2>/dev/null | jq '.score') if [[ $SCORE -lt $MIN_SCORE ]]; then echo "❌ $domain 安全检查未通过 (得分：$SCORE)。请修复后再发布。" exit 1 else echo "✅ $domain 安全检查通过 (得分：$SCORE)。" fi done echo "所有域名检查通过，可以发布。"

2. 周期性健康报告：结合Cron任务和邮件/钉钉/飞书机器人，每周发送一份所有负责域名的健康报告摘要。

# 每周一早上8点运行 0 8 * * 1 /path/to/your/scan_and_report.sh

报告脚本可以调用intodnsAPI获取JSON数据，然后格式化，只列出有问题的域名和具体项，通过curl发送到Webhook。

3. 与基础设施即代码（IaC）结合：如果你使用Terraform、Pulumi等工具管理DNS记录（如在Cloudflare， AWS Route 53上），可以在CI/CD流水线中，在terraform apply之后，自动运行intodns检查，验证配置应用后的最终状态是否符合预期，实现“配置即正确”的闭环。

4. 内部知识库建设：每次通过intodns发现并解决一个配置问题后，可以将问题现象、排查过程、修复命令和原理总结成文档，积累成团队的“DNS/邮件安全排错手册”。久而久之，团队对新服务的配置标准会自然提高，共性错误会大幅减少。

这个工具的强大之处在于，它把原本需要深厚协议知识和分散工具操作才能完成的安全审计，变成了一条命令、一个API调用。它不能替代你对协议原理的深入理解，但绝对是提高效率、预防问题、快速排障的利器。尤其是在微服务、多域名、多云架构成为常态的今天，拥有这样一个自动化的“域名健康哨兵”，能让你的运维防线更加稳固。

查看全文

http://www.jsqmd.com/news/712849/