home / skills / steipete / agent-scripts / domain-dns-ops

domain-dns-ops skill

safe

This skill guides onboarding and management of DNS and redirects across Cloudflare, DNSimple, and Namecheap, using a centralized manager.

npx playbooks add skill steipete/agent-scripts --skill domain-dns-ops

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

2.9 KB

---
name: domain-dns-ops
description: >
  Domain/DNS ops across Cloudflare, DNSimple, Namecheap for Peter. Use for onboarding zones to Cloudflare, flipping nameservers, setting redirects (Page Rules/Rulesets/Workers), updating redirect-worker mappings, and verifying DNS/HTTP. Source of truth: ~/Projects/manager.
---

# Domain/DNS Ops (Peter)

This skill is a thin router: use `~/Projects/manager` as truth, run the repo scripts, follow the checklists.

## Source of truth (read first)

- `~/Projects/manager/DOMAINS.md` (domain -> target map; registrar hints; exclusions)
- `~/Projects/manager/DNS.md` (Cloudflare onboarding + DNS/redirect checklist)
- `~/Projects/manager/redirect-worker.ts` + `~/Projects/manager/redirect-worker-mapping.md` (worker redirects)

## Golden path (new vanity domain -> Cloudflare -> redirect)

1. **Decide routing model**
   - Page Rule redirect (small scale, per-zone).
   - Rulesets / Bulk Redirects (account-level; needs token perms).
   - Worker route (fallback; uses `redirect-worker`).
2. **Cloudflare zone**
   - Create zone (UI), then confirm with `cli4`:
     - `cli4 --get name=example.com /zones`
3. **Nameservers**
   - If registrar = Namecheap: `cd ~/Projects/manager && source profile && bin/namecheap-set-ns example.com emma.ns.cloudflare.com scott.ns.cloudflare.com`
   - If registrar = DNSimple: see `~/Projects/manager/DNS.md` for delegation API notes.
4. **DNS placeholders (so CF can terminate HTTPS)**
   - Proxied apex `A` + wildcard `A` → `192.0.2.1` (see `~/Projects/manager/DNS.md` for exact `cli4` calls).
5. **Redirect**
   - If using Page Rules: use the `cli4 --post ... /pagerules` template from `~/Projects/manager/DNS.md`.
   - If using Worker: update mapping (`~/Projects/manager/redirect-worker-mapping.md`), deploy/bind routes per `~/Projects/manager/DNS.md`.
6. **Verify**
   - DNS: `dig +short example.com @1.1.1.1` (expect CF anycast).
   - HTTPS redirect: `curl -I https://example.com` (expect `301`).

## Common ops

- **Cloudflare token sanity**: `source ~/.profile` (prefer `CLOUDFLARE_API_TOKEN`; `CF_API_TOKEN` fallback).
- **Disable “Block AI bots”**: `cd ~/Projects/manager && source profile && bin/cloudflare-ai-bots status` / `bin/cloudflare-ai-bots disable`.

## After edits (commit/push)

If you changed anything in `~/Projects/manager` (docs, worker, scripts, mappings): commit there too.

1. Review: `cd ~/Projects/manager && git status && git diff`
2. Stage: `git add <paths>`
3. Commit (Conventional Commits): `git commit -m "feat: …"` / `fix:` / `docs:` / `chore:`
4. Push only when explicitly asked: `git push origin main`

## Guardrails

- Don’t touch `.md` lore domains or `steipete.md` unless explicitly asked; check `~/Projects/manager/DOMAINS.md`.
- Confirm registrar before debugging CF “invalid nameservers” (often “wrong registrar”).
- Prefer reversible steps; verify after each change (NS → DNS → redirect).

Overview

This skill manages Domain and DNS operations across Cloudflare, DNSimple, and Namecheap for Peter. It uses ~/Projects/manager as the source of truth and runs the repository scripts to onboard zones, flip nameservers, configure redirects, and verify DNS/HTTP. The goal is safe, reversible changes with checklist-driven verification.

How this skill works

Read ~/Projects/manager first to get domain maps, DNS checklists, and redirect-worker mappings. Use the included scripts and cli4 commands to create Cloudflare zones, set nameservers at registrars, add DNS placeholder records for HTTPS termination, and apply redirects via Page Rules, Rulesets, or Workers. Finish with DNS and HTTP verification commands and commit any changes back to ~/Projects/manager when appropriate.

When to use it

Onboard a new vanity domain to Cloudflare
Flip registrar nameservers (Namecheap, DNSimple) to Cloudflare
Implement or update HTTP redirects (Page Rules, Rulesets, Worker)
Verify DNS delegation and HTTPS redirect behavior
Perform routine Cloudflare token or AI-bot configuration checks

Best practices

Always read ~/Projects/manager files (DOMAINS.md, DNS.md, redirect-worker-mapping.md) before changing anything
Confirm the registrar listed in DOMAINS.md before troubleshooting nameserver issues
Prefer reversible operations and verify at each stage: NS → DNS → redirect → HTTPS
Use conventional commit messages and only push changes to ~/Projects/manager when explicitly instructed
Avoid editing protected lore entries in DOMAINS.md unless explicitly requested

Example use cases

Onboard example.com: create Cloudflare zone, add placeholder A records, set Namecheap nameservers, deploy redirect via Page Rule
Switch an existing site to worker-based redirects: update redirect-worker mapping, bind routes, deploy worker
Bulk-account redirect: use Rulesets with appropriate account-level token permissions
Troubleshoot invalid nameservers: confirm registrar and reapply delegation via registrar API or namecheap script
Disable Cloudflare "Block AI bots" setting using the provided manager scripts

FAQ

What should I check first when a domain isn’t resolving?

Confirm the registrar recorded in ~/Projects/manager/DOMAINS.md, verify nameservers at the registrar, then run dig against 1.1.1.1 to confirm Cloudflare anycast resolution.

When should I use a Worker vs Page Rules?

Use Page Rules for a small number of per-zone redirects, Rulesets for bulk account-level redirects (requires token perms), and Workers when you need flexible or fallback routing defined in redirect-worker-mapping.