domain-strategy
정보
이 스킬은 개발자가 도메인 포트폴리오, DNS 아키텍처, 리디렉션 전략을 계획하고 관리하는 데 도움을 줍니다. 등록 기관 선택, www와 애펙스 설정, 서브도메인 계획, 다중 사이트 구성과 같은 결정을 지원합니다. 새로운 사이트를 출시하거나 기존 도메인 구조를 최적화할 때 활용하세요.
빠른 설치
Claude Code
추천npx skills add rampstackco/claude-skills -a claude-code/plugin add https://github.com/rampstackco/claude-skillsgit clone https://github.com/rampstackco/claude-skills.git ~/.claude/skills/domain-strategyClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Domain Strategy
Decide how domains, subdomains, and DNS work across a portfolio. Stack-agnostic. Works for one site or one hundred.
When to use
- Setting up DNS for a new site (apex vs www, primary vs aliases)
- Choosing or switching registrars
- Planning redirects across multiple domains (parked, retired, consolidated)
- Deciding subdomain vs subfolder vs separate domain for a new product line
- Consolidating multiple sites into one
- Splitting one site into multiple
- Setting up DNS for email, security records, third-party services
When NOT to use
- Migrating content between platforms with URL changes (use
content-migration) - Email authentication setup specifically (use
email-deliverability) - Security headers or HTTPS config (use
security-baseline) - Internationalization domain choices (use
internationalization)
Required inputs
- Current domain inventory (every domain you own or operate)
- Status of each (live, parked, redirected, retired)
- Strategic role of each (primary brand, sub-brand, defensive registration, campaign)
- Current DNS provider and registrar for each
- Email and third-party service dependencies
The framework: 5 decisions
Every domain decision falls into one of these buckets. Address them in order.
Decision 1: Apex vs www as canonical
Pick one. Redirect the other to it. Pick before launch. Changing later is painful.
- Apex (example.com): cleaner, more memorable, the modern default.
- www (www.example.com): historically standard, easier to add CDN-level CNAME records (apex CNAME is technically forbidden but most providers offer ALIAS or ANAME).
Whichever you pick, the other must 301 to it. Both serving content is duplicate content and a soft signal of poor setup.
Decision 2: Subdomain vs subfolder vs separate domain
For a new product, blog, or content section:
| Pattern | Use when |
|---|---|
Subfolder (example.com/blog) | Same brand, want SEO equity to flow, default choice |
Subdomain (blog.example.com) | Different stack or platform, organizationally separate but related |
Separate domain (exampleblog.com) | Different brand, different audience, intentional separation |
Default to subfolder. The case for subdomain or separate domain has to be made.
Decision 3: Registrar strategy
The registrar is where the domain is registered. The DNS provider is where DNS records live. They can be the same or different.
Decisions:
- Single registrar vs multiple: single is simpler. Multiple makes sense for redundancy at scale.
- Lock and 2FA: non-negotiable. Domain hijacking is real and costly.
- Auto-renew: on for everything you care about. Off only for intentional drops.
- WHOIS privacy: on by default. Free at most modern registrars.
- Transfer lock: on except during planned transfers.
Decision 4: DNS provider
The DNS provider controls how domains resolve. Critical for performance, reliability, and security.
Pick a provider that gives you:
- Fast global resolution (anycast network)
- DNSSEC support
- API access for automation
- Reasonable record limits
- Good audit logs
Default DNS records every domain needs:
- A or AAAA records (or CNAME) for the apex and www
- MX records (even just nullified if no email)
- TXT for domain verification, SPF
- CAA records (locks down which certificate authorities can issue certs for the domain)
Decision 5: Parked domain strategy
Domains you own but aren't actively using. Three valid strategies:
- Redirect to a primary site. Best for defensively registered domains close to your main brand. 301 every path to the primary's homepage or matching path.
- Hold blank. A simple page or DNS NXDOMAIN. Acceptable for domains you may use later.
- Park with a landing page. Generic "coming soon" page. Lowest value. Avoid registrar default parking pages (often serve ads against your brand).
Anti-pattern: letting parked domains serve duplicate or near-duplicate content from your main site. This is an SEO liability.
Workflow
Step 1: Inventory
Pull every domain you own from every registrar. Build a single sheet:
| Domain | Registrar | DNS provider | Status | Role | Renewal date | Notes |
|---|
If you can't account for every domain, the strategy can't be accurate.
Step 2: Classify by role
Each domain gets one role:
- Primary (the main site for a brand)
- Alias (redirects to a primary)
- Defensive (registered to prevent others from getting it; usually parked)
- Campaign (short-term, specific use)
- Retired (no longer active; either drop at expiry or redirect permanently)
The classification drives the configuration.
Step 3: Audit current configuration
For each domain check:
- Is the canonical (apex vs www) consistent with the strategy?
- Are redirects 301 (permanent) where intended?
- Is HTTPS enforced on every variant?
- Are DNS records minimal and intentional?
- Is the registrar locked?
- Is auto-renew on?
- Is 2FA on the registrar account?
Document gaps. Each gap is a ticket.
Step 4: Set the canonical pattern
For new domains and any that need fixing:
- Pick apex or www as canonical
- Configure 301 redirect for the non-canonical
- Force HTTPS for both
- Verify with curl:
curl -I http://example.com,curl -I http://www.example.com,curl -I https://www.example.com. All should chain to a single 200 on the canonical.
Step 5: Document the redirect map
Across the portfolio, document every redirect:
| Source | Destination | Type | Reason | Date set |
|---|
This is invaluable when something breaks or when planning consolidations.
Step 6: Set up monitoring
Monitor:
- DNS resolution (alert on NXDOMAIN or wrong IP)
- HTTPS certificate expiration (alert at 30, 14, 7 days out)
- Redirect chains (alert if a 301 starts returning 200 or 404)
- Renewal dates (alert at 90, 30, 7 days out)
This is the bridge between domain strategy and monitoring-and-alerting.
Step 7: Document and revisit
Domain strategy is a quarterly review topic. Renewals, consolidations, and new launches change the picture. Without scheduled review, the portfolio drifts.
Failure patterns
Both apex and www serve content. Duplicate content. Pick one, redirect the other.
302 redirects where 301 was intended. 302 is temporary. 301 is permanent. SEO equity passes through 301, not (reliably) through 302.
HTTPS not enforced. HTTP variant serving content alongside HTTPS. Force HTTPS at the edge or the load balancer.
Registrar default parking pages. Parked domains serving registrar ads. Free for the registrar, bad for you. Replace with a redirect or your own page.
Domains in multiple registrars by accident. Migrations that didn't fully complete. Consolidate.
No CAA records. Anyone with a misconfigured ACME client can issue a cert for your domain. CAA limits which CAs can issue. Add it.
Auto-renew off "to save money." Domain accidentally drops, gets snapped up, costs ten times more (or is unrecoverable). Auto-renew is cheap insurance.
Subdomains used where subfolders would have been better. SEO equity gets fragmented across hostnames. The case for a subdomain has to be made; the default is subfolder.
Parked domains with thin content "for SEO." Search engines don't reward this. They penalize doorway pages. Either redirect or leave blank.
Output format
A domain strategy document includes:
- Inventory: the spreadsheet of every domain
- Classification: the role of each
- Canonical decisions: apex vs www, locked
- Redirect map: every redirect in the portfolio
- DNS standards: the default record set
- Registrar standards: locked, 2FA, auto-renew
- Monitoring: what's watched, where alerts go
- Renewal calendar: the next 12 months
- Review cadence: when this gets revisited
Reference files
references/dns-record-reference.md: Common DNS records explained, with the syntax for the most useful ones (A, AAAA, CNAME, MX, TXT, CAA, SRV, etc.) and when each is needed.
GitHub 저장소
연관 스킬
monitoring-and-alerting
기타이 스킬은 개발자가 모니터링 시스템을 설계하고 구현하는 데 도움을 주며, SLO 정의, 가동 시간 확인, 오류 추적을 다룹니다. 실행 가능한 알림 구성, 당직 순번 설정, 알림 피로도 해결 방법을 안내합니다. 가시성 확보를 시작할 때나 사고 발생으로 모니터링 공백이 드러났을 때 사용하세요.
security-baseline
기타보안-베이스라인 스킬은 개발자가 필수 웹 보안 구성을 수립하고 감사하는 데 도움을 줍니다. HTTPS/TLS 설정, 보안 헤더, CSP, 비밀 관리, 출시 전 강화에 대한 지침을 제공합니다. 컴플라이언스 검토, 취약점 평가, 정기적인 보안 감사에 활용하세요.
after-action-report
기타이 스킬은 사고, 출시 또는 프로젝트에 대해 구조화된 사후 검토를 실행하여 타임라인, 근본 원인 및 교훈을 포착합니다. '사후 분석', '회고' 또는 '근본 원인 분석(RCA)'과 같은 용어에 반응하며, 기능 출시나 사고 해결 후에 사용하기에 이상적입니다. 이 과정은 단순한 문서화가 아닌 실행 가능한 개선 방안 도출에 중점을 둡니다.
launch-runbook
기타이 스킬은 개발자들이 웹사이트나 제품을 위한 구조적인 출시 계획을 수립하고 실행하는 데 도움을 줍니다. 출시 전 점검, DNS 전환, 모니터링, 롤백 절차를 포함한 전체 가동 시퀀스를 다룹니다. 출시일 활동을 조율하고 배포 체크리스트를 구축하는 데 활용하세요.
