[sf-lug] SF-LUG (& BALUG) DNS, etc.

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> There definitely were (and likely still are) some SNAFUs to be corrected
> (and things caught up, etc.) with the SF-LUG and BALUG related machine
> shuffling that happened 2009-11-11.

No worries.  I was just a bit alarmed that apparently the master DNS had
moved and the secondaries not notified at all by several days later,
which suggested that there might be other things needing nailing down.

> This is also an area where SF-LUG could benefit from some appropriate
> monitoring (e.g. Nagios) 

Yep.  Meanwhile, I actually have a lazy-ass way of getting a weekly
report via cron.  There are all _sorts_ of ways it can be improved, but
the point is that it's easy enough that I could implement it in five
minutes, and works to a basic degree, and is _actually implemented_, as
opposed to a perennial "Oh, we should implement monitoring one day"
wishlist.

This is one of the key lessons of system administration:  The
good-enough if half-assed solution that you actually do is better than
the really good one that you never get to. 


:r /etc/cron.weekly/mydomains


#!/bin/sh

# mydomains     Cron script to sanity-check my domain's SOA records at
#               all of its authoritative nameservers, as a quick and 
#               dirty way of making sure (1) they're all online and
#               (2) they're all serving up the same data (or at least
#               data with the same zonefile serial number).
#  
#               The script queries all five nameservers for their current
#               SOA value (for linuxmafia.com), and then uses awk to parse 
#               out of that verbose record just the S/N field, which is 
#               field #3.  The point is that you can visually spot offline 
#               or aberrant nameservers by their S/Ns being (respectively) 
#               missing or an out-of-step value.
#
#		Written by Rick Moen (rick at linuxmafia.com)
#		$Id: cron.weekly,v 1.01 2009/05/19 20:18:05 rick

set -o errexit  #aka "set -e": exit if any line returns non-true value
set -o nounset  #aka "set -u": exit upon finding an uninitialised variable

test -x /usr/bin/mail || exit 0

dig -t soa linuxmafia.com @NS.PRIMATE.NET +short | awk {'print $3'} > /tmp/domains
dig -t soa linuxmafia.com @NS.TX.PRIMATE.NET +short | awk {'print $3'} >> /tmp/domains
dig -t soa linuxmafia.com @NS2.LINUXMAFIA.COM +short | awk {'print $3'} >> /tmp/domains
dig -t soa linuxmafia.com @NS1.THECOOP.NET +short | awk {'print $3'} >> /tmp/domains
dig -t soa linuxmafia.com @NS1.LINUXMAFIA.COM +short | awk {'print $3'} >> /tmp/domains

test -e /tmp/domains || exit 0

/usr/bin/mail -s "Domain linuxmafia.com SOA check" rick at linuxmafia.com < /tmp/domains




[domain record:]

> Yes, a single person as point of contact is generally bad.  

Name one where it's a _good_ idea, please.  

> Typically better to have multiple, and where feasible, use out-of-band
> (e.g. role based) alias(es) that have zero dependencies upon the DNS
> in question.      ^^^^^^^^^

No.  And BALUG should have already learned this lesson, when it got bit
by that mistake before.

When I eventually get around to writing my follow-up article about how
to do master authoritative DNS nameservice _well_, e-mail aliases
will be one of my top "seem like good ideas, but lead to diaster"
items.  There are two reasons:

1.  An e-mail alias in the WHOIS records constitutes a hidden mechanism
for redirection, such that the only people who can easily notice and
figure out breakage are the relative few people who have and use shell
access on the machine where the alias is defined.  A few years ago,
SVLUG nearly lost the svlug.org domain because Heather Stern, who
through a chain of bad-faith politics on the part of the domain
custodian had been (against the SVLUG president's orders) been given
domain ownership, against my advice defined all of the domain contacts
as mail aliases within her starshine.org domain.   Nobody but her knew
where the aliases pointed for the following year, and eventually nobody
knew that she'd inadvertantly broken those aliases during a machine
migration, so SVLUG didn't get the renewal notices -- exactly as I'd
warned.

Fortunately, anticipating the problem, I had been independently
monitoring the domain's expiration status, and paid for the renewal,
myself, at the last minute out of my own pocket.

As I mentioned, BALUG _should_ have already learned the above lesson,
from when it used a "role" e-mail address -- against my advice -- for 
the listadmin role on the BALUG mailing list.  I had insisted on my
listadmin participation -not- involve an alias, but rather my direct
address, so I kept getting notices -- but I discovered through sending
test e-mails that the _other_ listadmin e-mail address (alias) was
reaching nobody because (if memory serves) of changes at the mailbox to
which it redirected.

I'm disappointed to see this bad idea resurface.  It's a bad idea for
list administration; it's a bad idea in domain records for the same
reason.


2.  In 2009, mail reflected between SMTP systems via /etc/aliases or
~/.forward files has strong likelihood of rejection or deprecation
(classification as spam) by receiving mail systems, because it looks
like a forgery on account of the resulting mismatch between envelope
headers and internal "From:" headers.   (The above is true unless you
use a rewriting scheme like SRS,
http://en.wikipedia.org/wiki/Sender_Rewriting_Scheme.)

By contrast, mailing list manager software differs in that it updates
the envelope headers when it remails, and the perception of forgery is
avoided.


> "We" do in fact have an email alias for SF-LUG systems administrators
> that has zero DNS dependencies upon SF-LUG.COM. - that could
> potentially be used.

Well, for the love of all that's holy, learn from the past and DON'T DO
THAT.  

I frankly suspect that the "let's use an alias for list administration
roles" bad idea might have been one of yours, but, at bare minimum, you
were involved when it happened.  C'mon, Michael!  For gosh sakes, can't
we at least make _new_ mistakes?