Thanks for the excellent howto!
Suggested additions for the howto (or its Q/A section)
1. Do you need your own DNS server?
A. Yes. Specifically, the DNS server needs to be able to log queries sent to
it, and you will eventually need to get access to that data to do your
analysis.
2. Do you need a specific zone (sub-domain delegation) just for exists?
A. No, but you would need a delegation if you want to use a different server
than the one (ones) serving the parent domain. For example if you don't
publish NS records for spfchecker.example.net, the queries will go to the same
DNS server as example.net. This may be fine for what you want.
Reasons you might want a subdomain include:
- Your domain gets a lot of queries (like a high-traffic website) and you
only want to log queries related to the SPF exists: clause. Delegate the
subdomain to another server and only turn on logging for that one.
- Your domain has many NS records pointing to many servers and you don't want
to collect logs from many locations. Delegate the subdomain to only one
server. If that server is down, the exists: clause will fail and processing
should continue with the next term in your SPF record. That means you would
lose logging/tracking info but it shouldn't alter mail delivery (unless you
have actually populated the tracking zone with some data)
3. Does the exists: clause have to refer to the same domain as the SPF record?
A. No, you can write the exists: clause using any domain suffix you want.
(Thanks to Alex for the suggestion.) This is especially helpful if you are
able to add TXT records but you can't add NS records to do delegations. Also
this is a great idea for organizations that control hundreds or thousands of
domains and want to track SPF results for all of them without creating
hundreds or thousands of sub-domain delegations.
4. Does the domain mentioned in exists: have to be populated with data? Will
the domain ever exist, and will the exists: clause ever result in a Pass?
A. No, the zone you use for tracking doesn't need to be populated with any
data (other than NS and SOA if you are using a sub-delegation as mentioned
above). It is expected that the exists: query will return "no such domain"
(NXDOMAIN) result and won't pass.
Where you put the exists: in your SPF record determines whether you will get
all the queries for all SPF checks (if exists: appears first) or just the
queries indicating the check is about to fail (if exists: comes right before
?all or -all).
Extra credit section:
Some users might want to return some data to the exists: query. For example,
you may want some local users to be exempt from SPF's sending restrictions,
which can be done by supplying a wildcard entry that matches those queries.
It's probably better (less confusing and error-prone) to do this as a separate
exists: clause before the logging one, since then you can remove the logging
clause later with no other changes. (Also, if you have delegated the logging
subdomain to just one server, and that server goes down, this could change
email delivery and cases that you want to pass via this method may fail. Any
exists: entry that you might use to allow certain patterns through should
probably be assigned to redundant name servers.)
Really advanced SPF users may use similar techniques to set up a "stunt DNS
server" that serves dynamic data instead of static data. For example, if you
use a perl program based on Net::DNS::Nameserver instead of a traditional DNS
program, you could set up a perl program that returns A records the first 10
times a valid return address (or client IP) is used, then switches to
returning no results after the limit is reached for a certain return address
(or IP). This would allow a roaming user to send several messages from a
hotel but would stop spammers using fake local names and shut down spoofing of
valid names after a short period of time. If you're going to the extra effort
of tracking which local names or sending IPs have been seen before, you can
also arrange for more organized logging or even email notifications to the
administrator if you like.
--
Greg Connor
gconnor(_at_)nekodojo(_dot_)org
Everyone says that having power is a great responsibility. This is a lot
of bunk. Responsibility is when someone can blame you if something goes
wrong. When you have power you are surrounded by people whose job it is
to take the blame for your mistakes. If they're smart, that is.
-- Cerebus, "On Governing"