跳转至

DNS Vulnerability: Dangling Domain Records

DNS 漏洞：悬空域名记录 (Dangling Domain Records)

描述

当 DNS 记录指向不再活跃或不再受组织控制的资源时，就会出现悬空域名 (dangling domains)。这些错误配置可能导致域名劫持、数据泄露和声誉受损。以下领域是管理悬空域名时的关键关注点：

1. 云资源引用

指向已取消配置的云资源的 DNS 记录会带来重大风险。常见的错误配置包括： * 孤立的 CNAME 记录指向已终止的云服务 * A 记录指向已释放的 IP 地址 

# 危险的悬空记录
app.example.com.    IN CNAME   terminated-app.cloudservice.com.
api.example.com.    IN A       203.0.113.0   # Released IP

# 妥善停用
# 1. 释放资源前移除 DNS 记录
# 2. 或替换为受控占位符
app.example.com.    IN CNAME   service-offline.example.com.

2. 第三方服务集成

指向已停止使用的第三方服务的记录会产生安全漏洞： * 废弃的子域名委派 * 过期的服务端点 

# 危险配置
analytics.example.com.   IN CNAME   client-xyz.analytics-service.com.    # Service discontinued
track.example.com.      IN CNAME   example.abandoned-tracker.com.        # Company defunct

# 安全配置
# 始终维护内部服务依赖项清单
analytics.example.com.   IN CNAME   active-client.current-service.com.

3. 子域名管理

子域名清理不当会导致潜在的接管 (takeover) 场景： * 被遗忘的开发/预发布 (staging) 环境 * 传统应用程序子域名 * 不活跃的项目环境 

# 存在漏洞的子域名
dev.example.com.        IN CNAME   old-project.github.io.        # Repository deleted
stage.example.com.      IN CNAME   staging.heroku.com.          # App removed
beta.example.com.       IN A       198.51.100.1                 # Server decommissioned

# 妥善的记录管理
# 定期审计并移除不活跃的子域名
dev.example.com.        IN A       203.0.113.10                 # Internal development server
staging.example.com.    IN CNAME   current-stage.example.com.   # Active staging environment

4. 邮件服务器记录

废弃的与邮件相关的记录可能导致电子邮件欺骗 (spoofing) 和网络钓鱼 (phishing)： * 过期的 MX 记录 * 弃用的邮件服务器引用 

# 危险的邮件配置
example.com.    IN MX    10 legacy-mail.example.com.    # Server decommissioned
mail.example.com.   IN A    203.0.113.50               # Released IP

# 安全配置
example.com.    IN MX    10 primary-mail.example.com.
example.com.    IN MX    20 backup-mail.example.com.

5. 证书验证记录

废弃的域名验证记录会带来安全风险： * 过期的 ACME 挑战记录 * 被遗忘的域名验证 CNAME 记录 

# 存在风险的验证记录
_acme-challenge.example.com.    IN TXT    "abandoned-validation-token"
validate.example.com.          IN CNAME   validate.oldcertprovider.com.

# 干净的配置
# 签发证书后移除验证记录
# 使用自动证书管理

6. 服务发现记录

过时的服务发现条目可能会暴露内部基础架构： * 针对已停止服务的 SRV 记录 * 传统服务端点引用 

# 暴露的服务记录
_ldap._tcp.example.com.    IN SRV    0 0 389 old-dc.example.com.
_xmpp._tcp.example.com.    IN SRV    0 0 5222 chat.example.com.

# 适当清理
# 停用时移除或更新服务记录
_ldap._tcp.example.com.    IN SRV    0 0 389 current-dc.example.com.

这些悬空域名的错误配置可能导致严重的安全事件，包括： * 域名接管攻击 (domain takeover attacks) * 通过被劫持端点进行的数据外泄 * 使用合法域名进行的网络钓鱼活动 * 品牌声誉受损 * 内部基础架构细节暴露

组织应实施定期的 DNS 审计，维护服务清单，并遵循适当的停用程序，以防止出现悬空域名漏洞。

建议

为了降低与悬空域名相关的风险，请考虑以下建议：

  • 从域名清单开始： 开始对所有域名和子域名进行全面审计： 

    # 示例域名清单格式
domain: example.com
subdomains:
  - app.example.com -> AWS CloudFront
  - api.example.com -> Azure App Service
  - mail.example.com -> Google Workspace
owner: DevOps Team

  • 实施渐进式监控级别： 根据域名的关键性扩展监控规模： | 域名类型 | 检查频率 | 原因 | |-------------------|----------------|----------------------------------| | 生产环境关键 | 每 5 分钟 | 业务关键型服务 | | 面向客户 | 每 15 分钟 | 客户体验影响 | | 内部工具 | 每小时 | 内部运营支持 | | 开发环境 | 每 6 小时 | 非关键环境 |

  • 定期域名审计：

  • 验证所有云资源连接
  • 检查第三方服务依赖项
  • 验证 DNS 记录的准确性

  • 监控子域名证书

  • 安全最佳实践：

  • 为 DNS 管理使用专用的云凭据
  • 对 DNS 更改实施严格的 RBAC
  • 启用对所有 DNS 修改的审计日志记录

  • 维护 DNS 更改审批工作流

  • 操作程序：

  • 记录所有域名所有权细节
  • 创建服务停用检查表
  • 维护云资源映射

  • 测试域名接管预防措施

  • 计划中的停用策略：

  • 从资源识别开始
  • 记录所有依赖项
  • 监控活跃连接
  • 删除 DNS 记录
  • 归档配置细节

这些建议有助于确保适当的域名管理，并在保持运营效率的同时防止悬空域名漏洞。

链接

标准

  • SOC2_CONTROLS:
    • CC_6_1
    • CC_6_6
    • CC_6_7
    • CC_6_8
    • CC_7_1
    • CC_7_2
    • CC_8_1
  • CCPA:
    • CCPA_1798_150
  • GDPR:
    • ART_25
    • ART_32
  • HIPAA_CONTROLS:
    • SECURITY212
    • SECURITY213