fallback available for DNS/email #1374

New issue

Open

opened 2026-08-14 20:43:39 +02:00 by kiara · 2 comments

kiara commented

2026-08-14 20:43:39 +02:00

Owner

As a hosting provider,
I want a server to fall back to for DNS/email,
so that use of our services may continue undisturbed in case my production one goes down.

implementation notes

@koen suggested that different hosting providers using Fediversity could be facilitated in pooling their instances for this purpose, given the point would be to hedge it so they would not fail together.

**As** a hosting provider, **I want** a server to fall back to for DNS/email, **so that** use of our services may continue undisturbed in case my production one goes down. ### implementation notes - @koen suggested that different hosting providers using Fediversity could be facilitated in pooling their instances for this purpose, given the point would be to hedge it so they would not fail together.

kiara added the

type

user-story

label

2026-08-14 20:43:39 +02:00

kiara added a new dependency

2026-08-14 20:44:02 +02:00

#200 reproduce DNS VM

kiara added a new dependency

2026-08-14 20:44:26 +02:00

#380 initial Fediversity applications

kiara commented

2026-08-30 09:15:32 +02:00

Author

Owner

for what it's worth, it looks like predelegation-check TLDs (.de, .no, .dk, .nl?, see #110) are an awkward fit for such pooling in a setting involving a set of hosting providers potentially in competition, as the registry's gate fails hard: a stale delegation takes the zone down for everyone, behind a TTL we cannot shorten (the .de registry sets 86400s on the DS record).
as such, it could be of interest to limit this feature to higher-trust clusters, not unlike clan's setting.

for what it's worth, it looks like predelegation-check TLDs (`.de`, `.no`, `.dk`, `.nl`?, see #110) are an awkward fit for such pooling in a setting involving a set of hosting providers potentially in competition, as the registry's gate fails hard: a stale delegation takes the zone down for everyone, behind a TTL we cannot shorten (the `.de` registry sets 86400s on the DS record). as such, it could be of interest to limit this feature to higher-trust clusters, not unlike [clan](https://clan.lol/)'s setting.

kiara commented

2026-08-30 09:47:37 +02:00

Author

Owner

well worst-case we could just try third-party deSEC for the DNS side - which as per our DNS client comparison at #110 already seems supported by our DNS client OctoDNS as well.

well worst-case we could just try third-party [deSEC](https://desec.io/) for the DNS side - which as per our DNS client comparison at #110 already seems supported by our DNS client OctoDNS as well.

kiara referenced this issue from a commit

2026-09-03 13:57:36 +02:00

dns: let an incumbent secondary transfer from its address

kiara referenced this issue from a commit

2026-09-04 14:42:16 +02:00

dns: let a node slave the apex instead of holding it