Re: Re: DNS load research

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.

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

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.
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. 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.
> 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 think it's unsafe to do what you do, because:

Rogers is very similar to RoadRunner I think. Both are cable modem 
companies.
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.
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.
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!.
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 ;)
Regards,
Radu.