[sf-lug] Documenting(?): Re: SF-LUG zones now using dynamic DNS

Michael Paoli Michael.Paoli at cal.berkeley.edu
Wed Mar 11 20:25:10 PDT 2020


Good points.  :-)

And where might you suggest documenting such?

For (perhaps?) lack of better, I might think on BALUG's
wiki:
https://www.balug.org/wiki/doku.php?do=index
Perhaps under the "system" namespace,
and perhaps also with a cross-reference from the
SF-LUG Resources, etc.:
https://www.balug.org/wiki/doku.php?id=sf-lug:resources_etc
wiki page.

Got better idea/location (and in the context of what resources
and infrastructure BALUG/SF-LUG do/don't have?)

I'm also thinking, would have relevance to more than just
SF-LUG, as there's also infrastructure for
pi.BerkeleyLUG.com to be able to make DNS changes.

Maybe once "we"(/I?) figure out where, maybe I can get some
volunteer(s) do well document it.  :-)  (Why do I suspect
I'd hear crickets?)

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] SF-LUG zones now using dynamic DNS
> Date: Wed, 11 Mar 2020 13:57:16 -0700

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> For those that may be interested/curious,
>> The DNS master for the SF-LUG zones, is now using dynamic DNS
>> for the SF-LUG zones.
> [...]
>
> And here were my comments in response to Michael's mailing to the admins:
>
> From: Rick Moen <rick at linuxmafia.com>
> To: Michael Paoli <Michael.Paoli at cal.berkeley.edu>
> CC: [REDACTED]
> Subject: Re: SF-LUG DNS editors: SF-LUG zones now using dynamic DNS
>
> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> Dear SF-LUG DNS editors,
>
> Any chance the gist of this might be made available as some sort of process
> cheatsheet, that can be consulted when coming in to do work?  Otherwise,
> when you send the present assembled this sort of long account in e-mail,
> it lands into... saved e-mail, the worst possible place for important
> documentation, because you have essentially no hope of re-finding it
> when you need it, even if you can remember it's in saved mail somewhere
> (which isn't assured).
>
> When I say 'process cheatshet' (or 'process documentation'), I mean, in
> essence, a checklist the sysadmin can easily and naturally find to
> consult in real time when doing sysadmin work.  E.g., and I feel like
> I've made this point and cited this example before, on SVLUG's machines
> there is a 'site-docs' directory containing numerous
> process-documentation ASCII files for common tasks, _and_ every local
> user's homedir gets (via /etc/skel/) a 'site-docs' symlink pointing to
> that directory so it's always easily findable when needed.
>
> Short of that, I gather we're left to ssh in, run 'sudo -l', and guess what
> those various permitted commands are good for and what the expected and
> traditional workflow is.
>
> Like, for example:
>
>> o editing zone file - with some additional pre/post steps
>>
>> Using dynamic update.  The sudo access allows one to execute nsupdate as
>> group bind, and with that group bind access, access the requisite key
>> that can be used to edit those zones.
>>
>> Editing zone file.  To be reasonably assured that will work properly,
>> (via sudo) use rndc freeze (on the specific zone) before editing the
>> zone file, and after successfully editing the zone file, likewise
>> use rndc thaw (on the specific zone, and again via sudo).
>> To make things easier, I also coded up:
>> /usr/local/bin/sudoeditzone
>> /usr/local/bin/sudoeditzones
>> (both those are same program and file)
>> Those programs take argument(s) of the requisite zone(s),
>> and handle the requisite pre/post steps, in addition to doing
>> relevant checks.  (They're world readable, so one may certainly review
>> them).
>
>
> I'd not be able to remember on the spur of the moment, when suddenly
> obliged to edit a zonefile, _any_ of the above.  (I understand
> freeze/thaw by reading up just now, but those operations are new to me
> because I've successfully avoided DDNS until now.)
>
>> Also note, that comments generally are no longer preserved, as dynamic
>> DNS is in use - effectively comments will end up stripped, the data
>> reformatted, and BIND9 will add its standard commenting on (some select
>> bits of) the data.
>
> Comments automatically stripped from zonefiles: ugh!  That's a real
> shitshow.  (Totally not your fault, of course, but a sign of an ugly
> implementation of an ugly hack, referring of course to DDNS.)
>
> Everywhere else I maintain zonefiles, I consider appropriate use of
> comment lines and of blank comment lines for spacing, to be essential to
> clarity and documentation.




More information about the sf-lug mailing list