[sf-lug] Got domains? (sf-lug.{net,com} ...?)
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Wed Sep 11 09:45:57 PDT 2019
Al,
Thanks. I'll take you up on option 1/one for those two domains then.
I'm guestimaging having my bits of it done sometime between now and
end of next week (no shortage of other stuff goin' on too - including
even other [L]UG stuff). I'll update on relevant bits (notably
when I'm ready for you to take any relevant next steps).
Thanks.
> From: "Al Whaley" <awsflug at sunnyside.com>
> Subject: Re: Got domains? (sf-lug.{net,com} ...?) ... DNS slaves ...
> Date: Tue, 10 Sep 2019 10:54:09 -0700
> 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