[BALUG-Admin] linuxmafia.com & SPF (was: BALUG & SPF)
Rick Moen
rick@linuxmafia.com
Mon Aug 21 11:36:36 PDT 2017
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.
More information about the BALUG-Admin
mailing list