Target ownership via DNS
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.
Before any non-sandbox simulation runs, the platform requires technical proof that you control the target hostname: a DNS TXT record at _doesitdefend.<hostname> containing a per-tenant verification token. Ownership is proven before the first request is sent.
This is the authorization layer that keeps offensive testing consensual — the same class of control the CFAA and Marco Civil frameworks expect from authorized research.
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).
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.
Setup happens once per hostname in /settings/targets: the UI shows the exact record, you add it at your DNS provider, and verification resolves the TXT record and flips the row to verified. Propagation is usually a matter of minutes.
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.
Enforcement is server-side, not advisory: with REQUIRE_TARGET_OWNERSHIP enabled in production and staging, run creation against an unverified host fails with 403 target_ownership. Every verify and revoke event lands in the audit log, and revocation is available when a domain changes hands.
Related resources