# Pathrule Pattern: DNS and Domain Management (1.0.0) # ::pathrule:package:dns-domain-management ### [RULE] Production DNS records have one reviewed source of truth (path: /infra/dns) DNS changes route production traffic, mail, certificate validation, and third-party verification, so they require the same review and rollback discipline as code. Keep supported zones and records in a declarative source or controlled change system that records owner, purpose, environment, provider, record type, name, value, TTL intent, dependencies, and change history. - Restrict direct dashboard edits to documented emergency access and reconcile them back immediately. - Validate names, types, values, duplicates, conflicting records, zone boundaries, trailing-dot behavior, and environment separation before apply. - Protect apex, nameserver, mail, certificate, and ownership-verification records with appropriate review ownership. - Detect drift between declared, provider, registrar, and observed authoritative state. Verification: Make an emergency provider edit in a test zone and confirm drift detection identifies the exact record and recovery path without overwriting unrelated changes. --- ### [RULE] Cutovers are TTL-aware two-sided migrations (path: /ops/domains) TTL controls how long a resolver may cache an answer; it does not promise that every client updates at one universal moment. Plan both the DNS record change and the readiness of old and new destinations. Lower TTL sufficiently before the cutover only when faster rollback is needed, wait for prior longer caches to age, and restore the normal value after stability. - Verify the new origin, certificate, host routing, health, capacity, observability, and data compatibility before directing traffic. - Keep the old destination capable of serving mixed traffic for the documented cache and rollback window. - Change one resolution boundary at a time and record exact old and new values. - Test from multiple independent resolvers and networks while distinguishing recursive cache from authoritative state. Verification: Rehearse the change and rollback with representative cached answers; confirm both destinations remain correct during mixed resolution. --- ### [RULE] DNSSEC transitions coordinate signer and parent delegation (path: /ops/domains) DNSSEC creates a chain of trust between the parent zone and the authoritative signer. A stale or premature DS record can make otherwise present records fail validation. Treat enablement, key rotation, provider migration, multi-signer operation, algorithm change, and disablement as planned transitions across both the DNS provider and registrar or parent. - Inventory current nameservers, DNSKEY, DS, signer state, algorithms, key tags, and delegation before changing anything. - Publish and observe new signing material before making the parent require it, and remove parent trust before retiring the only matching signer. - Validate with independent DNSSEC-aware resolvers and authoritative queries at each stage. - Preserve exact rollback steps and avoid combining delegation, zone-content, and trust changes without a tested migration design. Verification: Rehearse the sequence in a delegated test zone and prove signed positive and negative answers throughout transition and rollback. --- ### [MEMORY] Registrar, registry, parent, and authoritative provider own different state (path: /ops/domains) A domain can be registered with one company, delegated by a registry or parent zone, signed through registrar-managed DS records, and served authoritatively by another DNS provider. Application hosting and certificate providers may create additional records without owning delegation. Document accounts, legal owner, renewal, lock and recovery settings, nameserver set, DS management path, authoritative zone, billing owner, and emergency access separately. Use role-based access and strong recovery controls for registrar and DNS accounts, with no shared personal ownership. Monitor expiration, nameserver and DS changes, and unauthorized zone edits. See /infra/dns for record source of truth and /tests/dns for observed-state verification. --- ### [MEMORY] DNS verification asks authoritative and recursive questions (path: /tests/dns) A provider dashboard can show the desired record while the delegated authoritative nameserver serves something else, and a recursive resolver can continue serving a valid cached answer after authoritative state changes. Verification queries the parent delegation and DS, each authoritative nameserver, several independent validating recursive resolvers, and the application path that consumes the name. Check expected record type, value, TTL, aliases, negative answers, IPv4 and IPv6, mail and certificate dependencies, and DNSSEC status. Record query time and responding server so differences are explainable. Do not declare propagation complete from one workstation cache or an online checker with unknown behavior. See /ops/domains for cutover acceptance and rollback criteria.