# Event subdomain audit and retirement worksheet

Copy one row per hostname. This is an operations register, not a penetration-test plan. Do not put passwords, tokens, attendee data or private vendor contacts in a shared copy.

**Domain / event edition:** ______  **DNS account and zone owner:** ______  **Audit date:** ______  **Approver:** ______

| Hostname | DNS type and target | Source / observed date | Current service and account | Business owner | Technical owner | Active dependencies (links, email, callbacks, login) | Observed DNS / HTTPS result | Decision: keep, investigate, redirect, replace, retire | Change approval / date | Follow-up verification / date |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| tickets.example.org | CNAME → [target] | Zone export / [date] | Ticket provider / [account ID] | [name] | [name] | [checkout, confirmation links] | [answer and page] | [decision] | [approver] | [result] |
| [hostname] | [record and target] | [source and date] | [service and account] | [name] | [name] | [links and integrations] | [observed result] | [decision] | [approver and date] | [result and date] |

## Inventory pass

- [ ] Export every authoritative DNS zone for each event domain.
- [ ] Identify child zones delegated with NS records and request their separate inventories.
- [ ] Compare provider accounts, hosting/CDN apps, infrastructure code, ticketing, mail and analytics settings.
- [ ] Check certificates, old event plans and published links for candidate names. Mark historical findings as unconfirmed until checked.
- [ ] Give each name a business owner, a technical owner and a next review date.

## Decision pass for each candidate

1. What attendee or staff journey uses the name today or at the next edition?
2. Who controls the actual resource to which DNS points? Record provider and resource ID, not a credential.
3. Does this name support mail, delegation, webhooks, authentication or a printed QR/link even if the website is blank?
4. Is the observed response expected? Capture date, resolver/region where relevant, and the HTTPS destination.
5. Who approves a keep, redirect, replacement or retirement? Who can reverse the change?

An HTTP error or unresolved target deserves investigation. It is not proof by itself that someone can claim the subdomain. Escalate suspected dangling records to the domain/security owner; do not try to claim a third-party resource as a test.

## Planned retirement record

**Hostname:** ______  **Replacement or redirect:** ______  **Dependencies checked:** ______

**Change owner / approver:** ______  **Change window:** ______  **Rollback contact:** ______

- [ ] Update or remove DNS before deleting the vendor resource, coordinated with the service owner.
- [ ] Verify public links, ticket emails, callbacks, mail and login settings after the change.
- [ ] Confirm the old hostname resolves or redirects only as intended from relevant networks.
- [ ] Record the observed result and close the old provider account/resource only when dependencies are satisfied.
- [ ] Update inventory and set a review date for any temporary redirect.

If unexpected content or an apparent takeover is already present, use the incident-response process instead of the planned retirement steps.

Sources: [OWASP Subdomain Takeover Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html) and [Cloudflare subdomain delegation documentation](https://developers.cloudflare.com/dns/zone-setups/subdomain-setup/setup/).