Just checking on things, in the wake of the departure from Dreamhost.
1. We have three nameservers. This is in the recommended range, barely: RFC2182 section 5 recommends at least 3. RFC1912 section 2.8 recommends no more than 7.
If we have one or two more friends running auth nameservers, adding them would be gravy.
2. No glue records for one nameserver (ns1.linuxmafia.com), because it is out-of-bailiwick for the .org TLD nameservers. This means queries to it are just a little slower than to the other two for which glue information gets supplied.
If you want to fix that, assign my nameserver IP (198.144.195.186) the name NS2.BALUG.ORG in the domain record, removing the entry for NS1.LINUXMAFIA.COM. That fixes the glue records at the parent (.org) zone. And then don't forget to make the same switch in the in-zone records served at master nameserver NS1.BALUG.ORG.
3. Information leakage. NS1.BALUG.ORG / 198.144.194.238 answers (correctly) CHAOS class queries about its version.
:r! dig version.bind txt chaos @NS1.BALUG.ORG +short "9.9.5-9+deb8u14-Debian"
It'd be a good idea to turn this off. I like to return amusing lies, myself. My stanza in /etc/bind/named.conf.options :
options { directory "/var/cache/bind"; version "Shirley, you're joking"; hostname "ns1.linuxmafia.com"; //server-id is essentially redundant to hostname, default is none //server-id none; auth-nxdomain no; # conform to RFC1035 allow-recursion { [redacted] }; allow-query { [redacted] }; dnssec-validation yes; };
Other than that, it looks good.
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.
I believe the SPF records for 'temp.balug.org' should now be amended to say it originates no mail.
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.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
I'm kind'a inclined to leave the SPF data for it as it is...
Your call. The general principle is: If the 'A' record doesn't originate mail, it's in your interest to make the DNS say so, in order to prevent spammers from believably forging it as a sender.
I personally care about the reputation of my FQDNs, including those that don't send 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 would. It's one line of sed.
Funny thing, that. Practically every bad DNS zonefile idea I hear defended, gets defended on the basis that there's too many records to change -- especially the 'I used CNAME when I shouldn't have' bad idea.
And in every single case I've encountered so far, the alternative maintenance regime and the correction regime, is one line of sed.
But hey, if you don't mind spammers believably forging those hostnames as senders of spam, and intend to deal with the misdirected complaints, sure, go right ahead and don't bother.
And, I will point out, you do _not_ have hundreds or thousands of 'A' records to deal with.