[sf-lug] And then there were 5: SFLUG.NET, SFLUG.COM, SFLUG, ORG, SF-LUG.COM, SF-LUG.ORG: Re: SFLUG.COM Re: SFLUG.[...] Re: SFLUG.org

Michael Paoli Michael.Paoli at cal.berkeley.edu
Thu Apr 18 06:39:37 PDT 2019


Lazy (a.k.a. efficient) SysAdmin/DNSAdmin/... ;-)

So ...
2019-05-22T10:05:40Z letsencrypt.org cert expires:  
*.sf-lug.org,sf-lug.org,*.ipv4.sf-lug.org,*.ipv6.sf-lug.org,*.sf-lug.com,sf-lug.com

As for http[s]://[www.]sflug.{org,com,net}/
I'll probably not add (proper, if any) certs until <~=2019-05-22T10:05:40Z
and likewise redirections to the canonical, etc. (though maybe I'll get
to some of that (fair bit?) sooner?).

Can be significantly more efficient to batch similar/related
items/requests and process them at/around same time, or back-to-back
or in parallel, as opposed to handling 'em separately (and more
immediately) as onesies-twosies.

So ... I'm thinkin' by about 2019-05-22T10:05:40Z we'll know what the
canonical is and what domains we've then got and are set up with
master(s) and slaves, and some means by which I can reasonably quickly
alter DNS (add/drop verification RRs) if I'm to be providing
corresponding https.

At that time, I can then add the relevant domains, etc. to TLS cert -
I'll likely also then drop the [ipv[46].] from all but the canonical.
And then knowing what the canonical is, can get all that in place and
configured in the web server.

And why also ~2019-05-22?  Because I've got a bunch of TLS certs that
expire around that same time.  It's much more efficient (easier) to deal
with them all around the same time, as opposed to having to deal with a
bunch of different certs that expire at different times.  I.e., as it
presently is, I have to deal with them once every <~=90 days, changing
that pattern means I would have to do that more often and/or sooner than
when approximately necessary anyway.

And if someone particularly wants different A, AAAA, and/or CAA records
in the meantime for any of, e.g. [www.]sflug.{org,com,net}.,
just spell out exactly what you need on those, and I can drop 'em in
easily enough (Rick Moen also has requisite access to be able to
do so.  Various folks - including Jim Stockford, also have the
requisite access to edit the existing http[s]://[www.]sf-lug.org/
web page).

Unless/until I hear otherwise, I'm presuming that, at least thus far,
http[s]://www.sf-lug.org/
remains the canonical.

Note also that many search engines / browsers are increasingly pushing
to/towards https.  We may want to - at least potentially at some point -
have the http redirect to https - not doing so yet for
{sf[-]lug.{org,com},sflug.net} - at least in general - but we
may decide in future - or at some particular future time/date - that
we may (then) want to do so.

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] And then there were 5: SFLUG.NET, SFLUG.COM,  
> SFLUG, ORG, SF-LUG.COM, SF-LUG.ORG: Re:  SFLUG.COM Re: SFLUG.[...]  
> Re: SFLUG.org
> Date: Thu, 18 Apr 2019 01:23:34 -0700

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> Uhm, are we done adding domains for a while now, or ... are we gonna pick up
>> yet more?  SF-LUG.NET also seems available, but I don't know that Jim
>> specifically suggested that ... nor up to how many domains he's willing
>> to be reimbursing folks for.
>
> Well, that's an issue going forward, isn't it?  For now, I'm going to
> infer a desire for slave nameservice from my two nameservers for...
>
>> Anyway, master now available for not only sflug.org.
>> but also now sflug.com. and sflug.net.:
>> ns1.sf-lug.org.:
>> 198.144.194.238
>> 2001:470:1f04:19e::2
>> Not sure where the slaves may be in the process.
>> Rick - if you want to coordinate with Al, you do also have access to
>> edit those zone masters:
>> balug-sf-lug-v2.balug.org
>
> [snip]
>
> Looks like Al (I assume) has gone ahead and declared authoritative the
> usual gang of nameservers:
>
> Liten-Datamaskin:~ rick$ whois sflug.net | grep 'Name Server'
>    Name Server: NS.PRIMATE.NET
>    Name Server: NS1.LINUXMAFIA.COM
>    Name Server: NS1.SF-LUG.ORG
>    Name Server: NS1.SVLUG.ORG
> Name Server: NS.PRIMATE.NET
> Name Server: NS1.LINUXMAFIA.COM
> Name Server: NS1.SVLUG.ORG
> Name Server: NS1.SF-LUG.ORG
> Liten-Datamaskin:~ rick$ whois sflug.com | grep 'Name Server'
>    Name Server: NS.PRIMATE.NET
>    Name Server: NS1.LINUXMAFIA.COM
>    Name Server: NS1.SF-LUG.ORG
>    Name Server: NS1.SVLUG.ORG
> Name Server: NS.PRIMATE.NET
> Name Server: NS1.LINUXMAFIA.COM
> Name Server: NS1.SVLUG.ORG
> Name Server: NS1.SF-LUG.ORG
> Liten-Datamaskin:~ rick$
>
> Checking at the master:
>
> Liten-Datamaskin:~ rick$ dig -t soa sflug.net @NS1.SF-LUG.ORG +short
> ns1.sflug.net. jim.well.com. 1555254673 10800 3600 1209600 86400
> Liten-Datamaskin:~ rick$ dig -t soa sflug.com @NS1.SF-LUG.ORG +short
> ns1.sflug.com. jim.well.com. 1555254672 10800 3600 1209600 86400
> Liten-Datamaskin:~ rick$
>
> Notice that the FQDN of the master nameserver cited in the SOA record
> ('ns1.sflug.net', 'ns1.sflug.com') is a mismatch compared to the
> parent-zone NS record FQDN ('NS1.SF-LUG.ORG') -- but this is admittedly
> a very minor problem.
>
> Neither of these two is yet set up at my two nameservers.  We'll do
> that now.  Adding slave nameservice on offered nameserver 1 of 2,
> ns1.linuxmafia.com:
>
> [Snip my adding two new stanzas to /etc/bind/named.conf.local.  Then:]
>
> linuxmafia:/etc/bind# rndc reconfig
> linuxmafia:/etc/bind# dig -t soa sflug.net @ns1.linuxmafia.com +short
> ns1.sflug.net. jim.well.com. 1555254673 10800 3600 1209600 86400
> linuxmafia:/etc/bind# dig -t soa sflug.com @ns1.linuxmafia.com +short
> ns1.sflug.com. jim.well.com. 1555254672 10800 3600 1209600 86400
> linuxmafia:/etc/bind#
>
> Confirmed functional.
>
> Moving on to configurating slave nameservice on offered nameserver
> 2 of 2, ns1.svlug.org, where it's NSD rather than BIND
>
> rick at gruyere:~$ sudo su -
> [sudo] password for rick:
> root at gruyere:~ # cd /etc/nsd3
> root at gruyere:/etc/nsd3
>
> [Snip my adding two new stanzas to /etc/nsd3/nsd.conf.  Then:]
>
> root at gruyere:/etc/nsd3 # nsdc restart
> root at gruyere:/etc/nsd3 # nsd-xfer -z sflug.net -f  
> secondary/sflug.net.zone 198.144.194.238
> [1555575378] nsd-xfer[23460]: info: send AXFR query to  
> 198.144.194.238 for sflug.net.
> root at gruyere:/etc/nsd3 # nsd-xfer -z sflug.com -f  
> secondary/sflug.com.zone 198.144.194.238
> [1555575396] nsd-xfer[23467]: info: send AXFR query to  
> 198.144.194.238 for sflug.com.
> root at gruyere:/etc/nsd3 # chown nsd:nsd secondary/sflug.net.zone  
> secondary/sflug.com.zone
> root at gruyere:/etc/nsd3 # nsdc rebuild
> root at gruyere:/etc/nsd3 # dig -t soa sflug.net @ns1.svlug.org +short
> ns1.sflug.net. jim.well.com. 1555254673 10800 3600 1209600 86400
> root at gruyere:/etc/nsd3 # dig -t soa sflug.com @ns1.svlug.org +short
> ns1.sflug.com. jim.well.com. 1555254672 10800 3600 1209600 86400
> root at gruyere:/etc/nsd3 #
>
> Confirmed functional.
>
>
> You'll bug Aaron Porter about adding slave nameservice for sflug.net and
> sflug.com to ns.primate.net, right?  It's not serving those, yet.
>
>
> AFAIK, I'm done as to my part(s).




More information about the sf-lug mailing list