Domain Dns Ops

核心功能

该 Skill 为个人定制化域名基础设施运维方案，采用「仓库即真理」的设计理念，所有配置以 ~/Projects/manager 目录下的 Markdown 文档和脚本为权威来源。核心能力覆盖：

1. 域名生命周期管理：Cloudflare 区域接入、注册商（Namecheap/DNSimple）Nameserver 批量切换
2. 重定向路由体系：支持 Page Rules、Rulesets/Bulk Redirects、Cloudflare Workers 三种模式灵活选型
3. 验证闭环：DNS 解析验证（dig）与 HTTPS 重定向验证（curl）双重确认
4. 安全与治理：AI 机器人拦截开关管理、受限域名保护（steipete.md 等敏感域需显式授权）

显著优势

• 声明式配置：所有路由映射、DNS 记录、重定向规则均以 Markdown/YAML 形式版本化管理，避免 UI 漂移
• 脚本化原子操作：封装 cli4、namecheap-set-ns 等工具链，降低 Cloudflare API 与注册商 API 的直接交互复杂度
• 多模式重定向：从简单 Page Rule 到高并发 Worker 方案，可按规模与性能需求渐进升级
• 显式安全边界：内置「受限域名单」与可逆操作原则，防止误触生产关键域名

潜在局限

• 强环境依赖：绑定特定用户（Peter）的本地目录结构与 shell 环境（source profile），迁移成本高
• 注册商覆盖有限：仅原生支持 Namecheap 和 DNSimple，其他注册商需手动介入或扩展脚本
• Token 权限隐式假设：依赖 CLOUDFLARE_API_TOKEN 环境变量，未内嵌权限校验逻辑
• 无并发控制：多域批量操作时需外部编排，脚本本身无分布式锁或事务机制

适合人群

• 拥有 10-100 个 vanity domain 的技术从业者
• 偏好「GitOps」式基础设施管理的开发者
• 需要快速搭建短链/重定向服务的独立开发者或小型团队

常规风险

| 风险场景 | 缓解措施 |

|---------|---------|

| Nameserver 切换导致服务中断 | 严格遵循 NS → DNS → redirect 三阶段验证，保留原 NS 回滚能力 |

| Worker 映射配置错误引发循环重定向 | 本地 `redirect-worker-mapping.md` review 后再部署 |

| API Token 泄露 | 优先使用最小权限 Token，避免将 Token 硬编码于脚本 |

| 误操作敏感域名（如 `steipete.md` lore） | 操作前强制读取 `DOMAINS.md` 排除清单 |

> 安全提示：该 Skill 涉及 DNS 权威记录修改与 TLS 证书边缘终止，建议在非生产环境充分验证后再应用于核心业务域名。

核心用法

Domain/DNS Ops (Peter) 是一款面向个人开发者的域名运维文档型 Skill，专精于 Cloudflare、DNSimple、Namecheap 三大平台的域名生命周期管理。其核心工作流围绕「vanity domain → Cloudflare 托管 → 重定向落地」的黄金路径展开，涵盖：

• 域名接入决策：支持 Page Rule（单域）、Rulesets/Bulk Redirects（账户级）、Worker 路由（兜底）三种重定向模型
• 自动化脚本调用：依托本地 ~/Projects/manager 仓库的 shell 脚本（namecheap-set-ns、cloudflare-ai-bots 等）完成 nameserver 切换、AI 爬虫屏蔽等操作
• 标准化验证链：通过 cli4、dig、curl 三工具构建「NS 解析 → DNS 生效 → HTTPS 重定向」的递进式验证

显著优点

1. 零代码攻击面：纯 Markdown 文档结构，无可执行文件、无第三方依赖，彻底消除远程代码执行风险
2. 显式操作授权：所有敏感操作（nameserver 切换、Token 加载）均需用户在本地终端手动执行，Skill 本身不发起任何 API 调用
3. 源真单一原则：以 ~/Projects/manager 为唯一配置源，内置 DOMAINS.md 黑名单机制，防止误触「lore domains」等保留域名
4. 合规性完备：通过 GDPR 数据最小化、用户同意机制、数据可携带性等六项合规检查，隐私评分 85

潜在局限

• 环境强依赖：要求用户预配置 ~/Projects/manager 仓库、Cloudflare API Token、shell profile 等本地环境，新手门槛较高
• 平台锁定：工作流深度耦合 Cloudflare 生态（cli4、特定 nameserver 命名），迁移至其他 CDN 需重写适配
• 人工审核瓶颈：git push 需显式授权，批量操作场景下效率受限；Page Rule 方案在 Cloudflare 新架构中已被标记为 legacy
• 无回滚机制：文档未提供自动化回滚流程，误操作 nameserver 切换可能导致服务中断

适合人群

• 持有 10-100 个 vanity domain 的技术型个人开发者
• 已采用 Cloudflare 作为主力 CDN、追求「代码即文档」运维风格的用户
• 具备 shell 脚本阅读能力、理解 DNS 传播延迟（TTL）的运维人员

常规风险

| 风险场景 | 缓解措施 |

|---------|---------|

| 误切换生产域名 nameserver | 严格遵循 `DOMAINS.md` 排除清单，变更前执行 `dig +short NS` 确认当前 registrar |

| Cloudflare Token 泄露 | `~/.profile` 中使用最小权限 Token（Zone:Read + DNS:Edit），避免全局 API Key |

| Worker 映射配置错误导致 redirect loop | 部署前在 staging 域名验证 `redirect-worker-mapping.md` 语法 |

| 本地仓库缺失导致脚本执行失败 | 首次使用前运行 `test -d ~/Projects/manager && echo "OK" || echo "MISSING"` 预检 |

---

> 安全提示：该 Skill 本身不执行任何命令，但文档中引用的 source ~/.profile、cli4 --post 等操作涉及敏感凭证加载与 DNS 变更，请务必在理解每条命令语义后执行，建议配合 git diff 审查所有配置变更。