[BALUG-Admin] balug.org DNS review

[Michael Paoli]

comment/response bits in-line ... and rearranged a bit ...

> From: "Rick Moen" <rick@linuxmafia.com>
> Subject: Re: [BALUG-Admin] balug.org DNS review
> Date: Wed, 27 Sep 2017 10:44:42 -0700

Thanks for the analysis!  :-)

> I believe the SPF records for 'temp.balug.org' should now be amended to
> say it originates no mail.

On that one, I may take the lazy/efficient way out ... or might update
it.  As I did already update it a bit ago (latter half of last week
or so?) to hard fail any illegitimate sending IPs, and also in that
temp.balug.org. is intended to be temporary and aimed to go bye-bye
~2017-11-30 - along with all RRs for it, including any A and/or AAAA
records, etc., I'm kind'a inclined to leave the SPF data for it
as it is, and just drop the whole subdomain at the appropriate time
and be done with it.  As the soft-fail was earlier changed to hard-fail,
it's pretty well covered - only additional coverage would be for the
improbable illegitimage generation of @temp.balug.org email from the
legitimate IPs.  Sufficiently improbable I'm quite unconcerned about
that - and even if it were to happen somehow, the SPF data wouldn't be
the biggest of my concerns.

> 4.  SPF records exist to accompany 'A' records for 'balug.org.',
> 'lists.balug.org.', and 'temp.balug.org', but not for any of the other
> 'A' records.  Given that those FQDNs do not originate mail, it's a very
> good idea to have an SPF declaration for each that says it doesn't
> originate mail.

Uhm, ... but if, e.g. one has hundreds or thousands of more A (and/or AAAA)
records for a domain, would one do SPF data records for all of 'em?  I
think not.  I think, to a large extent, ample mitigating control is
those records not only don't originate email, but won't accept to those
domains ... e.g. anything that bothered to check if
postmaster@some_semi-random_RR-subdomain.balug.org or any other
localpart at same domain would accept email, even if the IP accepts
connection on TCP port 25, SMTP server would basically say "hell no,
not that domain!".  Yes, I know, not as simple as SPF declaring "no",
on such, but ... as opposed to the DNS bloat of adding SPF data for
all non-SMTP A and AAAA records ... yeah, I'm guestimating best practice
isn't to add SPF data records for all those?  Maybe/probably, if/as
applicable the relative top domain(s) ... e.g. @balug.org (if that
were non-sending - but in our case it does actually send).
Hmmmm, I though we had some earlier communication regarding that
general question as to what A and AAAA records ought also have
relevant SPF records ... and for which one would be better off not
adding such.  Curious if anyone has pointers to a well vetted
"best practice" regarding that question.