spf-discuss
[Top] [All Lists]

Re: HOWTO: track SPF requests to see who says to be you

2004-11-30 16:30:14
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"