spf-discuss
[Top] [All Lists]

Re: Re: DNS load research

2005-03-20 18:02:25


Radu Hociung wrote:

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.

People who are actually talking about SPF to try to get it to work, yes. Those trying to scuttle it in favour of their own product, no. :(

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.

Um, unless you host your own DNS servers, publishing SPF has zero load affect on your resources. If you do host your own DNS servers, its likely reasonable to assume you have some money sunk into sufficient resources to run your own infrastructure. If not, reconsider running your own infrastructure, because you are susceptible to even the most childish script kiddie DOS attack.

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.

It is not the TTL that matters, actually. Short of internet outage the DNS will be refetched not when the TTL expires but when the REFRESH expires. I think you will find most REFRESH are set lower then 1 day. But even at say 4 hours (like mine), that's pathetically little resource consumption compared to the bandwidth saved by rejecting SPAM SMTP time (or the possibility of rejecting spam at SMTP time, once people start doing it and then using black/white lists to reject on the authenticated domains)

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

Since my company is done moving the corporate office (and changing ISP's at the same time), I have dropped the a and ptr as they are no longer needed. But for the mx and the secondary, they need to be there in the event I have to do an emergency co-location (like the last 2 times a construction company cut a trunk line that left me with an outage and I moved the server to a different office).


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

99% of legit email from my domain falls within 1 lookup (the primary) because even rogers and blackberry are (at least for now) correctly setting the reply-to (rather then enevelope from) to being the users company address.

spfcompile shows the following record as equivalent:

Then it does so incorrectly, because:
1) the instant one of my included domains publish SPF it is explicitly not equivalent 2) for SPF checking servers which use AI to determine SPF set for a domain that does not publish (e.g. assume MX and possibly A and/or PTR)

    "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) ?

I hope some day soon someone gets some email rejected because of the non-publishers. Then I can leverage legit user complaints to make policy about what ISP's can be used, and even perhaps to try to convince the ISP's to publish.

Would you consider removing these includes until those domains publish their SPF records ?

Absolutely not, see above (1) and (2)

they each cause the recipient to do a query to those domains.

Only for a very SMALL fraction of email from my domain, because the majority of email from my domain is matched by the IP mechanism.

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.

Agreed.

But I think you are overestimating the impact that DNS load has on internet infrastructure. SPAM has far worse impact on bandwidth consumption, server processing resources etc.

Terry


Thank you,
Radu.

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com


--
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085


<Prev in Thread] Current Thread [Next in Thread>