Hi Mark. THANK YOU.

sorry for delayed response.
I understood some of your response better after Matthijs also mentioned your mail-post. I need to look into DNSSEC activity flow again, i'm sure there are changes since my last works on these, 5 years back.

Main domain is "example.com"
┌────────────────┘
├─n1 (USA)       ┌─┬──g-subDomns: uga ugb ugc...
│ ├─n1─hostSrvr──│─┴─┬───DNS/web/UsrAcnt/STR/mailRelay
│ └─n1─hostSrvr──┼───│─┬─DNS/web/UsrAcnt/STR/mail
├────────────────┘   └─┴─n1-subDomns: u1a u1b u1c...
├─n2 (EU)        ┌─┬──g-subDomns: uga ugb ugc...
│ ├─n2─hostSrvr──│─┴─┬───DNS/web/UsrAcnt/STR/mailRelay
│ └─n2─hostSrvr──┼───│─┬─DNS/web/UsrAcnt/STR/mail
├────────────────┘   └─┴─n2-subDomns: u2a u2b u2c...
├─n3 (ASIA)      ┌─┬──g-subDomns: uga ugb ugc...
│ ├─n3─hostSrvr──│─┴─┬───DNS/web/UsrAcnt/STR/mailRelay
│ └─n3─hostSrvr──┼───│─┬─DNS/web/UsrAcnt/STR/mail
└────────────────┘   └─┴─n3-subDomns: u3a u3b u3c...
info, i.e:
• n1 set has 2-servers (same hostname), for HA,etc in USA.
  (n1s1 n1s2)
• n2 set has 2-servers (same hostname), for HA,etc in EU.
  (n2s1 n2s2)
• n3 set has 2-servers (same hostname), for HA,etc in ASIA.
  (n3s1 n3s2)
• (for data-privacy, etc ... local user's private/personal data must remain in their local area).
• UsrAcnt is user account+config handling service/daemon.


• STR = shared-storage ( replicated volume , mount-point )
• nameservers dnssec key-pairs, & nameserver zone files, & few other security software (SSH keypairs, TLS cert+key pair, etc) files, etc are put into a small shared-storage "v1", this is also available in each 6 servers.

• vg - shared-storage (Str) for: g-DB, global users+subDomns.
• vn1/vn2/vn3 - shared-storage (Str) for: n1-DB n2-DB n3-DB etc local-area users+subDomains.
• v1 - shared-storage (Str) for: nameservers, etc.

example.com
│
│         STR      STR
│         v1       vg (g-DB)
│         │        │
│        ┌┼┬┬┬┐   ┌┼┬┬┬┐
│        123456   123456
├─n1 USA ││││││   ││││││
│ ├─n1s1─┴────────┴───────1─┐
│ │      1│││││   1│││││    ├─ vn1 ─ n1─DB etc ─ USA
│ └─n1s2──┴────────┴──────2─┘
│         2││││    2││││
│          ││││     ││││
├─n2 EU    ││││     ││││
│ ├─n2s1───┴────────┴─────1─┐
│ │        3│││     3│││    ├─ vn2 ─ n2─DB etc ─ EU
│ └─n2s2────┴────────┴────2─┘
│           4││      4││
│            ││       ││
└─n3 ASIA    ││       ││
  ├─n3s1─────┴────────┴───1─┐
  │          5│       5│    ├─ vn3 ─ n3─DB etc ─ ASIA
  └─n3s2──────┴────────┴──2─┘
              6        6


• n1 set, n2 set, n3 set are added as nameservers for "example.com" in domain-registrar. These 3-sets have total 6-servers. ( initially, only n1s1 n2s1 n3s1 were added & configured for nameservers/DNS-server, later n1s2, n2s2, n3s2 were added).

• For 6-servers there will be 6 DNSKEY with KSK 257.
and 6 DNSKEY with ZSK 256.
• Domain-registrar of "example.com" domain will have 6 DS entries.


• Each name-server set (in domain-registrar's Domain settings) has 2 IPv4 & 2 IPv6 ... all 4 IP-address has same hostname+RDNS.


• n1 set , n2 set , n3 set are multi-signing each-others. 6-servers so 6-signers , for "example.com" domain/zone.
• n1 is SOA for "example.com" zone.
• Each in n1 n2 n3 is master/primary nameserver (provider).



zone "example.com"
│
│          For          For       ...
│           n1s1  Z1     n1s2  Z2 ...
│           DNSKEY       DNSKEY  ...
│            │            │       ...
│          ┌─┼─┬─┬─┬─┐   ┌┼┬┬┬┐   ...
│          Z Z Z Z Z Z   ZZZZZZ   ...
│          1 2 3 4 5 6   123456   ...
├─n1 USA   │ │ │ │ │ │   ││││││   ...
│ │        │ │ │ │ │ │   ││││││   ...
│ ├─n1s1───┼─┆─┆─┆─┆─┆───┼─────── ...
│ │      ┌─┴┐│ │ │ │ │  Z1│││││   ...
│ │      │Z1││ │ │ │ │    │││││   ...
│ │      └──┘│ │ │ │ │    │││││   ...
│ └─n1s2─────┼─┆─┆─┆─┆────┼────── ...
│          ┌─┴┐│ │ │ │   Z2││││   ...
│          │Z2││ │ │ │     ││││   ...
│          └──┘│ │ │ │     ││││   ...
├─n2 EU        │ │ │ │     ││││   ...
│ │            │ │ │ │     ││││   ...
│ ├─n2s1───────┼─┆─┆─┆─────┼───── ...
│ │          ┌─┴┐│ │ │    Z3│││   ...
│ │          │Z3││ │ │      │││   ...
│ │          └──┘│ │ │      │││   ...
│ └─n2s2─────────┼─┆─┆──────┼──── ...
│              ┌─┴┐│ │     Z4││   ...
│              │Z4││ │       ││   ...
│              └──┘│ │       ││   ...
└─n3 ASIA          │ │       ││   ...
  │                │ │       ││   ...
  ├─n3s1───────────┼─┆───────┼─── ...
  │              ┌─┴┐│      Z5│   ...
  │              │Z5││        │   ...
  │              └──┘│        │   ...
  └─n3s2─────────────┼────────┼── ...
                   ┌─┴┐      Z6   ...
                   │Z6│           ...
                   └──┘           ...



• Global users g-subDomains (such as uga ugb ugc etc) and n1 area, n2 area, n3 area users' subDomains (such as u1a u1b u1c u2a u2b u2c u3a u3b u3c etc) are added/removed in/from "example.com" zone.
• after add/remove a subdomain, "example.com" zone is re-MultiSigned.
• each subdomain when created, requires 1 KSK & 1 ZSK, under each server. So for 6-servers there will be 6 KSKs & 6 ZSKs. And so each subdomain also has 6 signers.

• I wanted to put individual area's local users subDomains (under "example.com") into 2 servers ( s1 s2 ) instead of all 6-servers , but i need to apply geo-location techniques for that, & need to find a solution.


• by the way, in reality, the last n3 currently have only 1 server, n3s1, performing all functions. Now n3 set/area does not have 2nd server n3s2.
• I could not obtain low-cost & suitable server in Asia.


• And, in each area's server-set (USA, EU, ASIA, ...) the s1 servers (n1s1 n2s1 n3s1) are slightly less powerful than s2 server (n1s2 n2s2 n3s2), as s2 will perform more heavy load functions than s1. If s2 goes down, some functions will pause. I could not purchase equal level & suitable server from 2 different provider in same area, for low-budget reason.


Erik.

Erik T Ashfolk.



On 9/27/24 4:13 PM, Mark Andrews wrote:
You need to remember multi-signer still has a lot of hand waving in its 
specification.  All the coordination between operators is unspecified.

Things like how you generate CDS automatically is undefined.  A pre CDS (PCDS) 
record with an signer tag and signer count  before the CDS data would work. The 
servers would then look for a full set of PCDS records and promote them to CDS 
records when that exists. This would be per algorithm.

A full set is defined as having a record from each signer and the count of such 
signers matching the maximum signers of all PCDS records.

Each signer needs to know its signer identifier and the total count of signers. 
 When a new signer is added a new PCDS is generated by each signer for its 
keys.  Similarly for when a signer is removed.

Signers will log discrepancies between the configured signer count and the 
observed value in the PCDS records.

All this needs to go through the IETF.

--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to