[retronet] Subdomains of retrocomp.net…

[John P. Willis]

----- On Aug 30, 2018, at 10:51 PM, gtaylor gtaylor at tnetconsulting.net wrote:

> On 08/30/2018 10:34 PM, John P. Willis wrote:
> 
>> Do we want it integrated in any way into the registration system
>> I'm putting together? It will be able to hold <$memberNickname>, and
>> could easily spit out zonefiles/sections of zonefiles/kick off an rndc
>> retransfer.
> 
> I think we certainly want to register nick names and use that as the
> subdomain name by default if not by declaration.
> 
> Aside:  I see no reason at this time why we would need to go beyond one
> subdomain name.  (I can see a hypothetical possibility of more than a
> /24 in an extreme case, but we can easily cross that bridge when we get
> there.)
> 

Agreed.

> 
> That being said, I'm more interested in leveraging Dynamic DNS, using
> TSIG keys and "grant" statements, to allow clients to use the DNS
> protocols to update their zones / records via things like nsupdate.
> 
> I would also be quite interested in the possibility of the Web UIs
> re-using the same Dynamic DNS methodology.
> 
> The systems that do the update can identify the SOA for the zone /
> subdomain and send Dynamic DNS updates (via nsupdate or anything else
> comparable) to the master name server.  Said master name server could be
> BIND running on the local RetroNet client or it could be BIND running on
> the central RetroNet servers.  Same method supports different locations.
> 

I think it sounds compelling, though my only experience with dynamic DNS
systems was a stint with AD-integrated DNS ca. 2001.

>> Pretty used to automating this sort of thing. Not saying those scripts
>> are useful in this scenario, however.
> 
> I think it's an interesting idea.  I'm personally interested in trying
> the Dynamic DNS updates using TSIG keys and grant statements first.
> 
> What do you think?
> 
> 

My only concern (minor concern; not a show-stopper) would be shutting out
people who want to run their own DNS on vintage gear/systems that may not
support the more modern features.

Again, though, a bridge we can cross when we get there, and perhaps one 
better left to individual cases.

In any event, I think the central servers should probably be something
secure and modern, with the caveat that old resolver libraries must be
able to work with them.

> 
> --
> Grant. . . .
> unix || die
> 
> 
> _______________________________________________
> retronet mailing list
> retronet at mailman.chivanet.org
> http://mailman.chivanet.org/listinfo/retronet