[sf-lug] SF-LUG zones now using dynamic DNS

[Rick Moen]

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.