Registrar un dominio propio

Escritura · requiere el permiso accounts:write.

StoreCustomDomainRequest already sanitized hostname and validated shape + uniqueness (422, no Cloudflare call) before this method runs. Cloudflare is called next; on failure NOTHING is persisted locally (spec scenario "Cloudflare API failure on creation").

Requests HTTP DCV by default (design.md D9 — supersedes the original TXT-only MVP default): CloudflareCustomHostnameClient::create() defaults to SslValidationMethod::Http, so no explicit method is passed here. With HTTP DCV the certificate is issued once the CNAME resolves, so ssl_validation_string (TXT-specific) is expected to stay null for new domains — DnsRecordBuilder renders a single routing record (no TXT) accordingly. A domain can later fall back to TXT via switchValidationMethod().

Also autodetects the DNS provider from the hostname's nameservers (design.md D14-D17, Increment 6) and persists it as detected_provider — a best-effort UX hint, never blocking creation. null when detection fails or the domain was just registered and its NS do not resolve yet (the "sticky" re-detection on verify() covers that case).

Since Increment 9 (design.md Addendum 5 D32/D34), a Custom Hostname alone gets a certificate but routes no traffic — a Worker Route ({hostname}/* -> the custom-hostnames Worker) is required for the domain to actually work. It is created right after the Custom Hostname, using the script name from config('services.cloudflare.worker_script') (D36), and its id is persisted as cloudflare_route_id (internal bookkeeping only — never exposed via CustomDomainResource). If the Custom Hostname succeeds but the Worker Route fails, the just-created Custom Hostname is rolled back (best-effort delete, logged on failure) and NOTHING is persisted locally — a domain with a hostname but no route would be a silently dead domain (SSL may go ACTIVE but no traffic ever reaches the resolver), which is worse than failing the request outright.