Misconfigured DNS is one of the top launch-day failure modes for vibe-coded projects. A custom domain referenced in code but not pointed at the hosting provider produces broken canonical URLs, OAuth callback mismatches (login stops working), and email links that resolve to nothing. Under ISO 25010:2011 reliability.availability, this is a hard availability failure: the app is deployed but unreachable at its intended address. Because DNS propagation takes up to 48 hours, discovering this on launch day means a day of downtime.
High because an unconfigured custom domain makes the production app unreachable and breaks every integration that depends on the canonical URL, from OAuth redirects to email links.
Add your domain in the hosting platform dashboard first, then set the corresponding record at your registrar. For Vercel, the CNAME target is cname.vercel-dns.com; the A record target is 76.76.21.21.
// vercel.json
{ "domains": ["yourdomain.com", "www.yourdomain.com"] }
Verify propagation with dig yourdomain.com +short or whatsmydns.net before announcing launch. DNS changes require up to 48 hours to propagate globally — do not leave this for launch day.
ID: pre-launch.infrastructure.dns-configured
Severity: high
What to look for: Count all DNS-related configuration files and domain references. Enumerate whether A/CNAME records point to the production hosting provider. Check deployment config for custom domain settings. Look for domain configuration in vercel.json, netlify.toml, or hosting platform config files. Check for CNAME, A record, or DNS verification patterns in deployment scripts or README. Look for custom domain references in the project (not just localhost or platform subdomains).
Pass criteria: A custom domain is referenced in deployment configuration or documentation, indicating intentional DNS setup. Alternatively, the project is clearly intended to run on a platform subdomain (e.g., yourapp.vercel.app) with no custom domain expectation. At least 1 DNS record must point to the production hosting provider.
Fail criteria: Deployment configuration references a custom domain but no DNS configuration evidence is present, suggesting DNS setup may be incomplete. If a custom domain is referenced in the codebase as the intended production URL (e.g., in environment variables, constants, metadata configuration, or next.config.ts) but is NOT configured in the deployment platform (Vercel, Netlify, etc.), this is a FAIL with detail explaining that the domain is referenced in code but not yet configured for deployment. An intended-but-unconfigured domain will cause production failures (broken canonical URLs, OAuth callback mismatches, email links pointing nowhere).
Skip (N/A) when: Never — every project going live has a domain, whether custom or platform-assigned.
Cross-reference: For SSL/TLS validity on the configured domain, see ssl-valid. For www redirect, see www-redirect.
Detail on fail: "Custom domain referenced in deployment config but no DNS configuration evidence found — verify A/CNAME records are set at your registrar"
Remediation: DNS misconfiguration is one of the most common launch-day failures. Verify your records are set before launch day:
// vercel.json — domain configuration
{ "domains": ["yourdomain.com", "www.yourdomain.com"] }
cname.vercel-dns.com, or use A records pointing to 76.76.21.21.dig yourdomain.com or a tool like whatsmydns.net to verify propagation before announcing launch.After propagation, verify your site loads at the custom domain before going live.