Target ownership (DNS challenge)
Before any non-sandbox simulation runs, DoesItDefend requires technical proof that the caller controls the target hostname. The proof is a DNS TXT challenge at `_doesitdefend.<hostname>` containing a per-tenant verification token. This is the CFAA / Marco Civil da Internet / Computer Misuse Act layer — without it, an attacker with a valid API key could weaponise the platform against arbitrary targets.
Key points
- Tokens are scoped to (tenant, hostname) and rotate every 7 days for pending verifications, every 365 days for verified ones.
- Verification is technical, not declarative — we resolve the TXT record live; a declaration without a matching record never grants access.
- Sandbox targets (Juice Shop, VulnBot) bypass the challenge — they are infrastructure we host for our own demo and never reach customer endpoints.
- Verified records auto-revoke on DNS-resolution failure during weekly background re-checks (the target-ownership-sweeper Cloud Run Job).
01
Setup (one time per hostname)
- In /settings/targets, add the hostname. The UI shows the TXT record to add (host = _doesitdefend.<hostname>, value = did-verify=<48-char token>).
- Add the record to your DNS provider. Propagation usually completes within minutes.
- Click Verify. The platform resolves the TXT record and flips the row from pending to verified.
02
Operational guarantees
- REQUIRE_TARGET_OWNERSHIP=true on prod / staging — POST /v1/runs returns 403 target_ownership_required for any unverified non-sandbox host.
- Audit log entry on every verify_requested / verified / verify_failed / revoked event, linked to the actor (user_id or system).
- Revoke flow in /settings/targets — useful when a customer transfers the domain or rotates DNS.