DNS manager¶

Publish your own hostnames against IPs Nekotopia has allocated to you. The platform auto-manages the boring stuff (ip-X-X-X-X.<region>.nekotopia.io defaults, your mesh hostname, PTR records for every allocated IP); you only see DNS Manager when you have something you can customise.

Where it lives

Sidebar: DNS manager (under Edge & DNS). Section ID: dns-manager-section. Loader: loadDnsManager().

What's auto-managed (you don't touch this)¶

The moment you're allocated a Torus mesh IP, nSolo IP, or nColo prefix, the platform writes the corresponding DNS records on your behalf:

Allocation	Auto-record
Torus mesh IP (every member)	`<username>.edge.nekotopia.io` → your mesh IP (internal, dnsmasq only)
nSolo IP (Plus + Pro)	`ip-X-X-X-X.<region>.nekotopia.io` forward A + PTR (public, Route53)
nColo prefix (Pro)	Forward A + PTR for every IP in the prefix (public, Route53)

When you release any of these, the records are removed automatically.

The platform infrastructure (*.ring.nekotopia.io — wiki, necho, browse, wrp, jump, gateway, …) is operator-owned and lives in a separate platform zone. See Ring DNS.

What you can customise¶

The DNS Manager UI shows one card per allocation. Inside each card you can:

Add a custom forward hostname — pick a memorable name (e.g. myapp.dist.nekotopia.io) pointing at the same IP. Submitted records are committed straight to Route53 + dnsmasq.
Override the reverse PTR — tick the Use as PTR checkbox on any custom forward record to make the PTR point at it instead of the default ip-X-X-X-X.<region>.nekotopia.io. Useful for outbound mail (SPF/reverse-match), reputation services, anything that does PTR lookups.

The PTR is mutually exclusive per IP — only one custom record at a time can hold it. Ticking one auto-clears the others. Unticking the last one restores the regional default.

The three editable zones¶

Zone	Who	Holds	Visibility
`dist.nekotopia.io`	Plus + Pro (with nSolo)	Records pointing at your nSolo IP	Public + Torus
`core.nekotopia.io`	Pro only (with nColo)	Records pointing into your nColo prefix	Public + Torus
(`edge.nekotopia.io` is auto-managed and not editable in the UI.)

The card for each zone only appears when you have the matching allocation. Basic members with no nSolo/nColo see an empty state pointing to the Torus tiers page.

Adding a record¶

In the per-allocation card, type a hostname in the inline form (the suffix .dist.nekotopia.io or .core.nekotopia.io is appended automatically) and click + Add. The record is created and committed in one step — no separate draft → commit flow. Live in Route53 + dnsmasq within a few seconds.

Editing / deleting¶

Inline buttons in the records table. Edits go back through the same draft → commit flow. Deleting a propagated record also removes it from Route53 (where applicable).

What's resolvable where¶

Inside Torus (DNS = your hub's dnsmasq):
  ring.nekotopia.io  → yes
  edge.nekotopia.io  → yes (member mesh IPs)
  dist.nekotopia.io  → yes (member nSolo IPs)
  core.nekotopia.io  → yes (member nColo IPs)

Outside Torus (public DNS / Route53):
  ring.nekotopia.io  → no
  edge.nekotopia.io  → no
  dist.nekotopia.io  → yes
  core.nekotopia.io  → yes

Reachability is a separate question: - edge only — mesh-only. You need to be on Torus to actually hit those IPs. - dist — you can resolve it from anywhere on the internet; whether you can reach the IP depends on what's listening (typically nothing unless you also have nSolo Inbound). - core — same as dist, but the underlying IP is inside your routed nColo prefix, so anything in your prefix that's listening is reachable.

Hostname rules¶

Lowercase, alphanumeric + dash, max ~32 chars
Reserved prefixes (blocked across all zones): www, mail, smtp, pop, imap, ftp, ns, ns1, ns2, dns, admin, root, test, dev, staging, prod, localhost, local, nekotopia, torus, teleport, api, app, cdn, static. The ip-X-X-X-X pattern is also reserved (used for platform-managed defaults).
One zone per record — myapp.dist.nekotopia.io and myapp.core.nekotopia.io are different records; you can hold both if your tier permits
Duplicate (same name + type + zone) is rejected at create

Tier downgrades¶

If you drop a tier, records in zones you've lost are archived, not silently deleted. The downgrade confirmation modal lists exactly which records will be archived. They survive in archived_dns.json for 90 days; if you re-upgrade within that window, the DNS Manager shows a per-zone Restore archived records disclosure. Restoring re-validates each record against your current allocations — stale values (e.g. you got a different nColo prefix this time) fail with a clear error rather than creating zombie records.