Delegate an event subdomain to another DNS provider: a handoff checklist

Decide whether the service needs a child zone

Download the editable subdomain handoff card (Markdown, English)

A normal A, AAAA or CNAME record in the existing parent zone is often enough when a provider only needs one hostname to resolve to its service. Delegation is useful when another operator must manage a whole subtree, including different record types or nested names. Ask for the provider’s exact DNS requirements before creating a child zone. Do not treat a request for a verification TXT record or a CNAME as a request for NS delegation.[1][2]

AWS describes both arrangements: records for a subdomain can live in the parent zone, or a separate hosted zone can answer for the child. Cloudflare describes NS delegation for a separately managed subdomain and notes that its own child-zone setup has product and plan constraints. If Cloudflare is involved, check the current setup and account eligibility rather than assuming any Cloudflare zone can be delegated in the same way.[1][3]

Name the parent and child operators before any edit

Write the exact registered parent domain, exact child-zone name, parent authoritative DNS host, child DNS provider and the people allowed to change each one. The parent owner controls the NS record at the delegation point. The child operator controls the answers beneath it. A registrar change for the registered domain is a separate operation; do not alter registrar nameservers when the task is only to delegate tickets.example.org.[1]

List the event page, ticket purchase route, registration confirmation, email, certificate validation and provider verification that depend on the child name. Confirm whether the child provider needs public DNS or a private zone; a private hosted zone does not by itself create public delegation. Put a named organizer in charge of approving visitor impact and a technical owner in charge of proving the answer from each authority.[1]

Stage records in the child zone before the parent points to it

Create the child zone by following the child provider’s current guide. Copy its actual authoritative nameserver set into the handoff card; never paste example nameservers from an article. Inventory every record at and below the proposed cut point. Put required web, TXT, MX or other service records in the child zone and query its authoritative nameservers directly before changing the parent. Record the answers and UTC time.[1]

AWS warns that overlapping parent and child data during transition can produce inconsistent answers because resolvers may have different name-server information cached. Plan exactly which old parent records will be retired and when; do not delete a working record before the child can answer it. If DNSSEC is active, have the DNS operators review the child-zone signing and parent DS treatment under their supported procedure. Do not improvise a DS value or assume DNSSEC crosses the new boundary automatically.[1][3]

Publish the delegation and check the authority path

Once the child is ready and the change is approved, the parent-zone operator publishes an NS record for the exact child-zone name using the nameservers supplied by the child provider. Check the parent’s authoritative answer for that NS set, then ask the child’s authoritative servers for the service records. Compare independent recursive-resolver answers as caches update. A public lookup showing the right NS set is useful evidence, but it is not proof that the event flow works.[1]

Test the actual event page, ticket or registration link, any confirmation route and any email use on the delegated name. Check certificate and provider-verification state in the service’s own dashboard. Record time-stamped results and the observer’s location or resolver. Avoid a fixed “propagation complete after X minutes” promise; cached records, TTLs and provider operations differ. If visitors receive conflicting answers, pause dependent changes and follow the reviewed reversal or escalation decision.[1]

Keep a reversible handoff and a maintenance owner

The reversal plan needs the parent-zone editor, the previous record set and a decision owner. Restoring parent records requires checking what the child answered and what visitors may still have cached. Do not close the old child zone or remove its records while resolvers may still use its NS set. Once the change is stable, remove obsolete duplicate records from the parent according to the provider plan and archive the before-and-after evidence.[1]

Record who maintains the child zone, handles future TXT or certificate requests, pays for the provider, rotates access and closes delegation when the event or contract ends. A delegated subdomain can become a forgotten dependency after an event season. Add it to the domain inventory with a next review date. If the child provider is retiring, plan the return of authority as a new DNS change, with its own preflight and visitor-task checks.[1]

Use the editable handoff card

The downloadable card separates the decision, dependent records, parent and child owners, preflight, observed results and handback. Fill one card per child zone and store it with the event’s DNS change approvals. It is a coordination record, not a universal command sequence. Keep credentials, API tokens, transfer codes and private keys out of it.[1]

If your event pages or links are managed through Boletolibre.com, include the exact public hostnames and attendee tasks in the dependency list. Use the DNS instructions actually provided for those hosts; this guide does not assume Boletolibre operates your registrar or authoritative DNS.[1]