Subj : Re: I just borked the dns
To   : Deon George
From : MeaTLoTioN
Date : Fri May 10 2019 09:02 am

 DG> Actually, Al is right, the nodelist should reflect the correct state of
 DG> affairs, (and owners could override that if required).
 DG> 
 DG> So technically, this net is not "on ZT", we havent got critical mass :(.
 DG> We are by definition "in transition" or "schizophrenic" :)

Schizophrenic - love it! 

 DG> So, in the nodelist:
 DG> 
 DG> * Hub 1 could have the ZT address - but instructions to Hub 3 on how to
 DG> connect to it, as a manual override, since its not on ZT yet.
 DG> 
 DG> * Hub 2 can have a ZT address - its on me to tell my remaining
 DG> downstream how to connect me via override, or get them onboard (apam are
 DG> you listening? :)
 DG> 
 DG> * Hub 3 should have a public address - since it cannot do ZT and has all
 DG> downstreams that are not on ZT. Hub 1 would need an override to talk to
 DG> it, (as would Hub 2).
 DG> 
 DG> If/when Hub 3 can do ZT, it would be up to Al if he adopted it as a
 DG> default for his Region, and when to change the nodelist address to a ZT
 DG> address. (It would take into account who looses access if his nodelist
 DG> hostname address changes - since you should work on the assumption that
 DG> mailers send according to nodelist entries (which is not how most use
 DG> mystic I believe).
 DG> 
 DG> The impact of this, is nodes (not on ZT) cannot talk to Hubs exclusively
 DG> on ZT (according to the nodelist), unless the know an override - but
 DG> they should always be able to connect to their hub to send messages...
 DG> 
 DG> There may also be a way of doing this with DNS A/AAAA records resolving
 DG> to both public and ZT ip addresses (not multiple names however, since
 DG> its a 1:1 mapping of CNAME and its value). (I cannot do this, because my
 DG> public address is dynamic, so, I have a static CNAME that always knows
 DG> what it's current value is.)
 DG> 
 DG> Argh, the joys of network admin :)
 DG> 

Ok, so what I'm reading into this is that in the nodelist, I am able to keep
HUB 1 with the zt address, HUB 2 with the zt address, and HUB 3 should be on
the public address until such times as zt is available and Al chooses to use
that as primary? I can set that no probs of course.

Seeing as currently HUB 1 only services 1 node, i.e. TQW, it's safe to assume
that the BBS owner is happy for it to be zt connectivity, =), and HUB 2, it's
down to nodes and HUB admin to ascertain which to use?

I guess my question needs to be more specific... what _should_ I put into the
nodelist for right now, and at what time should I modify it to reflect
something different?

---
|14Best regards,
|11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N

|07ÄÄ |08[|10eml|08] |15ml@erb.pw |07ÄÄ |08[|10web|08] |15www.erb.pw |07ÄÄÄ¿
|07ÄÄ |08[|09fsx|08]  |1521:1/158 |07ÄÄ |08[|11tqw|08] |151337:1/101 |07ÂÄÄÙ
|07ÄÄ |08[|12rtn|08] |1580:774/81 |07ÄÂ |08[|14fdn|08] |152:250/5 |07ÄÄÄÙ
|07ÄÄ |08[|10ark|08]  |1510:104/2 |07ÄÙ

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
 * Origin: The Quantum Wormhole, Ramsgate, UK. bbs.erb.pw (1337:1/101)

.