Pārvietot domēna DNS uz Brain Club vārdserveriem

Kad izmantot

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.

Pirms sāc

• 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.

Ko izpilde pieprasa1

Ceļš9 soļi

1. S1

   Export the current zoneaģents

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

   Izdarīts, kad 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. S2

   Note the TTLs and the expiryaģents

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

   Izdarīts, kad 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. S3

   Rebuild the zone in Brain Clubaģents

   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.

   Izdarīts, kad 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. S4

   Verify parity, especially mailaģents

   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.

   Izdarīts, kad every mailbox on the domain has a home and every mail record matches, or a missing item is listed for the owner.

5. S5

   Approve the cut-overīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S5 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

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

   Izdarīts, kad the owner has named the moment and accepted the diff.

6. S6

   Switch the delegationaģents

   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).

   Izdarīts, kad 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. S7

   Verify from outsideaģents

   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.

   Izdarīts, kad every answer matches the new zone on every nameserver and the test mail arrives.

8. S8

   Watch, then decommission the old zoneaģents

   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.

   Izdarīts, kad the old provider shows no zone for the domain and S7 checks still pass a day later.

9. S9

   Record and hand backaģents

   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.

   Izdarīts, kad 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.

Pārbaudes — kā zinām, ka izdevās

• 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.

Ja noiet greizi

Ko atstāj katrs solis

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.

Ko saglabāt

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.

Kā šī procedūra uzlabojas

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.