Re: Re: DNS load research

Terry Fielder wrote:
> Life's tough, but at least the users will have email back within a few 
> hours whether or not the data center T1 is back up.
I think I have a suggestion that will allow you to be back up much 
faster than a few hours, and avoid a bunch of spam traffic in the process.
Get yourself a full-time IP address at your fall-back
location. Give it a name within your domain name
(fallback.ggh.com). The TTL for this needs not be short.

Normally there would be no machine at this address. List the
static IP in your SPF record. Normally no mail will be coming
from there. No problem, 12 wasted bytes in an SPF record.
Actually they're not wasted, they are 'insurance'.

For incoming, list the fallback machine as a secondary MX
exchange with a lower priority than your mail.ggh.com primary MX.
The legitimate SMTP servers will usually contact the highest
priority MX for deliveries. When it goes down, they will try the
secondary, at the pre-published address. Spammers also like to
send through the secondary, so they will see connection
timeouts while trying to do this, and in turn your main MX server
will also have to deal with much less spam. Rarely do they try the
primary, because there's a lesser chance of mail going through.
This means less spam traffic (SMTP, DNS, etc).

Actually, perhaps I should do this too, add a fake secondary MX
at some non-routable IP address. That's brilliant. I wonder if
anyone else has thought of this. I sure hope it's not pattentable,
but if it is, remember that you've seen it here first ;)



> > So after 2:30pm, I'll try to re-fetch the mail.greatgulfhomes.com A 
> > record from ns.greatgulfhomes.com (216.191.52.74) or 
> > ns4.greatgulfhomes.com (216.191.52.72). In my cache, the addresses of 
> > your NS's  is good till next morning at 11am. I suspect both of your 
> > NS machines are on the dark side of the cut trunk based on the IP 
> > addreses. 
> 2 primaries are, but there are 3 other DNS servers, located in Atlanta, 
> Dallas, and Houston.  I can switch to them in a heartbeat.
I see. Got it.

> > So as long as you use a template for your zone file, like:
> >
> > mail.greatgulfhomes.com       IN  A  _IPADDR_
> > greatgulfhomes.com            IN TXT "v=spf1 ip4:209.91.136.161/28 
> > ip4:216.191.52.64/27 _IPADDR_ -all"
> > Both records are updated in sync, and all you have to do is "make" to 
> > regenerate your zone file when you move to the new location.
> > The issue with the DNS mechanims in your SPF record is forged email, 
> > not the email you generate. I don't know if your domains are forged 
> > often, but if they are, any time a forgery goes around, all the DNS 
> > mechanisms will be queried, because the forger's IP address does not 
> > match any on your SPF list. 
>
> If 3rd party is receiving email forged as from me, they are trying to 
> save themselves.  Provided the cure is not worse then the disease, its 
> not a problem.  Receiving forged spam is worse then having to perform a 
> few DNS queries.  Get over it.
Indeed, it's the receivers we need to be considerate of.

> > So when a spammer pretends to be you, and sends me an email, I have to 
> > do 11 queries for no good reason. What worries me is not that I have 
> > to do 11 queries, but that I have to do 11 queries for every domain 
> > name my spammer can think of.
> Um, did you think spammers were going to make it easy for you?  Perhaps 
> you can ask them nicely and they will behave?  :)  Seriously, you are 
> going to get screwed by spammers chewing your resources one way or another.
In this case I am afraid it's expensive SPF records that makes their 
spam expensive for me.
To put it in perspective, my server is mainly used for mail. I use a 
challenge-response system which rejects before DATA. Also, I do SPF 
checks before checking the whitelist. This is because I only challenge 
senders that pass the SPF check. So I need to do the SPF check whether 
they are on the whitelist or not.
Recently I've been paying attention to my traffic, and my DNS traffic 
originating from the mail server is about 2.5 times the traffic of mail 
actually transfered through the MTA port. This is traffic that acually 
goes out the Ethernet port, so it represents DNS cache misses. I think 
more than 75% of the DNS traffic is due to the SPF checking. I feel this 
is too much of a load.
Since I have a method in place to block spam before DATA, and I think 
many do, regardless of whether it's challenge-response or something 
else, the bulk of the chewed resources are not chewed by the spammers, 
but by the expensive SPF publishers. And funny, but they have to pay it 
it too :)
I don't have enough stats to see how this scales, but it would mean that 
if one of the large ISP's wanted to check SPF, they'd need twice as much 
DNS infrastructure as they currently use for mail.
Because of this large incremental investment, I think SPF's chances to 
succed would be higher if it weren't so bandwidth expensive.
I'm not worried about my domain, as I have a thousand times more 
capacity than I use, but I don't think everyone has this luxury. I know 
that some IT departments always complain that they don't have budgets as 
big as needed.
Being careless, we're only killing SPF's chances. That's my biggest worry.

> I already have users who send email through Rogers.  When rejection 
> starts happening (and I actually look forward to it) then I have a drum 
> to beat to assist with doing things right (e.g. SMTP AUTH).  And then I 
> will be able to get rid of the includes.
I agree, but I don't see your rogers include helping with this.

> > I think it's unsafe to do what you do, because:
> Its also not safe to drive to work.  But is a calculated risk I take so 
> I can pay the bills.
Yes, I guess we calculate risk differently :) We all have bills, that's 
for sure.
> And anyway I don't want my Rogers email users to be blocked, I have done 
> what I can to prevent it, but that doesn't preclude me from looking 
> forward to when it does start getting blocked and I can "beat my drum" 
> to push proper SPF implementation with SMTP AUTH for *all* roamers.
When it does start happening, it will be because recipients start 
checking, not because Rogers finally publishes SPF.
> It's only a potential permerror for emails from the non ip4, which are 
> ones that matter most.
Currently those emails are evaluated as "fail". If that changes to 
"permerror" there will be no difference.

Radu.