[sf-lug] Got domains? (sf-lug.{net, com} ...?) ... DNS slaves ...

[Michael Paoli]

Al,

How 'bout your (perhaps along with some other(s)) choice:

For the domains (notably presently the non-canonical)
sf-lug.NET and sf-lug.COM

Can go one of two (general) routes/ways ... your choice (matters not
much to me):

First of all, there's a (presumed) general objective, that the
non-canonicals suitably HTTP 301 redirect to the canonical,
e.g.:
http[s]://[www.]non-canonical/whatever... --> 301 -->
http[s]://www.sf-lug.org/whatever...
With protocol (http or https) (and port) remaining same,
and pathname portion (whatever...) remaining same - likewise including
any query portion, anchor, etc., and with proper recognized CA signed
cert(s) installed for https://[www.]non-canonical/whatever...
That (presumably) being the case,
two general options on how to proceed on each such domain (and each
domains can be decided independently):

Option one:
delegate me as DNS master (including "glue"):
NON-CANONICAL.       IN   NS     ns0.NON-CANONICAL.
ns0.NON-CANONICAL.   IN   A      198.144.194.238
ns0.NON-CANONICAL.   IN   AAAA   2001:470:1f05:19e::3
and then I'll:
o set up DNS master
o provide DNSSEC data to activate DNSSEC (typically installed via
   registrar interface(s) to install into delegating authority DNS)
o arrange for DNS slaves (you're certainly welcome to volunteer for
   that!)
o set up sudo access so appropriate SF-LUG folks can also update DNS
   master zone file data (feel free to volunteer if you want to be
   added to the folks that have such access)
o set up the relevant http[s] redirects from non-canonical to canonical
o set up and maintain the relevant TLS(/"SSL") cert(s) for https on the
   above (note that I may not add those until I get around to my <90
   day update/replacement cycle - for (my) efficiency, I tend to
   renew/replace all my certs right around the same time)
o periodically backup the relevant data (folks can also volunteer to
   be yet another set of backup(s) for various SF-LUG data, if they
   so wish).

Option two:
You and/or other(s) can effectively provide that functionality (would
mostly look the same to users - unless they particularly
"peek under the hood" (look at various technical details) the
differences would/should be effectively transparent to most users:
o set up DNS, including master(s) and if/as applicable, slave(s)
   (I and/or others can also volunteer to provide slave services)
o optionally implement DNSSEC
o optionally set up access so additional appropriate SF-LUG folks can
   update/alter/maintain the relevant DNS (including master zone data).
o set up the relevant http[s] redirects from non-canonical to canonical
o set up and maintain the relevant TLS(/"SSL") cert(s) for https on the
   above
o periodically backup the relevant data (if relevant access is made
   available, additional folk(s) may volunteer to also backup this data)

And, as I'm sure Rick would be inclined to point out, would be good
on the registrar's whois data for the registrant, to have multiple
independent person's names and email addresses in there, "just in case"
(avoid single points of failure); and I'd be inclined to also say, may
depend upon the registrar and what tools/capabilities they make
available, but many have capabilities to add additional person(s) with
access, and may have various granularity controls on that access, e.g.
just be able to change DNS related data, or "everything" except
accessing or using stored credit/debit billing data, or "everything" -
particulars/capabilities vary by registrar.

I'll also add (probably/hopefully mostly goes without saying - but to
cover the bases), best not to be willy-nilly flippin' stuff back 'n
forth, e.g. (especially majorly) switching between such options, adding
domains, then dropping them, etc.  All such changes burn resources,
and excessively/unnecessarily doing so, or even more so - folks also
tend to get annoyed when their volunteered resources (e.g. time) are
callously disregarded and effectively or much wasted because they're
"free" - folks can always choose to do *other* things with their
valuable limited resources.

And thanks for all your work on this!  :-)

> From: "Al Whaley" <awsflug at sunnyside.com>
> Subject: Re: Got domains? (sf-lug.{net,com} ...?) ... DNS slaves ...
> Date: Sun, 8 Sep 2019 20:27:30 -0700

> It's not my impression that anyone in the actual sf-lug meeting  
> group care all that much, so I suppose we could set these
> other domains up or we could for now just ignore them.
> I'm certainly willing to slave DNS for them or other domains.
>
> On 9/8/2019 17:47, Michael Paoli wrote:
>> Well, ... suppose I could set up DNS master & http[s] redirects ...
>> "again" in the case of sf-lug.com ... and
>> "new" in the case of sf-lug.net
>> Wanna offer DNS slaves for such?
>>
>> ... or someone(s) else could do all that and set up suitable
>> redirects, ... sf-lug.org thus far still being the canonical 'n
>> all that.
>>
>> Let me know how you'd like to proceed.
>>
>> Also, while I'm thinking about DNS slaves, ... looking/hoping for
>> some that are more responsive to NOTIFY events than puck.nether.net.
>> Great that puck.nether.net is free and quite available, and basically
>> self-serve to set up, but becomes rather annoying when I'm doing
>> DNS verifications for SSL certs, and I'm trying to get all the relevant
>> records into authoritative DNS in sufficiently timely manner. Also a
>> pain when the back-ends of it are effectively "hidden", and I may see
>> most current S/N from its public IPs one moment, and somewhat older
>> zone serial #s and data later from same IP(s) ... so makes it harder
>> to know when it's fully "given up" the older data (short of any
>> guarantees on DNS TTLs themselves ... but I've got rather long
>> time on the negative caching, so I don't want a "miss" when things first
>> check for those (unique random) DNS entries).
>>
>>> From: "Al Whaley" <awsflug at sunnyside.com>
>>> Subject: Re: Got domains? (sf-lug.{net,com} ...?)
>>> Date: Sun, 8 Sep 2019 08:17:16 -0700
>>
>>> Michael,
>>> Guilty.
>>> Probably unnecessary, but what the heck.
>>> Let me know if you have any DNSSEC entries.
>>> Al
>>>
>>> On 9/7/2019 21:39, Michael Paoli wrote:
>>>> Hmmm, got domains?
>>>>
>>>> I notice (and somebody else had noticed) ...
>>>> $ whois sf-lug.net | fgrep Date:
>>>>  Updated Date: 2019-09-03T23:38:29Z
>>>>  Creation Date: 2019-09-03T23:38:28Z
>>>>  Registry Expiry Date: 2020-09-03T23:38:28Z
>>>> Updated Date: 2019-09-03T23:38:29Z
>>>> Creation Date: 2019-09-03T23:38:28Z
>>>> Registrar Registration Expiration Date: 2020-09-03T23:38:28Z
>>>> $
>>>>
>>>> $ whois sf-lug.com | fgrep Date:
>>>>  Updated Date: 2019-09-07T21:52:41Z
>>>>  Creation Date: 2019-09-07T18:09:17Z
>>>>  Registry Expiry Date: 2020-09-07T18:09:17Z
>>>> Updated Date: 2019-09-07T21:52:40Z
>>>> Creation Date: 2019-09-07T18:09:17Z
>>>> Registrar Registration Expiration Date: 2020-09-07T18:09:17Z
>>>> $
>>>>
>>>> references/excerpts:
>>>> whois(1)
>>>> https://www.balug.org/wiki/doku.php?id=sf-lug:resources_etc