关于 dns-intelligence
dns-intelligence 是用于检查 DNS 配置、邮件认证和子域暴露情况的 MCP 服务及命令行工具,适用于安全审查。它覆盖 DNS 记录与子域接管风险,并提供问题结果和修复建议。
主要功能
- 01枚举常见 DNS 记录
- 02检查 SPF、DMARC 和 DKIM 配置
- 03通过证书透明度日志和词表发现子域
- 04检测可能的子域接管
- 05审计 DNSSEC、CAA 和名称服务器
- 06提供评级和修复建议
适用场景
- 01审查域名的 DNS 与邮件安全
- 02在攻击者发现前查找悬空子域
- 03比较多个域名的 DNS 问题
- 04在 CI 或部署前运行 DNS 检查
MCP 相关
提供用于 DNS 枚举、域名审计、子域发现、接管检查和邮件安全分析的 MCP 工具。
配置
本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。
工具
4收录的工具列表 · 更新于 2 周前
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
| domain | string | 是 | 要枚举的域名(例如:example.com) |
详细介绍
@guardbee/mcp-dns-intelligence
🇬🇧 English | 🇹🇷 Türkçe | 🇨🇳 中文 | 🇯🇵 日本語 | 🇰🇷 한국어 | 🇧🇷 Português | 🇪🇸 Español | 🇩🇪 Deutsch
一个 MCP 服务,可枚举 DNS 记录、检测 SPF / DMARC / DKIM 配置错误,并通过证书透明度日志和词表发现可能被接管的子域名。使用 Node.js 内置的 dns/promises,无需外部依赖。
默认情况下,遥测功能处于关闭状态。设置
GUARDBEE_TELEMETRY=1后,会发送服务、工具、成功状态、耗时以及文件路径等较短的参数值;较长的字符串以及content、token或password等字段会替换为占位符。请参阅@guardbee/mcp-telemetry。
功能
- 完整 DNS 枚举 — A、AAAA、MX、NS、TXT、CNAME、SOA 记录
- SPF 分析 —
+all、?all、重复记录,以及按接收方的方式计算 RFC 7208 限制:跨嵌套include/redirect的 DNS 查询(最多 10 次)、无效查询(最多 2 次)、include 循环和缺失的 include - DMARC 分析 — 策略(
none/quarantine/reject)、pct、缺少rua地址 - DKIM 检查 — 探测 9 个常见选择器(
default、google、selector1、mail等) - 子域名发现 — 从证书透明度日志(crt.sh 和 Cert Spotter,并行查询;只发送域名)获取名称,另加 75 个名称的词表,并过滤通配符 DNS;检查每个有效名称是否存在子域名接管风险
- 电子邮件安全摘要 — 综合分析 SPF + DMARC + DKIM,并提供可直接复制粘贴的修复建议
- 23 项单元测试 — 纯逻辑测试,无需网络连接
快速开始
npm install -g @guardbee/mcp-dns-intelligence
添加到 claude_desktop_config.json:
{
"mcpServers": {
"guardbee-dns-intelligence": {
"command": "npx",
"args": ["-y", "@guardbee/mcp-dns-intelligence"]
}
}
}
MCP 工具
| 工具 | 描述 |
|---|---|
enumerate_dns | 全面的 DNS 检查,并给出 A–F 评级:记录、SPF/DMARC/DKIM、MTA-STS、DNSSEC、CAA、名称服务器 |
audit_domains | 审计最多 20 个域名,并比较其评级和主要发现 |
enumerate_subdomains | 探测常见子域名(识别通配符);检测子域名接管 |
check_takeover | 检查给定主机名是否存在子域名接管风险 |
check_email_security | 综合审计 SPF + DMARC + DKIM,并提供修复建议 |
lookup_dns | 按指定记录类型(A/MX/TXT 等)执行定向 DNS 查询 |
使用示例
你可以询问 Claude:
“example.com 的 DNS 配置有问题吗?”
“审计 example.com 的电子邮件安全——SPF、DMARC 和 DKIM”
“列出 example.com 的子域名,并标记任何悬空的子域名”
“example.com 的 MX 记录有哪些?”
输出示例
Email Security Check: example.com
──────────────────────────────────────────────────
── SPF ─────────────────────────────────────────
✓ v=spf1 include:_spf.google.com -all
── DMARC ───────────────────────────────────────
✗ No DMARC record found at _dmarc.example.com
Add: v=DMARC1; p=quarantine; rua=mailto:[email protected]
── DKIM ────────────────────────────────────────
✓ Found DKIM selectors: google
SPF 检查结果
| 代码 | 严重性 | 描述 |
|---|---|---|
SPF_MISSING | 🟡 中 | 未找到 SPF 记录 |
SPF_PERMISSIVE_ALL | 🔴 严重 | +all — 允许任何服务器 |
SPF_NEUTRAL_ALL | 🟠 高 | ?all — 不拒绝未授权的发件人 |
SPF_NO_ALL | 🟡 中 | 没有 all 机制 |
SPF_TOO_MANY_LOOKUPS | 🟠 高 | DNS 查询次数 > 10 — 会导致 SPF 验证失败 |
SPF_DUPLICATE | 🟠 高 | 存在多条 SPF 记录 |
SPF_AT_LOOKUP_LIMIT | 🔵 低 | 查询次数正好为 10 — 再多一个 include 就会导致 SPF 验证失败 |
SPF_TOO_MANY_VOID_LOOKUPS | 🟠 高 | 超过 2 个 include 未返回记录 |
SPF_INCLUDE_MISSING | 🟠 高 | include/redirect 目标没有 SPF 记录(permerror) |
SPF_INCLUDE_DUPLICATE | 🟠 高 | 被包含的域发布了多条 SPF 记录 |
SPF_INCLUDE_LOOP | 🟠 高 | include 循环引用回正在评估的记录 |
SPF_PTR | 🔵 低 | 使用了已弃用的 ptr 机制 |
DMARC 检查结果
| 代码 | 严重性 | 描述 |
|---|---|---|
DMARC_MISSING | 🟠 高 | 没有 DMARC 记录 |
DMARC_NO_POLICY | 🟠 高 | 缺少 p= 策略 |
DMARC_POLICY_NONE | 🟡 中 | p=none — 监控模式,不执行策略 |
DMARC_PCT_LOW | 🔵 低 | pct < 100 — 部分执行策略 |
DMARC_NO_RUA | 🔵 低 | 没有汇总报告地址(rua) |
DMARC_MULTIPLE | 🟠 高 | 存在多条 DMARC 记录 — 接收方会忽略所有记录 |
DMARC_INVALID_POLICY | 🟠 高 | p= 不是 none、quarantine 或 reject |
DMARC_SUBDOMAINS_NONE | 🟡 中 | sp=none 会使子域容易被伪造 |
DOMAIN_NOT_FOUND | 🟠 高 | 域名不存在(NXDOMAIN) |
没有自有 DMARC 记录的子域会继承父域的策略(sp=),与接收方的处理方式一致。子域枚举会检测通配符 DNS,并排除仅由通配符应答的名称。
DKIM、MX 和传输检查结果
| 代码 | 严重性 | 描述 |
|---|---|---|
DKIM_NOT_FOUND | 🟡 中 | 在约 35 个常见选择器下未找到 DKIM 密钥(通过 dkimSelectors 传入你的选择器) |
DKIM_KEY_WEAK | 🟠 高 | RSA 密钥短于 1024 位 |
DKIM_KEY_1024 | 🟡 中 | 1024 位 RSA 密钥 — 应轮换为 2048 位(RFC 8301) |
DKIM_KEY_INVALID | 🟡 中 | 无法解析已发布的密钥 |
DKIM_TESTING | 🔵 低 | t=y 测试模式 |
MX_UNRESOLVABLE | 🟠 高 | 某个 MX 主机没有 A/AAAA 记录 |
MTA_STS_MISSING | 🔵 低 | 没有 MTA-STS:入站邮件可能会被降级为明文 |
MTA_STS_MX_MISMATCH | 🟠 高 | 强制执行策略未包含一个有效 MX — 合规的发件方会拒绝投递 |
MTA_STS_POLICY_UNREACHABLE / _INVALID | 🟡 中 | 策略文件缺失、被重定向或格式错误 — 发件方会忽略 MTA-STS |
MTA_STS_TESTING / _MODE_NONE / _MAX_AGE_SHORT | 🔵 低 | 未强制执行、已撤销,或 max_age 少于一天 |
TLSRPT_MISSING / _INVALID | 🔵 低 | MTA-STS 旁边没有可用的 TLS-RPT |
如果域名有 MX 记录,SPF_MISSING 的严重性为 🟠 高(建议使用初始记录,例如 Google Workspace 的 v=spf1 include:_spf.google.com ~all);否则为 🟡 中(建议使用 v=spf1 -all)。
名称服务器发现
会直接通过 DNS(UDP/TCP 53)查询区域的每台名称服务器:不递归的 SOA 查询、AXFR 请求(只读取首批消息,不会下载整个区域),以及对其未托管名称的递归查询。使用 --no-ns-probe / nameserverProbe: false 可跳过。
| 代码 | 严重程度 | 描述 |
|---|---|---|
NS_AXFR_ALLOWED | 🟠 高 | 任何人都可以下载整个区域(区域传送) |
NS_LAME | 🟠 高 | 列出的名称服务器未进行权威应答(REFUSED、SERVFAIL、没有 AA,或没有应答) |
NS_UNRESOLVABLE | 🟠 高 | 名称服务器自身的名称没有地址 |
NS_OPEN_RESOLVER | 🟡 中 | 名称服务器会为任何人应答递归查询(可能导致放大攻击、缓存投毒) |
NS_SOA_SERIAL_MISMATCH | 🔵 低 | 同一主服务器的服务器返回了不同的序列号(多服务商配置会按主服务器分别比较) |
DNSSEC 和 CAA 发现
| 代码 | 严重程度 | 描述 |
|---|---|---|
DNSSEC_BROKEN | 🔴 严重 | 验证失败——验证型解析器(Google、Cloudflare 和大多数 ISP)无法解析该域名 |
DNSSEC_NO_DS | 🟡 中 | 区域已签名,但父区域没有 DS,因此不会进行验证 |
DNSSEC_WEAK_ALGORITHM | 🟡 中 | 已弃用的签名算法(RSASHA1、RSAMD5、DSA、GOST;RFC 8624) |
DNSSEC_DS_SHA1 | 🔵 低 | 唯一的 DS 摘要为 SHA-1 |
DNSSEC_DISABLED | 🔵 低 | 区域未签名 |
CAA_BLOCKS_CURRENT_CA | 🟡 中 | CAA 不允许签发当前有效证书的 CA——证书续期将失败 |
CAA_UNKNOWN_CRITICAL | 🟠 高 | 存在 CA 无法理解的关键 CAA 标签——所有 CA 都必须拒绝签发 |
CAA_MISSING | 🔵 低 | 整个上级域名树中都没有 CAA:任何 CA 都可以签发 |
DNSSEC 检查通过 DNS-over-HTTPS(dns.google)读取,并比较验证型查询与 cd=1(禁用检查)的查询,因为 Node 的解析器无法读取 DS/DNSKEY 记录或 AD 标志。CAA 检查遵循 RFC 8659(最近的祖先),并将其与 :443 上提供的证书的签发者进行比较。使用 http: false 可跳过这两项检查。
子域名接管检测
会检查每个带有 CNAME 的有效子域名,并沿 CNAME 链跟进(最多 5 跳)。也会检查通配符记录:失效的 *.domain 会使所有未列出的名称都可被认领。
| 风险 | 情况 | 服务商 |
|---|---|---|
| ⚠️ 可能被接管 | 服务商允许任何人认领该名称 | AWS S3(NoSuchBucket 页面)、Microsoft Azure 和 AWS Elastic Beanstalk(CNAME 目标返回 NXDOMAIN)、Surge.sh(project not found),以及任何 CNAME 指向未注册域名的情况 |
| ⚠️ 需手动验证 | 资源已消失,但服务商可能要求验证域名 | GitHub Pages、Heroku、Netlify、Vercel、Ghost、Pantheon、WordPress.com、Help Scout、Tumblr、ngrok |
| 🧹 过时记录 | 目标已消失,但位于仅由其所有者控制的已注册域名下——删除该记录;这不属于接管,也不会导致 CI 失败 | 其他任何服务商 |
每个页面指纹都已与服务商上一个随机的、未被认领的名称进行比对。对于其“未找到”页面已不再带有稳定标记的服务商,不会列出。HTTP 检查会向子域名发送一次 GET /(先 HTTPS,再 HTTP);使用 --no-http / httpProbe: false 可关闭检查。对于已知主机名,可使用 check_takeover / takeover <host…>。
CLI — CI/CD 集成
除了 MCP 服务模式外,也可以直接将其作为 CLI 使用:
# Full DNS + email security check
npx @guardbee/mcp-dns-intelligence check example.com
# Fail only on high and above
npx @guardbee/mcp-dns-intelligence check example.com --fail-on=high
# Subdomain scan — exits 1 if a dangling CNAME is found
npx @guardbee/mcp-dns-intelligence subdomains example.com
# Subdomain scan with higher concurrency
npx @guardbee/mcp-dns-intelligence subdomains example.com --concurrency=50
# JSON output
npx @guardbee/mcp-dns-intelligence check example.com --format=json
# Several domains with an A–F grade each and a summary table (or every domain in guardbee.yml when none is given)
npx @guardbee/mcp-dns-intelligence check example.com example.de example.co.uk
npx @guardbee/mcp-dns-intelligence check --format=sarif > dns.sarif
评分:每个发现的问题都会扣分(严重 40 分、高 20 分、中 8 分、低 2 分),最严重问题会限制评分上限——出现任何严重问题则为 F,出现任何高风险问题则最高为 C,出现任何中风险问题则最高为 B。
退出代码: 0 = 无问题 · 1 = 发现超过阈值的问题 / 存在失效子域名 · 2 = 错误
通过 guardbee.yml 配置
在项目根目录创建 guardbee.yml,以保存 CLI 标志。CLI 标志始终优先于文件设置。
dns-intelligence:
fail-on: high # critical | high | medium | low
concurrency: 20 # parallel subdomain probes
domains: # used when no domain is given on the CLI
- example.com
- staging.example.com
示例文件请参阅 guardbee.example.yml。
GitHub Actions — DNS 安全审计
name: DNS Security Check
on:
schedule:
- cron: "0 6 * * *" # Every day at 06:00
workflow_dispatch:
jobs:
dns-check:
runs-on: ubuntu-latest
steps:
- name: Check DNS configuration
run: npx @guardbee/mcp-dns-intelligence check ${{ vars.DOMAIN }} --fail-on=high
- name: Scan for dangling subdomains
run: npx @guardbee/mcp-dns-intelligence subdomains ${{ vars.DOMAIN }}
GitLab CI
dns-security:
image: node:20
script:
- npx @guardbee/mcp-dns-intelligence check $DOMAIN --fail-on=high
- npx @guardbee/mcp-dns-intelligence subdomains $DOMAIN
only:
- schedules
部署前电子邮件安全检查
- name: Verify email security records
run: |
npx @guardbee/mcp-dns-intelligence check ${{ vars.DOMAIN }} \
--fail-on=high \
--format=json | tee dns-report.json
- name: Upload DNS report
uses: actions/upload-artifact@v4
with:
name: dns-security-report
path: dns-report.json
开发
npm install
npm test # 23 unit tests
npm run build # TypeScript compile
许可证
MIT — GuardBee
反馈
有问题、想法或发现误报?请在 GitHub Discussions 中发起讨论,或提交 issue。如果 GuardBee 对你有帮助,请在代码仓库点个 ⭐,帮助其他人找到它。
评论
一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。