breachme.ai: fix syncPubKeyDomain prefix (Cloudflare verifier returns 502)

[Gilayos]

Summary

Move the domainconnect. prefix out of syncPubKeyDomain and into the apply URL's key parameter. Originally submitted in #1011; the prefix-in-template version was a misconfiguration on my side that surfaced once Cloudflare started actually verifying signatures against our key.

Problem

Cloudflare's Domain Connect verifier (the dashboard at dash.cloudflare.com/domainconnect/...) constructs the public-key TXT lookup target as <key>.<syncPubKeyDomain>. With the previous template:

	Value
syncPubKeyDomain	domainconnect.breachme.ai
URL key=	domainconnect
Cloudflare's lookup target	domainconnect.domainconnect.breachme.ai ❌
Where the TXT actually lives	domainconnect.breachme.ai

The doubled domainconnect. prefix → NXDOMAIN → upstream verify service throws → 502 Bad Gateway from /dns/domainconnect/v2/verify → the dash JS shows the generic "Cloudflare cannot proceed with applying new DNS records for BreachMe because this URL is not verified" error to users.

Smoking gun from a HAR captured 2026-05-03:

POST https://dash.cloudflare.com/dns/domainconnect/v2/verify
{
  "domain": "domainconnect.domainconnect.breachme.ai",
  "sig":    "<our base64url signature>",
  "hash":   "domain=…&verification=…&redirect_uri=…"
}
→ 502 Bad Gateway

Fix

Change syncPubKeyDomain from "domainconnect.breachme.ai" to "breachme.ai". The apply URL keeps key=domainconnect, so Cloudflare constructs domainconnect.breachme.ai — exactly where the TXT record lives.

The TXT record at domainconnect.breachme.ai is unchanged; only the template metadata moves.

Verification

• TXT at domainconnect.breachme.ai still resolves to two correctly-chunked p=1,a=RS256,d=… / p=2,a=RS256,d=… records.
• Local openssl dgst -sha256 -verify against the reassembled key still returns Verified OK for our signed payloads.
• After this template change merges and the CDN cache picks it up, Cloudflare's lookup target should land on the right host.

Notes for reviewers

• providerId and serviceId are unchanged — same template identity.
• Logo / records / agreements / hostRequired all unchanged.
• Our (BreachMe-side) signing code is being updated in lockstep to send key=domainconnect once this template is live.

cc @kerolasa — happy to provide the full HAR off-issue if helpful for tracing your verifier's behaviour. The 502 response (vs a clearer 4xx with "key configuration mismatch") made this a tough one to diagnose without the network capture.

🤖 Generated with Claude Code

[github-actions]

✅ JSON Filename Check Passed

[github-actions]

✅ JSON Schema Validation Passed

[github-actions]

Linter OK

breachme.ai.domain-verification.json

Level	Code	Note
info	DCTL1021	missing from iana definitions

[github-actions]

PR Description Check Failed

The PR description is missing required elements. Please update it according to the PR template.

Details

Labels to add: Checklist of common problems not complete, PR description incomplete, Test links missing
Labels to remove: Forged editor links

PR description check FAILED:
  FAIL  'Type of change' section not found
  FAIL  'How Has This Been Tested?' section not found
  FAIL  'Checklist of common problems' section not found
  FAIL  'Online Editor test results' section not found
  FAIL  Template coverage: breachme.ai.domain-verification.json: no editor test link found (expected template id 'breachme.ai.domain-verification')

[Gilayos]

Closing — re-read Cloudflare's Domain Connect docs more carefully and the template doesn't actually need to change.

The doubled-prefix in the HAR (domainconnect.domainconnect.breachme.ai) wasn't caused by syncPubKeyDomain being wrong — it was caused by us sending key=domainconnect (a relative prefix). Cloudflare's docs explicitly say:

"Key: Required. … the hostname of the TXT record must be appended as another variable on the query string of the form."

i.e. key= should be the full hostname of the TXT record (domainconnect.breachme.ai), not a relative prefix. With the right key value, Cloudflare looks up the TXT directly at key, and syncPubKeyDomain acts as the security boundary (validating that key is within it). The current syncPubKeyDomain="domainconnect.breachme.ai" is fine.

Confirmed by running dc-template-linter -cloudflare against the template — exit 0, no errors (only an info-level note about _breachme not being in IANA's underscore-host registry, which is expected for custom service names).

Server-side fix shipped: KEY_HOST is now the full hostname, and sig is correctly the last query parameter (was previously after key, also against the docs). Apologies for the noise on this PR.

@kerolasa — thanks for your patience while we worked through this. If the apply URLs still fail after the new code is live, I'll capture another HAR.