Dynamic DNS updates and letsencrypt.org ... yummy! :-)
So, not too long back, I had a wee little mini-project that gave me
motivation to start using, or at to at least seriously consider
starting to use, dynamic DNS updates.
I'll skip the full details on that, but key bit was, to be able to give
specific individual(s), ability to relatively easily and quickly edit
DNS data ... but only very specific DNS data. Notably, generally, that
of a specific subdomain (Pi.BerkeleyLUG.com) - and any subdomains
thereunder. And without giving them ability to alter any other DNS
data in or under the zone (BerkeleyLUG.com).
Without dynamic DNS updates, there would generally be two possible ways
to approach that. One would be to create delegated subdomain. That
then fully hands that off, but then burdens them with additional need
to have DNS servers, and needing static Internet Protocol addresses
(IPs) for those etc., and part of the earlier motivation was that they
didn't have static IPs. So that also would burden them with DNS
nameservers and need for static IPs - so that would at best be far from
idea.
Other approach, would be to leverage existing DNS infrastructure, and
allow them only to change data in and under the subdomain
(Pi.BerkeleyLUG.com) of existing zone (BerkeleyLUG.com). That would be
rather to quite difficult, as allowing them to only make DNS changes in
the zone file appropriate for the subdomain (and any thereunder), would
be a quite non-trivial configuration task. So, such an approach also
wasn't very feasible. Not to mention there are generally hazards with
allowing folks to edit DNS master zone file(s) - notably errors there
can cause significant problems with DNS (up to and including breakage
or other issues with up to the entire zone).
Well, enter dynamic DNS. With that, I could set up key that could be
used only to alter DNS data for the subdomain (and any subdomains
thereunder), but that key couldn't change any other DNS data at all.
So that was the general approach I pursued. To test, and before
enabling dynamic DNS on production (BerkeleyLUG.com) domain/zone, I
created a temporary test delegated subdomain, and tested dynamic DNS on
that zone (and restricting to a subdomain thereof, and any subdomains
thereunder). I then created one more such temporary test delegated
subdomain for some further testing.
After I was fully satisfied with all that, I moved on to dropping those
two temporary test delegated subdomains, and enabling dynamic DNS
updates for the production domain/zone, and setting up key that could
only change the specifically configured subdomain (Pi.BerkeleyLUG.com)
within (and any subdomains thereunder).
Anyway, after having that infrastructure in place, I thought of another
potentially very useful use case. letsencrypt.org Certificate
Authority (CA) TLS(/"SSL") certificates (certs). To validate those,
http can be used - but not for wildcard certs, or DNS and including
wildcard certs. Since many of the certs I use and prefer (if not
"require" - does make things quite a bit simpler) use wildcards, well,
DNS validation is the way to go on that. But that's been a quite
semi-manual process. Notably, I'd been doing it where requesting
client tells me what DNS data to add, I manually add it (add it to zone
file and update serial number, reload, wait for that to propagate to
the responding authoritative nameservers) ... and do that for each such
verification data that needs be added, manually doing each, getting the
cert, then removing those temporarily added no longer needed bits of
DNS data. Well, certbot(8) (client for letsencrypt.org) has
hooks/capabilities to use dynamic DNS updates and/or call programs in
place of (or as part of) the "manual" verification (and cleanup) steps.
So, by either by giving it access to suitable key (and/)or by having
it call programs to handle creating the validation data, those steps
can be automated. For DNS, such program(s) would be being given a
[sub]domain, and a specific text string, and would then create the
relevant TXT record under that [sub]domain. So, I set up a key with
the appropriate access to use dynamic DNS (and had earlier set dynamic
DNS up across all the zones where I'm master), and set up some helper
programs, to allow certbot(8) to leverage the specific key, to make the
DNS additions - and also remove them again after validations have
completed.
So ... generating keys, CSRs, requesting certs, temporarily inserting
DNS validation data, getting certs, and removing that temporarily
inserted data. That used to be a semi-manual process. The manual part
mostly being adding DNS data, checking its propagation, proceeding
through that validation step ... for numerous domains across multiple
certs. Typically that would take me, oh, maybe roughly 30 minutes or
more, maybe once every about 85 days or so (the certs have a lifetime of
only 90 days).
But with dynamic DNS, and certbot(8) then using the hooks to programs I
wrote ... full automated. What used to typically take about 30 minutes
or more about every 85 days or so ... much faster and fully automated.
Now down to ... under 4 minutes (3m21.050s)!
Anyway, I show that below - the/my command used (I did this one against
letsencrypt.org test environment, as I don't need to get new certs at
present, and test doesn't have the rate limiting of the production
environment, and also saves production from having that additional
traffic where it's not needed - otherwise production is essentially
identical).
$ time myCERTBOT_EMAIL= \
> myCERTBOT_OPTS='--preferred-challenges dns --test-cert --server
> https://acme-v02.api.letsencrypt.org/directory --manual-auth-hook
> mymanual-auth-hook --manual-cleanup-hook mymanual-cleanup-hook' \
> Getcerts \
> '*.balug.org,balug.org,*.archive.balug.org,*.beta.balug.org,*.ipv4.balug.org,*.ipv6.balug.org,*.new.balug.org,*.secure.balug.org,*.staging.balug.org,*.test.balug.org,*.php.test.balug.org,*.wiki.balug.org'
> \
> '*.sf-lug.org,sf-lug.org,*.ipv4.sf-lug.org,*.ipv6.sf-lug.org,*.sflug.org,sflug.org,*.sflug.com,sflug.com,*.sflug.net,sflug.net,sf-lug.net,www.sf-lug.net,sf-lug.com,www.sf-lug.com'
> \
> 'mpaoli.net,*.mpaoli.net,*.blackie.mpaoli.net,*.old-debian.mpaoli.net,digita…'
> \
> '*.balug.org,balug.org,*.lists.balug.org,berkeleylug.com,*.berkeleylug.com' \
> 'berkeleylug.com,*.berkeleylug.com,berkeleylug.org,*.berkeleylug.org' \
> '*.pi.berkeleylug.com,pi.berkeleylug.com'; echo "$?"
...
real 3m21.050s
user 0m23.092s
sys 0m4.706s
$ (for f in *_cert.pem; do openssl x509 -noout -text -in "$f" 2>&1
> done) |
> sed -ne 's/^ *\(Not After :.*\)$/\1/p
> /DNS:/{s/^ *//;s/, */,/g;s/DNS://g;p}'
Not After : Jun 25 16:57:17 2020 GMT
*.archive.balug.org,*.balug.org,*.beta.balug.org,*.ipv4.balug.org,*.ipv6.balug.org,*.new.balug.org,*.php.test.balug.org,*.secure.balug.org,*.staging.balug.org,*.test.balug.org,*.wiki.balug.org,balug.org
Not After : Jun 25 16:57:24 2020 GMT
*.ipv4.sf-lug.org,*.ipv6.sf-lug.org,*.sf-lug.org,*.sflug.com,*.sflug.net,*.sflug.org,sf-lug.com,sf-lug.net,sf-lug.org,sflug.com,sflug.net,sflug.org,www.sf-lug.com,www.sf-lug.net
Not After : Jun 25 16:57:28 2020 GMT
*.blackie.mpaoli.net,*.digitalwitness.org,*.mpaoli.net,*.old-debian.mpaoli.net,digitalwitness.org,mpaoli.net
Not After : Jun 25 16:57:33 2020 GMT
*.balug.org,*.berkeleylug.com,*.lists.balug.org,balug.org,berkeleylug.com
Not After : Jun 25 16:57:38 2020 GMT
*.berkeleylug.com,*.berkeleylug.org,berkeleylug.com,berkeleylug.org
Not After : Jun 25 16:57:43 2020 GMT
*.pi.berkeleylug.com,pi.berkeleylug.com
$
And at the end there, for the certs obtained I show when they expire and
the domains/names in their SAN data.
Note also in the above, the leading "> " is not literally entered, but
PS2 (essentially the shell prompting us that it needs more input to
complete the command).
So, 6 certs, each with Subject Alternative Name (SAN) having multiple
names/domains, and each with at least one, if not more, having wildcard
... all done automatically in 3m21.050s elapsed time.
Oh, and another advantage with dynamic DNS updates. Serial numbers
handled automatically - one less place for us mere mortal humans to
screw up DNS.
Also, on the helper programs ... I only wanted the invoking ID to be
able to make very certain specific changes to DNS records - the
validation records are of a very specific type and format, etc. I
could restrict the key a fair bit on that, but not fully to only and
exactly just the needed. So, I handle that via the helper programs and
a little bit of sudo. The ID doing the request never actually has
access to the key itself. Instead, via sudo, the key is used on its
behalf - and in program that further checks and restricts, such that
only and exactly needed validation data is added (and later removed) -
nothing else is allowed. Very feasible that way. Also, the helper
programs that add the DNS data - also checks that it's propagated to the
responding authoritative nameservers, before continuing (so it should
then pass letsencrypt.org's validation tests).
But back to, e.g. Pi.BerkeleyLUG.com. Were that to instead be done the
"old school" way of editing master zone file, would be quite
challenging to set something up that could only update DNS data for
that subdomain and subdomains thereunder ... but very easy to limit to
only and exactly that on dynamic DNS.
So, dynamic DNS updates ... already able to do multiple useful things
for me (and other(s)). :-)
"Joseph Perla" <joseph(a)jperla.com>
Ah, what listadmins get to deal with :-/ ...
(if anyone has constructive criticism on how this process/instructions
can be improved, feel free to chime in).
I'm sorry, "Joseph Perla" <joseph(a)jperla.com>,
but now you're getting annoying.
BALUG has over 800 list subscribers,
but alas, you're now the less than 1 in 800 that can't figure out
how to get the email address you have subscribed, unsubscribed.
The instructions from the list and web pages are pretty straight-forward.
I also specifically and personally emailed you and the email address
subscribed that's apparently getting that subscribed email to you,
relevant instructions. Yet it appears you still fail to follow those
instructions.
It ain't rocket science. I don't know how much more clear it can be.
There's a subscribed, opted in (probably double opted in) email address
that's receiving email from the list. Great. You say it's some catch-all
you can't sent from - whatever, not my problem, that doesn't prevent you
(or whomever controls that email) from unsubscribing.
By default, you even get monthly password reminder - you shouldn't share
that password with anyone (not even me) ... whatever, you also included it
in your email. So, okay, go to the web interface - you know what that
is, you know what Internet and browser and web are, right? Did you read my
email? Did you comprehend it? You put the subscribed email in the
box to unsubscribe ... don't have the password, you can request password
reminder, and it'll email it to you.
So, subscribed email address, password, web form, clicky-clicky, boom,
unsubscribed. With that, it's immediate, no email confirmation or
the like needed (I think it kicks out one final email that the email
address has been unsubscribed) ... and yeah, I just retested all that,
works 100% perfectly fine lickety split. So, ain't too damn hard,
just friggin' do it. If you can't handle that, give the email address
and password to someone else who might volunteer do do that for you - but
I'm not going to do that for you. Just do it - get it done - boom,
unsubscribed, not that hard.
If you can't figure out the instructions, maybe search on the web on how
to unsubscribe from a mailman list - probably a few zillion
examples/tutorials out there too - it ain't hard.
And if that "catch-all" email doesn't want to be unsubscribed, too bad
for them - they're apparently forwarding you the list email ... that
also allows you to control the subscription of that email ... that's just
the way it is. I have absolutely zero control of what email sent to
balug.org(a)jperla.com gets forwarded to "Joseph Perla" <joseph(a)jperla.com>
Not my problem, if you have issue with that, I suggest you take it up
with balug.org(a)jperla.com.
Sorry if this sounds frustrated, but well, it is.
I get too many of these kinds of darn emails (not frequently, but they do
occasionally keep coming up ... relentless occasional dribble/trickle).
If you've got useful criticism on how the instructions and such can be
improved, sure, send it.
If you can provide any diagnostics of where things are failing where they're
in fact nor functioning as they ought, great, please provide it - but you've
not done any of that.
You're basically just "please unsubscribe me".
No, it's self-serve - you (or balug.org(a)jperla.com) self-subscribed,
and have all the needed access to as, or even more easily, likewise
self-unsubscribe the balug.org(a)jperla.com address yourself. So,
please do so.
Hmmm, hey, I guess this isn't the best time to also put out a pitch,
Hey, who'd also like to also volunteer to be a list admin and deal with
emails from folks that can't read and follow instructions, on a recurring
basis?
> From: "Joseph Perla" <joseph(a)jperla.com>
> Subject: Re: BALUG list(s) unsubscribe
> Date: Sat, 02 May 2020 01:18:38 +0000
> It?s a catch all address and I can?t send email from it. Please unsubscribe
>
> On Fri, May 1 2020 at 6:16 PM, Michael Paoli <
> Michael.Paoli(a)cal.berkeley.edu > wrote:
>
>>
>>
>>
>> balug.org(a)jperla.com, [Cc: "Joseph Perla" <joseph(a)jperla.com>]
>>
>>
>>
>> (Also, "Joseph Perla" <joseph(a)jperla.com>, if your issue is with
>> balug.org(a)jperla.com sending/forwarding email to you that you don't want,
>> I suggest you take that up with balug.org(a)jperla.com, as balug.org has no
>> control over what balug.org(a)jperla.com does with their email).
>>
>>
>>
>> Subscribe/unsubscribe is completely self-service on BALUG lists.
>>
>>
>>
>> So, you should be able to fully take care of that yourself.
>>
>>
>>
>> See the reference information (links, etc.) provided further below.
>>
>>
>>
>> Note also:
>> o every list mailing contains URL(s) towards end of message body
>> to manage subscription(s) - including unsubscribing o in addition to the
>> above, every list posting sent also contains
>> unsubscribe information within the message headers (notably the
>> "List-Unsubscribe: " header contains information on how to
>> unsubscribe both via email and via URL)
>>
>>
>>
>> If that doesn't work for you, please provide: o The error diagnostic(s)
>> (if any) you're getting when you attempt to
>> unsubscribe.
>> o What steps you're following that result in the above (never tell me/us
>> nor anyone your list password, but otherwise provide relevant details) o
>> FULL EMAIL HEADERS of an example message that you're getting or still
>> getting that you're trying to unsubscribe from.
>>
>>
>>
>> Hopefully you should be able to self-unsubscribe, but if that fails,
>> please let us know, as noted above.
>>
>>
>>
>> Thanks for your attention to this and your cooperation,
>>
>>
>>
>> The busy BALUG / list administrator folks.
>>
>>
>>
>> See also / references / excerpts / hints:
>> https://www.balug.org/#Lists
>> https://lists.balug.org/cgi-bin/mailman/listinfo/balug-announce
>> https://lists.balug.org/cgi-bin/mailman/listinfo/balug-talk
>> https://lists.balug.org/cgi-bin/mailman/listinfo/balug-admin
>> https://lists.balug.org/cgi-bin/mailman/listinfo/balug-test
>> https://lists.balug.org/cgi-bin/mailman/listinfo
>>
>>
>>
>> references/excerpts (redacted):
>>
>>
>>>
>>>
>>> From: "Joseph Perla" <joseph(a)jperla.com> Subject: Re: lists.balug.org
>>> mailing list memberships reminder Date: Fri, 01 May 2020 06:14:36 +0000
>>>
>>>
>>>
>>> Please remove balug.org(a)jperla.com I cannot.
>>>
>>>
>>
>>
>>
>> >
>>
>>
>>>
>>>
>>> On Thu, Apr 30 2020 at 10:00 PM, < mailman-owner(a)lists.balug.org > wrote:
>>>
>>>
>>
>>
>>
>> >
>> >>
>> >>
>> >>
>>
>>
>>>
>>>>
>>>>
>>>> This is a reminder, sent out once a month, about your lists.balug.org
>>>> mailing list memberships. It includes your subscription info and how to
>>>> use it to change it or unsubscribe from a list.
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> >>
>> >>
>> >>
>>
>>
>>>
>>>>
>>>>
>>>> You can visit the URLs to change your membership status or configuration,
>>>> including unsubscribing, setting digest-style delivery or disabling
>>>> delivery altogether (e.g., for a vacation), and so on.
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> >>
>> >>
>> >>
>>
>>
>>>
>>>>
>>>>
>>>> In addition to the URL interfaces, you can also use email to make such
>>>> changes. For more info, send a message to the '-request' address of the
>>>> list (for example, mailman-request(a)lists.balug.org) containing just the
>>>> word 'help' in the message body, and an email message will be sent to you
>>>> with instructions.
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> >>
>> >>
>> >>
>>
>>
>>>
>>>>
>>>>
>>>> If you have questions, problems, comments, etc, send them to
>>>> mailman-owner(a)lists.balug.org. Thanks!
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> >>
>> >>
>> >>
>>
>>
>>>
>>>>
>>>>
>>>> Passwords for balug.org(a)jperla.com:
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> >>
>> >>
>> >>
>>
>>
>>>
>>>>
>>>>
>>>> List Password // URL
>>>> ---- -------- balug-announce(a)lists.balug.org [REDACTED]
>>>> https://lists.balug.org/cgi-bin/mailman/options/balug-announce/balug.org%40…