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.
- 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.