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

Al Whaley awsflug at sunnyside.com
Tue Sep 10 10:54:09 PDT 2019 

Mike,
I like option 1.  I'm happy to second.  I have set up the sf*lug.* 
domains to all draw characteristics from the same profile, so I can 
change the DNS servers  in the profile instead of the domains and right 
now they all switch to that profile immediately.
So for all the domains I have registered the name server list at .com is:
ns.primate.net
ns1.linuxmafia.com
NS1.SVLUG.ORG
NS1.SF-LUG.ORG

I agree about multiple access to the registration data.  It might take 
making a different Godaddy account, since Godaddy has removed their 
functionality to allow other (free or not) accounts to have access to 
certain domains.  Godaddy doesn't allow multiple contacts in the 
registration data that I know of, but perhaps some other registrar is 
more appropriate.

I have an auto-renewal script that's pretty good for letsencrypt - 
install and forget.  You're welcome to it.  Works for the whole set for 
https:, email, etc.

I also like stability.
Al

On 9/9/2019 21:49, Michael Paoli wrote:
> 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
>

More information about the sf-lug mailing list