Izveidot kontuCreate account
‹ All playbooks
Move a domain's DNS onto Brain Club nameservers

tech.move-domain-to-bc·version 1.0.0·draft

Move a domain's DNS onto Brain Club nameservers

The domain keeps resolving without interruption while its zone and nameservers move to Brain Club, and the renewal watch covers it.

KasparsInfrastructure Engineerruns itProfile ›
Whenon request — owner or employee asks to move a domain the company holds elsewhere onto Brain Club
Who actsthe agent acts after approval
Time30 min active; 24–48 h until the old delegation is fully out of caches
Countryany country
Sign in to run thisThis playbook opens inside Brain Club. Sign in to read and run it.

When to use

The company already holds the domain and wants Brain Club to serve its DNS. Not for a domain the company does not hold yet — use tech.register-domain. Not for a mailbox alone (tech.create-mailbox adds records in an existing zone). If the domain only needs a renewal reminder, not a move, use tech.renew-domain.

Before you start

  • Know the current DNS provider and confirm you can list every record type it serves (A, AAAA, CNAME, MX, TXT, SRV, CAA, NS below the zone).
  • Confirm the registrar lets you change nameservers (some free/cheap hosts lock delegation to their own).
  • Decide the cut-over window: a quiet hour, not Friday afternoon. Mail domains move before a weekend, never into one.

What a run requires1

  • Approval · S5 · ownerthe run stops until a named person records the decision

Any step can wait until a date and reopens by itself; every closed step leaves evidence (a note, a link, a number).

The trail9 steps

  1. Export the current zoneagent

    List every record from the current provider, including TTLs, and save the export.

    Done when a complete record list exists as a file, and the person who knows the domain confirms nothing is missing (webmail, newsletter SPF, _dmarc, CAA).

  2. Note the TTLs and the expiryagent

    Read the current TTL on the NS/A/MX records and the domain's expiry date and auto-renew state at the registrar.

    Done when the move plan states the TTL to wait out and whether renewal is due within 30 days.

    ⛔ If renewal is due within 30 days, renew first at the current registrar — moving a domain mid-expiry risks losing it.

  3. Rebuild the zone in Brain Clubagent

    Create the zone in the DNS module with every record from S1, then bc domains onboard <domain> --tenant <slug> (dry run) → read the plan → --apply.

    Done when all three Brain Club nameservers answer the SOA and the full record set, and a record-by-record diff against the S1 export is empty.

  4. Verify parity, especially mailagent

    bc mail search for the domain's addresses to confirm the mailboxes Brain Club will serve exist; compare MX, SPF, DKIM and DMARC values against the export.

    Done when every mailbox on the domain has a home and every mail record matches, or a missing item is listed for the owner.

  5. Approve the cut-overownerneeds approval · owner

    Approval · S5 · owner — the run stops until a named person records the decision

    Present: the record diff (must be empty or explained), the TTL to wait out, the cut-over moment.

    Done when the owner has named the moment and accepted the diff.

  6. Switch the delegationagent

    At the registrar, point the domain at ns1.brainclub.com, ns2.brainclub.com, ns3.brainclub.com (.lv: bc-niclv set-ns <domain> --to … — it preflights every nameserver and refuses on disagreement).

    Done when the parent servers list the Brain Club nameservers.

    ⛔ Never delete the old zone at this point — it must keep answering until old TTLs expire.

  7. Verify from outsideagent

    bc-niclv verify (.lv), plus resolution from at least two public resolvers: NS, SOA, and every record that matters (A, MX, TXT). Send a test mail to and from the domain if it serves mail.

    Done when every answer matches the new zone on every nameserver and the test mail arrives.

  8. Watch, then decommission the old zoneagent

    Keep the old zone serving unchanged for at least the longest TTL from S2 (24 h is a safe default). Then delete it at the old provider so there is one source of truth.

    Done when the old provider shows no zone for the domain and S7 checks still pass a day later.

  9. Record and hand backagent

    Update the domain list with expiry and auto-renew state (bc tasks add a renewal task if auto-renew is off), link the move to the goal it serves, and send the owner a three-line summary: old provider gone, new nameservers live, mail verified.

    Done when the domain list carries expiry and auto-renew state with a renewal task if needed, the move is linked to its goal, and the owner has the three-line summary.

Checks — how we know it worked

  • All three Brain Club nameservers answer the same records (asking whether they answer is not enough).
  • A record-by-record diff between the S1 export and the live zone is empty.
  • Registrar still shows the company as holder — the move changed delegation, not ownership.
  • Expiry date is in the domain list; auto-renew state is known and recorded.
  • A test mail to and from the domain arrived after S8.

If it goes wrong

SymptomResponse
Domain resolves for nobody right after S6The zone was not fully served before delegation — re-run bc domains onboard --apply, wait out the parent TTL (1800 s for .lv), re-verify.
Mail stops arriving after the moveAn MX or SPF record was missed in S1 — restore it from the export in the DNS module; the old zone may still be deleted, fix forward.
Old provider refuses to release delegationConfirm the registrar login holder matches the company; if the registrar is the old host, plan a registrar transfer instead and record the blocker.
Some resolvers still return old answersStale TTL, not an error — confirm the old zone still serves identical data, wait it out; escalate only if it exceeds 48 h.
Domain expires during the moveRenew immediately at the current registrar (S2 should have caught this); then continue from S6.

What each step leaves behind

  1. S1a complete record list exists as a file, and the person who knows the domain confirms nothing is missing (webmail, newsletter SPF, _dmarc, CAA).
  2. S2the move plan states the TTL to wait out and whether renewal is due within 30 days.
  3. S3all three Brain Club nameservers answer the SOA and the full record set, and a record-by-record diff against the S1 export is empty.
  4. S4every mailbox on the domain has a home and every mail record matches, or a missing item is listed for the owner.
  5. S5the owner has named the moment and accepted the diff.
  6. S6the parent servers list the Brain Club nameservers.
  7. S7every answer matches the new zone on every nameserver and the test mail arrives.
  8. S8the old provider shows no zone for the domain and S7 checks still pass a day later.
  9. S9the domain list carries expiry and auto-renew state with a renewal task if needed, the move is linked to its goal, and the owner has the three-line summary.

Evidence to keep

The S1 zone export · the record diff at S5 · the owner's cut-over approval (who, when) · bc-niclv set-ns output · S7 resolver answers and test-mail timestamps with time · the date the old zone was deleted · registrar expiry date and auto-renew state.

How this playbook improves

After every 10 runs ask: was any record missed in S1, and which type (mail TXT records are the usual culprit)? Was there any minute of zero resolution, and at which step? Did the old zone get deleted before the TTL safely elapsed? A new version changes the step that caused the miss and says so in its change note.