Multi Master/Primary Authoritative DNSSEC DNS Nameserver With Synced/Replicated COMMON Dir/Vol For BIND

[Terik Erik Ashfolk]

Hi Matthew. THANKS.
For HA (High-Availability), my 3 providers/nameservers will always 
stay online.

you are right, i'm applying high change rate in zone.

Ofcourse, now i dont have many users.
Project is in early/development stage.
But, project is geared to have many users, thus why i mentioned 
MULTI-MASTER/PRIMARY for HA.
In reality, now it has 3 nameservers in 3 separate jurisdiction, 
(USA, EU, ASIA) where personal/private will must remain in that 
area's server(s).
And USA & EU has 2 servers in same area, for HA, (even if only 1 
server is up/remain, & all others went dn/failed in same-area, then 
most essential functionalities will still continue, for lcoal users).
Could not manage to get suitable 2nd server in Asia, so Asia has 1 
server performing all tasks by itself now.
Servers have my rented IPv6 subnet over BGP-Announcement.
IPv4 subnet is costly, so staying with IPv6.
I completed shared-storage (TLS encrypted, etc) part, now into 
BIND/nameserver part.
By the way, project do involve creating dynamic sub-domain for 
user's homepage+Services, but users must get+attach their own 
domain. Then these will allow users to connect-into or provide 
service-from their own-home/homeoffice/mobile devices (so routing, 
fast-updating, etc are involved), and/or link their own server from 
server-providers.
Those were main reasons to have (very) low TTL, for faster update, 
And i used that (faster-update) opportunity to also update/change 
DNSSEC keys, etc faster.
Each area's provider/nameserver needs to prioritize availability 
local users first, so geo-detection & IP-adrs prioritizing also 
needs separate providers, where RRsets, services, etc are sorted in 
different order in different area.
Users who selected to be Global user, their's data is in separate 
shared-storage mount-point (with encryption). Global users can get 
services from any server anywhere.
I'm using low-cost resources, but problem is these type of server 
providers often close the door, servers often go down, slows-down, 
etc, etc. Some providers supports set-A resources & some not, Some 
supports set-B resources & some not, etc. Thus the need for HA.
Hope these give better understanding + explain to readers, on my 
need, & why i'm doing various stuff in certain ways.
I'm always open to change+improve, but also need to stay with 
project objectives, & also need to be whats possible or what i'm 
capable to do, etc. My cousin did help when he could.
I dont know how far i can go with very-low budget, but lets see.


Readers can see why i'm implementing a set of strategies thats 
suitable for my type of project objectives.
If/when reader's objectives are different then they need to change 
their config to suit their need.


5 or 6 years earlier, i did these shared-storage (synced over 
SSH,etc), DNSSEC DNS nameservers, dynamic linking, etc ... (with 
only 3 small servers) ... tried to do multi signing for DNSSEC, but 
did not get suitable response/advise from experts, (as multi 
signing was idea or in infancy). I also contacted few ISC/IETF 
members, only 1 responded ... Anyway, i & my cousin decided to use 
master/slave mode. And after some time i could not continue on this 
project, as another project was becoming better.


I'm amazed, that Multi-Signer functionality still has not been 
solved in DNSSEC.
It was+is essential, & can meet practical DNS configuration needs, 
low-cost HA need.


Erik.

Erik T Ashfolk.


On 9/30/24 12:11 PM, Matthew Pounsett wrote:
> 
> 
> On Sat, Sep 28, 2024 at 11:13 AM Terik Erik Ashfolk 
> <aterik at outlook.com <mailto:aterik at outlook.com>> wrote:
> 
> 
>     But 1024 or 2048 bit RSA key-pairs are considered weak.
> 
> 
> Those are considered weak for _encryption_ because of the risk of 
> future decryption of secrets.  The window for someone to brute 
> force your keys and fake signatures with a limited lifetime is 
> closed the second you rotate your existing keys, and rotating every 
> year or two is plenty for that use case.
> 
> 
> What is your motivation for doing multi-signer here?  The only 
> thing I can think of is if you have an extremely high change rate 
> on the zone, and can't afford to have the signer down for a few 
> hours overnight if it fails.  For pretty much any other use case 
> you're fine having a single signer, with a much MUCH simpler 
> configuration, which can be replaced in a heartbeat next-business- 
> day if the production signer fails for some reason.
>