co-op/runbooks
2
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

dns change sheet: rebuild from the registrar's panel

Browse Source 
The previous sheet's record counts could not be reproduced and at least two listed records did not exist, so it was replaced rather than corrected. Rebuilt from a screenshot of the domains.coop panel: 11 records total, of which two are wildcards carrying both A and AAAA. That is the item the old sheet omitted, and it is the one that matters most — every application hostname (chat, portal, panel, dashboard, newsletter, gateway, vault, git, registry, files, forum, email, docs, my, status) resolves ONLY via the wildcard and is not an individual record. A cutover that moves the apex but not the wildcards leaves all of them behind.

Also recorded: the second DKIM selector (UUID-named, 2048-bit) that is almost certainly Scaleway TEM's, and which explains why probing plausible selector names never found it; the absence of any CNAME, CAA, SRV or ACME records; an unexplained server.inference.coop A record that must be identified before it is moved; and the pre-window TTL reduction.

Known gap: row 11's full name and value are truncated in the panel screenshot and must be read in the panel before that row is edited.
This commit is contained in:
inference-bot committed 2026-11-01 23:49:45 +00:00
1 parent 049d8c59ad
commit 48c4827957
1 file changed
+71 -88
Download Patch File Download Diff File Expand all files Collapse all files
dns-change-sheet.md
+71 -88
View File
@@ -1,102 +1,85 @@
# DNS change sheet — Cloudron migration (Hostinger → Infomaniak)
# DNS change sheet — inference.coop
Prepared 2026-10-30 from a live zone inventory (`zone_inventory.json`, 41 records).
Registrar: **yoursrs.com** (NS for domains.coop). Cloudron cannot manage these records;
every change below is manual. **Nothing here is time-sensitive except the TTL lowering.**
**Rebuilt 2026-11-01 from the registrar's own panel** (domains.coop; nameservers `ns1/ns2.yoursrs.com`).
The previous version listed record counts that could not be reproduced and at least two records that did
not exist, so it is replaced rather than edited.
## Counts, so the switch is not underestimated
## Why the panel was the only source
- **19 A records** → `179.199.135.72`
- **18 AAAA records** → `2a02:4780:6e:83fd::1` (Hostinger's range)
- 1 MX, 1 SPF TXT, 1 DKIM TXT, 1 DMARC TXT
- **No CAA records**, so no certificate-authority restriction to update.
- **The zone is wildcarded.** A nonsense name (`definitely-not-a-real-host-xyz`.
`inference.coop`) resolves to the same A/AAAA as `inference.coop` itself, so *any* name
answers. Two consequences: (a) a name that resolves is **not** evidence that a record
exists — `docs.inference.coop` was listed in this sheet on exactly that mistake, and does
not exist; (b) **DNS cannot verify the cutover per-name.** Check the registrar's record
list against this sheet rather than resolving hostnames. If the wildcard is a real edge
record, it must be repointed at cutover too, or every name relying on it stays on the old
box while the named records move.
- **Configured TTL is 3600 s on every record.** (Lower these a day early; the 1090–1204 s
seen on some answers are cache countdowns, not zone values.)
- **AXFR is refused**, so the zone cannot be pulled.
- **The zone is wildcarded.** A made-up hostname (`zz-random-check-9f2.inference.coop`) returns the old
box's address. So a name that *resolves* proves nothing about whether a record exists, and any hostname
absent from the list below is served by the wildcard.
- Only 11 records exist. Everything else is `*`.
## Records to change at cutover
## The complete inventory (11 records)
| Name | Type | Current | Set to |
|---|---|---|---|
| `chat-legacy.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `chat.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `cloud.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `dashboard.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `email.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `forum.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `gateway.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `git.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `matrix.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `my.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `newsletter.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `panel.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `portal.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `search.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `status.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `vault.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `www.inference.coop` | A | `179.199.135.72` | `179.237.86.116` |
| `chat-legacy.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `chat.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `cloud.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `dashboard.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `email.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `forum.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `gateway.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `git.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `matrix.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `my.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `newsletter.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `panel.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `portal.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `search.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `status.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| `vault.inference.coop` | AAAA | `2a02:4780:6e:83fd::1` | `2001:1600:18:206::89` |
| # | Type | Hostname | Value | TTL | Moves? |
|---|------|----------|-------|-----|--------|
| 1 | A | `inference.coop` | `179.199.135.72` | 3600 | **YES** → new box |
| 2 | AAAA | `inference.coop` | `2a02:4780:6e:83fd::1` | 3600 | **YES** → new box |
| 3 | A | `*` | `179.199.135.72` | 3600 | **YES** → new box |
| 4 | AAAA | `*` | `2a02:4780:6e:83fd::1` | 3600 | **YES** → new box |
| 5 | A | `server` | `179.199.135.72` | 3600 | **CHECK FIRST** — nothing else references it |
| 6 | A | `www` | `179.199.135.72` | 3600 | **YES** → new box |
| 7 | MX (pri 10) | `inference.coop` | `my.inference.coop` | 3600 | stays (follows record 1/2) |
| 8 | TXT | `inference.coop` | `v=spf1 a:my.inference.coop include:_spf.tem.scaleway.com ~all` | 3600 | stays |
| 9 | TXT | `_dmarc` | `v=DMARC1; p=reject; pct=100` | 3600 | stays |
| 10 | TXT | `cloudron._domainkey` | `v=DKIM1; t=s; p=MIGfMA0GCSqGSIb3…` (1024-bit; full value recovered 2026-11-01 and restored) | 3600 | stays |
| 11 | TXT | `ede94f37-204c-41ee-b3…` | `v=DKIM1; h=sha256; k=rsa; p=MIIBIjA…` (2048-bit) | 3600 | stays |
| 12 | TXT | `_atproto` | `did=did:plc:4leras5objxiqtnbjzoholds` | 3600 | stays |
`www` has no app behind it in the Cloudron inventory — confirm whether it is an alias,
a redirect, or stale before touching it.
(The table shows 12 rows because `www` was added as a separate item; rows 1–11 are the panel's 11.
Reconcile the numbering against the panel when editing.)
## Records that must NOT change, but must be re-verified after the restore
## The four records that matter at cutover
| Name | Type | Value | Why |
|---|---|---|---|
| `inference.coop` | MX | `10 my.inference.coop.` | Follows the A record; no MX edit needed. |
| `inference.coop` | TXT (SPF) | `v=spf1 a:my.inference.coop ~all` | Hostname-based — survives the IP change. |
| `cloudron._domainkey` | TXT (DKIM) | `v=DKIM1; t=s; p=MIGfMA0…` | **Must match the key inside the restored mail app's data.** Mismatch + DMARC below = silently discarded mail. |
| `_dmarc` | TXT | `v=DMARC1; p=reject; pct=100` | Reject policy: misaligned mail is DISCARDED, not junked. |
**Records 1–4 and 6**: apex A, apex AAAA, wildcard A, wildcard AAAA, and `www`. Change these and the site
moves. Nothing else in the zone needs touching for the migration.
## Sequence (see the main runbook §4)
**The wildcards are the item the old sheet omitted entirely.** Because `*` carries both A and AAAA records,
every hostname not listed above — `chat`, `portal`, `panel`, `dashboard`, `newsletter`, `gateway`,
`vault`, `git`, `registry`, `files`, `forum`, `email`, `docs`, `my`, `status` — resolves *only* via the
wildcard. They are not individual records and must not be created as such; they move when the wildcards
move. A partial cutover that changes the apex but not `*` leaves every application on the old box.
1. A day early: set every A and AAAA TTL to 300 s.
2. At cutover: point A records at **`179.237.86.116`**; repoint every AAAA record to **`2001:1600:18:206::89`**
(the new box has IPv6, so this is a repoint, not a delete — but it must happen in
the same pass: an IPv6-capable client or homeserver left on Hostinger's address
reaches the old box even after the A switch).
3. Verify with the resolver set below, not one resolver.
## Two DKIM selectors, for different senders
- **`cloudron._domainkey`** — the box's own mail signing (1024-bit). Used by the portal and by Listmonk,
both of which relay through the Cloudron mail app.
- **`ede94f37-…`** — a UUID-named selector with a 2048-bit key. UUID selectors are what a service
generates for itself, and this is almost certainly **Scaleway Transactional Email's**. Scaleway's own
domain verification passed, which is the authority on whether it is right.
*Name and value for row 11 are truncated in the panel screenshot. Read the full name in the panel (or
from Scaleway's domain-verification page) before editing that row.*
## What the zone does NOT contain
No CNAME, no CAA, no SRV, no `_acme-challenge` entries. If any of those are ever needed, they are new
records, not moves. (`docs.inference.coop` has no record of its own — it is served by the wildcard, which
is why it answers with the Cloudron dashboard.)
## Before the window
1. **Lower the TTL on records 1–4 and 6 from 3600 to ~300.** At 3600 a mistake takes an hour to correct;
at 300 it takes five minutes. Do this a day ahead so the old TTL expires, then restore it afterwards.
2. **Establish what `server.inference.coop` is used for.** Nothing in the co-op's documented set refers to
it, and it is not covered by the wildcard. Do not move or delete it until that is known.
3. **Confirm the full name of record 11** (above).
## Verification after the move
Query the **authoritative** nameservers, not a resolver, and query the specific name — a wildcard answer
cannot be distinguished from a real record otherwise:
```
for h in inference.coop my.inference.coop matrix.inference.coop gateway.inference.coop; do
dig +short A $h @1.1.1.1; dig +short A $h @8.8.8.8; dig +short AAAA $h @1.1.1.1
done
dig +short A inference.coop @ns1.yoursrs.com
dig +short AAAA inference.coop @ns1.yoursrs.com
dig +short A zz-random-check-9f2.inference.coop @ns1.yoursrs.com # wildcard, must now be the NEW box
dig +short MX inference.coop @ns1.yoursrs.com
```
## The new box (given 2026-10-30)
- **IPv4** `179.237.86.116` · **IPv6** `2001:1600:18:206::89`
- 4 CPU · 12 GB RAM · **250 GB disk** · unlimited traffic
- **1 snapshot slot free** — take a snapshot *after* a clean restore and *before* the DNS
switch, so a bad restore is a revert rather than a rebuild.
- Location Plan-les-Ouates, Switzerland (same provider as the backup target, so the
restore reads from inside Infomaniak's network).
- Ubuntu **26.04 LTS** — confirm Cloudron 9.x supports it before installing.
- **Reverse DNS is listed as "configure" for BOTH addresses.** Set PTR → `my.inference.coop`
on the IPv4 *and* the IPv6. A sending IP without matching PTR is the classic cause of
fresh-IP mail landing in spam, and DMARC here is `p=reject` on our own domain.
Then `verify-restore.py`. Its two known blind spots (the `data` group crashing on a missing PATH, and the
mail check asserting a port-25 state it cannot observe from the agent host) are still unfixed — fix them
before relying on a clean run.