Re: Re: DNS load research

Radu Hociung wrote:

> Terry Fielder wrote:
>
> > > > Radu Hociung wrote:
> > > > I'm sorry... a correction is needed. There are still some bugs in 
> > > > spfcompile. The equivalent record should read:
> > > >     "v=spf1 ip4:209.91.136.161/28 ip4:216.191.52.64/27
> > > >     ip4:216.191.52.70 ip4:216.191.52.6/31 ptr
> > > >     include:rogers.blackberry.net include:blackberry.net
> > > >     include:rogers.com include:vianet.ca include:bellnet.ca -all"
> > >
> > > If you were to replace the hosts under your control with their IP 
> > > addresses, and remove the includes which do not publish SPF records, 
> > > and   after noticing that the IP addresses above are already covered 
> > > by ip4:216.191.52.64/27, your equivalent SPF record is:
> > > "v=spf1 ip4:209.91.136.161/28 ip4:216.191.52.64/27 ptr -all"
> > Excluding the mx and secondary mx only works while they remain within 
> > that IP block.  They currently are, but once again would not in a 
> > crises (see my previous note).
>
> That is a pretty ingenious technique. But I'm not sure I understand it 
> completely:
> mail.greatgulfhomes.com has a TTL of 3 hours.
>
> So if you send me an email in the morning at 11am, my MTA will do its 
> SPF check and my local DNS server will cache your SPF record as well 
> as your MX for 24h, the A record for mail.greatgulfhomes.com for 3h, 
> and the two NS records for your domain for 24h.
> Then, your ISP cuts your trunk mid morning at 11:30am. You quickly 
> move your server to another location, and update your A record for 
> mail.greatgulfhomes.com.
> Then one of your sales people sends me another email at 12pm. My MTA 
> checks the SPF again, but this time against the DNS data already in my 
> cache. My mail.greatgulfhomes.com info is good till 2:30pm, and since 
> the noon-time incoming IP is not in the SPF record listed in my cache 
> (which is valid till 2:30pm), I'll bounce your mail hard (5xx error) 
> for the first 3 hours after the accident.
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.
> 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.
> So my attempts to get the A record for mail.greatgulfhomes.com will 
> fail till next day at 11am, when I will ask the root servers "What are 
> the NS servers responsible for greatgulfhomes.com?". 
Incorrect, see above.

> In the meanwhile, I will have no option but to return TempError, and a 
> 400 error "Temporary DNS failure. Try later". After 4 hours (at 4pm), 
> your SMTP server will inform the salesperson that I cannot be reached. 
> He'll try to call me at the office, but I would have already left for 
> the day, having made up my mind about that sales guy at 
> greatgulfhomes.com.
>
> Since mail.greatgulfhomes.com takes 3 hours to expire, I think you'd 
> have to stop outgoing mail from for 3 hours from the accident time to 
> allow all caches to expire, and send non-delivery warnings to the 
> users right away. Otherwise, I'll be using only information already in 
> my cache (which is valid for till 2:30pm), and since the noon-time 
> incoming IP is not in the SPF record listed in my cache (which is 
> valid till 2:30pm), I'll bounce your mail hard (5xx error) for the 
> first 3 hours after the accident. then, I'll bounce it soft (4xx) as I 
> showed above, for the next 21 hours.
It doesn't get me back up instantly, but it means I can get back up 
within a few hours with minimal scrambling.
> I could be wrong, but I believe the TTL (time-to-live), is what the 
> DNS server uses as the length of time to cache queries, while the 
> refresh period is used by secondary DNS servers as the period of 
> polling for zone changes. The expire parameter tells secondary servers 
> that if they are not able to refresh (due to connectivity), to stop 
> responding to queries when the data is that old.
> Am I missing something?
No.  Which is why changes to my DNS will propogate in 4 hours (provided 
my DNS servers are reachable).
> If you set your SPF record's TTL the same as the 
> mail.greatgulfhomes.com, you'll only experience that much down time. 
> Of course, I think you need to set your NS TTL to 3 hours as well for 
> this to really work like you intended it.
Nope.  And I have done it, and it works.  DNS servers will refresh after 
the refresh expires.  They refuse to hold the cache entry after the TTL, 
but they
> 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.
> 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.
> > And including domains that do not (yet) publish can give 
> > fundamentally different results then dropping the include 
> > altogether.  Further, it means as soon as they do publish the include 
> > suddenly starts working.
>
> I agree. As soon as Rogers publishes an SPF record, the two are no 
> longer equivalent, and you'd have to update your SPF record, to make 
> them equivalent again.
> However:
>
> 1. You mentioned that your current IP list (not including rogers, etc) 
> covers all your mail sources. Presumably that's why your record ends 
> with -all. Because you're confident your mail can come from nowhere 
> else. So as soon as rogers publishes a record, does it mean you 
> immediately start sending through them without knowing it?
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 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.
> Rogers is very similar to RoadRunner I think. Both are cable modem 
> companies.
True

> I don't know about Rogers, but RR's SPF record includes several class 
> C networks. Also, their user agreement specifies that their users can 
> use any MAIL FROM: they wish in their outgoing mail. I think also they 
> do not block port 25 outgoing. So their customers can run their own 
> mail servers, legally. (I think in the case of rogers, only zombie 
> computers run SMTP servers ;) - illegally) I don't know if the RR 
> record includes their cable modem IP blocks.
It's against the Rogers EULA, unless you have a business class modem, 
but then its a whole different set of rules (and its a static ip)
> So, are you sure you are happy to include Roger's SPF record *without 
> looking at it* first? I think you'd make it possible for all the cable 
> modem virus-infected machines to send mail as 
> someone(_at_)greatgulfhomes(_dot_)com, and your SPF record would even validate it 
> as authentic.
Rogers is a drop in the bucket.  If I didn't publish anything in SPF, 
those receiving spam forged as from me are better off, not worse, don't 
forget it.
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.
> Also, when RoadRunner first published SPF records, they took 78 
> queries to resolve. Maybe Roger's first attempt will be better, but it 
> could be worse. Maybe they publish syntactically wrong records. In 
> either case, your SPF record will go from good to PermError faster 
> than you can say sh*t!.
It's only a potential permerror for emails from the non ip4, which are 
ones that matter most.
> Perhaps you've already read the User Agreements of the ISP's your 
> including blindly and already know that they won't do anything stupid 
> like that above, because they promise not to ;)
Actually its not the cable modem accounts I am worried about, that make 
me include the rogers SPF record (for when it exists), it is the PDA's 
such as blackberries and wireless palm devices.
Terry

> Regards,
> 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