Re: Re: DNS load research

Terry Fielder wrote:
> Radu Hociung wrote:
> <snip>
>
> > It would be very nice if those named above responded with:
> >
> > 1. Do you run your own SMTP server ?
>
> Yes
>
> > 2. Do you host your zone on your own DNS server ?
>
> Yes
>
> > 3. Do you run or administer your own MTA-based spam solution?
>
> Yes
>
> > 4. What is the nature of your experience in the world of SMTP and DNS?
>
> If you have the resources to setup an SMTP server, you have the 
> resources to setup your own DNS cache.
> > Of course one can easily find if mail goes to some outsourced service, 
> > and if the DNS queries go to some public DNS service.
> > Maybe a good way to make people aware of the load they put on other 
> > peoples's DNS servers would be to start an "SPF hall of shame". I know 
> > just enough about PHP and MySQL to make this happen. Anyone else 
> > willing to help?
> I am not sure what you are trying to accomplish here, but it smells like 
> a witch hunt for ___ (still trying to figure out what the witchhunt is 
> for, people who don't have a problem with DNS load increase being a part 
> of SPF?  Why?  Have you ever checked to see the impact clients running 
> SpamAssassin have on your DNS?  I'll give you a hint: checking DNS 
> blacklists not only increase DNS traffic *per workstation*, but the 
> traffic usually has very low timeouts (the nature of blacklists) and so 
> caching is minimal.  SPF queries on the other hand are cached for normal 
> times, usually upwards of hours or a couple days before a refresh is 
> required).
> My DNS record includes a couple ISP's whom I know my users send emails 
> from without SMTP AUTH.  Yes, my servers support SMTP AUTH.  Yes, all my 
> remote users should be using SMTP AUTH.  Yes all new laptops are rolled 
> out with SMTP AUTH..  No, in the short term I don't have time to visit 
> all the executives houses to ensure a retrofit of SMTP AUTH to prevent 
> SPF FAIL.  So for the short term including the relevant ISP's is a short 
> term workable solution.
Hello Terry,

Thank you for responding to my survey.

I said Maybe because I'm not sure myself that a witch hunt is the right 
method to raise awarness. So far most people seem very much receptive to 
suggestions for improvements.
I don't use SpamAssassin myself. There are plenty of companies that use 
content-based filtering like Brightmail, Bayesian filters, etc. If they 
were to add SPF checking, their DNS load might go up several folds (from 
1-2 queries per email to the SPF lookup limit).
If this increase in load is significant, these companies would be 
reluctant to check SPF records, and probably even to publish their own 
records.
I'm not suggesting you should beat on your users or change the way your 
domains are used, but there are a few changes to your record that would 
save recipients a few queries. Even with a DNS cache, like you said, the 
data still needs to be re-fetched every so often, depending on the TTL 
set by the publisher. I think the default TTL is 1 day, so most DNS 
information out there is only refreshed that often.
Currently your SPF record is:

   "v=spf1 ip4:209.91.136.161/28 ip4:216.191.52.64/27 a mx ptr
     a:mail.ashtonwoodshomes.com include:rogers.blackberry.net
     include:blackberry.net include:rogers.com include:vianet.ca
     include:bellnet.ca -all"

Would it be possible for you to replace the following mechanisms
with their IP4 equivalents? They appear to be under your control:

- a
- mx
- mail.ashtonwoodshomes.com

With these changes, your record's DNS cost would drop from 11 down to 7.

spfcompile shows the following record as equivalent:

    "v=spf1 ip4:209.91.136.161/28 ip4:216.191.52.64/27
    216.191.52.70 216.191.52.6/31 ptr -all"

It also appears that none of your included domains publish SPF records 
yet, and this is why spfcompile removed them. Perhaps your -all 
mechanism would cause blackberry mail to be rejected by those who check 
SPF records (there are very few who check and reject failures yet, so 
that's probably why you're not seeing a lot of rejected mail) ?
Would you consider removing these includes until those domains publish 
their SPF records ? they each cause the recipient to do a query to those 
domains. It's a DNS load that your systems do not see, but the 
recepients of your mail has to query as per your SPF instructions.
Thank you,
Radu.