Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Thanks for the updates/corrections. :-) Yeah, I kind'a suspected you might'a been a bit fatigued or something, or forgotten some of the details of exactly the situation BALUG has been in and still is regarding DNS & DreamHost.com ... but *fairly* soon that should change and be *much* better! :-)
That was part of it, and the other part was that I implemented SPF ages ago (2010, I think) on linuxmafia.com for that domain's very mimimal needs and simple situation -- and over the years since became fuzzy about the mechanics of that standard, simply overextrapolated its application to subdomains, whereas by intention an SPF RR's effect does _not_ flow down automatically to subdomains [/hosts] of a base domain.
And good point also about using SPF to effectively say "this domain never originates email, hard fail anything that claims to be from such" for relevant (sub)domain(s).
Which brings me to the point of this mail: I just now implemented that, and herewith present my current zonefile, as revised:
:r /etc/bind/linuxmafia.com.zone
$TTL 86400 $ORIGIN linuxmafia.com. @ IN SOA ns1.linuxmafia.com. rick.deirdre.net. ( 2017082101 ; serial 7200 ; refresh 2 hours 3600 ; retry 1 hour 2419200 ; expire 28 days 900 ; negative TTL 15 mins ) ; IN NS ns1.linuxmafia.com. IN NS ns3.linuxmafia.com. IN NS ns1.thecoop.net. IN NS ns.primate.net. IN NS ns.tx.primate.net. IN A 198.144.195.186 IN MX 10 linuxmafia.com. IN HINFO P3/500 Linux-v.2.4.24 IN TXT "v=spf1 ipv4:198.144.195.186 -all" LOC 37 25 53.825 N 122 11 52.128 W 15m uncle-enzo IN A 198.144.195.186 LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" enzo IN A 198.144.195.186 LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" mail IN A 198.144.195.186 LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" www IN A 198.144.195.186 LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" ftp IN A 198.144.195.186 LOC 37 25 53.825 N 122 11 52.128 W 15m IN TXT "v=spf1 -all" ns1 IN A 198.144.195.186 IN MX 10 linuxmafia.com. LOC 37 25 53.825 N 122 11 52.128 W 15m ns3 IN A 198.144.209.73 IN TXT "v=spf1 -all" ; ns3 is aka ns.catwhisker.org, David Wolfskill's box water IN A 198.144.195.188 IN TXT "v=spf1 -all" wap IN A 198.144.195.187 IN TXT "v=spf1 -all" nsa IN CNAME bxa.doc.gov. sf-lug IN A 198.144.194.238 IN TXT "v=spf1 -all"
Yes, I still use BIND9, though I disrecommend it. For all new authoritative nameservers, I recommend NSD. For all new recursive nameservers, I recommend Unbound. (For very large sites, the two corresponding packages of the PowerDNS suite are often better, if you don't mind dealing with databases.)
A few points about style and content: I add comment lines where absolutely essential for clarity and in one place (after the SOA) for spacing. The $ORIGIN line is not actually needed and present in my zonefiles merely as syntactic sugar, so that you can see at a glance what zonefile you're in. Woe betide you putting the _wrong_ $ORIGIN in a zonefile via copying an old zonefile to create a new one and forgetting to change that line. I might be better off on balance using a comment line instead.
The alias 'ns3.linuxmafia.com' for David Wolfskill's ns.catwhisker.org is a fine point of DNS performance. It's about bailiwick. Any recursive nameserver asking about linuxmafia.com's NS record will get the answer to those queries plus 'ADDITIONAL SECTION' glue-record answers not specifically requested stating the corresponding 'A' records for the NS ones -- but only when the request is inside the bailiwick of the TLD nameserver giving the answer. com. is outside org.'s bailiwick. Therefore, giving David's org. nameserver an alias within com. and using that saves lookups.
At the time I did that, the same TLD nameservers handled both com. and net., so glue records for ns1.thecoop.net, ns.primate.net, and ns.tx.primate.net were returned on 'ns' queries about linuxmafia.com . In checking today, I see something must have changed, as that is no longer true:
~ $ dig -t ns linuxmafia.com @ns1.linuxmafia.com ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34722 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 2
;; ANSWER SECTION: linuxmafia.com. 86400 IN NS ns.primate.net. linuxmafia.com. 86400 IN NS ns.tx.primate.net. linuxmafia.com. 86400 IN NS ns1.thecoop.net. linuxmafia.com. 86400 IN NS ns3.linuxmafia.com. linuxmafia.com. 86400 IN NS ns1.linuxmafia.com.
;; ADDITIONAL SECTION: ns1.linuxmafia.com. 86400 IN A 198.144.195.186 ns3.linuxmafia.com. 86400 IN A 198.144.209.73
[rick@linuxmafia] ~ $
As a later date, I will probably alias those three as ns2.linuxmafia.com, ns4.linuxmafia.com, and ns5.linuxmafia.com, so that automatic glue record delivery for those will happen again, and nameservers querying my five NS (auth nameserver) lines in-zone will no longer then have to turn right around and do separate 'A' record lookups for three of them before being able to use the 'NS' answers.
(In case you're curious, there used to be an ns2.linuxmafia.com, pointing to David's old IP for ns.catwhisker.org. He notified me of its pending replacement with a new IP so I listed the new one as ns3, then eventually removed the vestigial ns2 entry when that IP went away.)
All of the SOA subfield values and the global $TTL value are squarely inside RFC-recommendation ranges. People very, very often get those wrong, whcih is one reason why since the 1990s I've published my zonefile and BIND9 conffiles as a downloadable tarball, to help people have a model to follow if they wish.
The 'rick.deirdre.net' of course means 'rick@deirdre.net' as an SMTP mailbox, and is the public point of contact in case people need to inquire with the zonefile maintainer. Note that it is carefully out-of-band for the domain (and indeed for the host handling my mail), routed to my wife Deirdre's domain. Ensuring out-of-band contact is another thing people often screw up, both here and in domain whois contacts. It's a bit sad when you cannot be told 'Dude, there's a problem with your zonefile [/domain]' because there's a problem with your zonefile [/domain].
Note that there are five auth nameservers. RFC-2182 section 5 recommends minimum 3, maximum 7. Mine are network-diverse and across different portions of the national power grid, e.g., at least one of the primate.net ones is in Texas. (Why? Because avoiding SPoFs is at least as important a principle as ensuring out-of-band reachability about problems with the things in question.)
The HINFO (host info) and LOC (location) records are because why not? The HINFO record's kernel declaration is now intentionally misleading, though, because I've become wary of advertising certain version information -- including also nameserver details queried from the abstract CHAOS class:
:r /etc/named/named.conf.options
options { [...] version "Shirley, you're joking"; hostname "ns1.linuxmafia.com"; //server-id is essentially redundant to hostname, default is none //server-id none; [...] }; [...]
The LOC data is a completely accurate set of longitude, latitude, and altitude specs. Some people go out of their way to hide. I go out of my way to ostentatiously _not_ hide, because I'll be damned if I obscure where in the world I live and compute. I call it my 'ICBM address', and it also appears in human-readable form on my personal Web page.
water.linuxmafia.com is my OpenSprinkler Arduino device controlling the drip irrigation and lawn watering for my property. It has an admin WebUI. (No, I'm not giving out the access password.)
wap.linuxmafia.com is my LinkSys wrt54g WAP running OpenWRT, powered on only during CABAL meetings.
Notice that nsa.linuxmafia.com is my _only_ CNAME record. Newcomers to DNS tend to horribly overuse the CNAME RR and for bad reasons, creating long-term problems for themselves. My rule of thumb is to _never_ use a CNAME for intra-zone references. That use-case and can should be an 'A' record, instead -- saving double-lookups and avoiding future maintenance errors.
What is nsa.linuxmafia.com for? In 2000, when the Federal government semi-gracefully surrendered to Daniel J. Bernstein's ongoing lawsuit asserting the right to export strong crypto, a new Commerce Department Export Administration Regulations (EAR) rulemaking suddenly permitted the strong-crypto export that existed anyway, but required any USA Internet sites intending to offer strong-crypto for export to notify Commerce Department Bureau of Export Administration at crypt@bxa.doc.gov . My alias was on the one hand a convenience so I didn't have to remember 'bxa.doc.gov' and could just e-mail crypt@linuxmafia.com, and on the other hand also a small joke about Federal stupidity.
(Reference: https://epic.org/crypto/export_controls/regs_1_00.html I have no idea if that EAR is still theoretically in force, but FWIW I only ever sent the one 'Hey, linuxmafia.com is offering strong crypto for public ftp and Web access, bye!" mail, which was all that was to my knowledge ever required.)
sf-lug.linuxmafia.com is of course the BALUG/SF-LUG Web host. I believe I created that RR at a time, long ago, when SF-LUG's DNS was on the fritz. Normally, that would be a CNAME, being cross-domain. I probably should lose it.
And last, of course, you will note that every 'A' DNS reference record (RR) that is _not_ my outgoing mail server now has an accompanying SPF RR saying 'this FQDN never originates mail, so please consider any mail claiming to come from it forged.'
And ... type SPF & TXT, or ... just TXT or just SPF? Yeah, I'm curious about current status on that ...
The dedicated SPF RR does exist as an IETF spec. Among the problems with it is that, if one of your slave auth nameservers runs nameserver software, that doesn't know how to handle a dedicated SPF RR encounters it, or a recursive software package unable to handle one receives it, then you could have problems, whereas any nameserver will correctly onvey as literal text a TXT record. And, of course, MTAs if they check SPF at all will know to query TXT, but it's less likely that they'll know to check dedicated SPF RRs.
So, the smart money say, just use TXT. Adding a decicated SPF RR if you already have a TXT one buys you nothing[1] and exposes you to potential problems from (at least) slave nameservers that might not know how to handle one. So, no obvious gain, possible downside, don't bother.
The above perception being widely held among DNS maintainers has further discouraged use of the dedicated SPF RR, creating a vicious cycle against it.
[1] You might say 'prevents the need for an MTA / MTA-helper to do two lookups'. I'll believe that when I see evidence of such software checking SPF RR first and then falling back to TXT.