First half day of SPF tests from my domain...

Folks,

	Last week I shamelessly copied the spf record of Altavista into my  
home domain. Yesterday, I finally got around to turning it on. Here are  
the results after about 14 hours of testing.

The main DDG.com spf record is:
DDG.com        IN      TXT     "v=spf1  
+exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.ddg.com mx a -all"

It was the record typically fetched by the three joe-jobs working my  
domain yesterday:

Aug 11 18:20:17.922 queries: client 204.31.203.2#2047: query: ddg.com  
IN MX
Aug 11 18:20:19.011 queries: client 204.31.203.2#2047: query: ddg.com  
IN TXT
Aug 11 18:20:19.315 queries: client 204.31.203.2#2047: query:  
CL.220.118.128.254.FR.preciselybdrb\@ddg.com.HE.220.118.128.254.null.spf 
.ddg.com IN A
Aug 11 18:20:19.772 queries: client 204.31.203.2#2047: query: ddg.com  
IN A

The first query went about as planned - get the MX, get the TXT, query  
for test domain, query for A record. I am confused that there was no  
query for the A record for the target of the MX record. If things are  
processed in a left to right order, I would expect that query before  
the bare A query. Perhaps tomorrow, after the 24 hour TTL has expired,  
I will see the behavior I expect.

Aug 11 20:28:01.649 queries: client 213.180.192.168#5301: query:  
FW.ddg.com IN AAAA
Aug 11 20:28:01.858 queries: client 213.180.192.168#5301: query:  
ddg.com IN TXT
Aug 11 20:28:02.152 queries: client 213.180.192.168#5301: query:  
CL.218.147.45.45.FR.roi87iedfl3c\@ddg.com.HE.218.147.45.45.null.spf.ddg. 
com IN A
Aug 11 20:28:02.378 queries: client 213.180.192.168#5301: query:  
ddg.com IN A
Aug 11 22:07:02.134 queries: client 213.180.192.168#5301: query:  
CL.195.54.209.145.FR.xkc78\@ddg.com.HE.bdsm.cust.rinet.ru.null.spf.ddg.c 
om IN A
Aug 12 00:14:54.605 queries: client 213.180.192.168#5301: query:  
CL.217.23.17.186.FR.1evfcignz\@ddg.com.HE.adm.step.nnov.ru.null.spf.ddg. 
com IN A
Aug 12 07:24:38.489 queries: client 213.180.192.168#5301: query:  
CL.81.22.2.178.FR.6d4mr\@ddg.com.HE.ddg.com.null.spf.ddg.com IN A

The above represents three separate joe-job attempts on yandex.net.  
Notice that the ddg.com A record is cached. The final null.spf query  
shows signs of DNS spoofing. Is there is no PTR record for a sender,  
then the HE field will have the numeric IP address. Notice that it  
claims to be the reverse for ddg.com (which really is either  
FW:66.93.83.221 or Mail:66.93.83.131).

Aug 11 18:48:57.682 queries: client 194.67.21.67#32768: query: ddg.com  
IN MX

Aug 11 19:43:17.404 queries: client 194.67.21.69#32768: query: ddg.com  
IN MX
Aug 11 19:43:18.211 queries: client 194.67.21.69#32768: query:  
CL.201.135.197.190.FR.x6cb0e\@ddg.com.HE.dsl-201-135-197-190.prod- 
infinitum.com.mx.null.spf.ddg.com IN A

Aug 12 00:33:08.781 queries: client 194.67.21.74#32768: query: ddg.com  
IN MX
Aug 12 00:33:09.572 queries: client 194.67.21.74#32768: query:  
CL.201.135.32.91.FR.iywrgs38x\@ddg.com.HE.dsl-201-135-32-91.prod- 
infinitum.com.mx.null.spf.ddg.com IN A

Aug 12 07:12:10.634 queries: client 194.67.21.68#32768: query: ddg.com  
IN MX


The above set of queries look to be incomplete. I expect the cache at  
net.rol.ru is masking these effects.

Enjoy the data. I'll post more in the next few days.

Andrew
____________________________________
Andrew W. Donoho
[email protected], PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)