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>
|
- Re: DNS load research, (continued)
- Re: DNS load research, Frank Ellermann
- Re: Re: DNS load research, Terry Fielder
- Re: Re: DNS load research, Radu Hociung
- Re: Re: DNS load research, Radu Hociung
- Re: Re: DNS load research, Radu Hociung
- Re: Re: DNS load research, Terry Fielder
- Re: Re: DNS load research, Radu Hociung
- Re: Re: DNS load research, Terry Fielder
- Re: Re: DNS load research, Radu Hociung
- Re: Re: DNS load research, Radu Hociung
- Re: Re: DNS load research,
Terry Fielder <=
- Re: DNS load research, Frank Ellermann
- Re: Re: DNS load research, Radu Hociung
- Re: Re: DNS load research, Andy Bakun
- Re: DNS load research, Frank Ellermann
- Re: Re: DNS load research, Radu Hociung
- RE: Re: DNS load research, Scott Kitterman
RE: Re: DNS load research, Marc Alaia
RE: Re: DNS load research, Marc Alaia
|
|
|