No, I'm not over thinking this. In your example, if I have a TTL of 6
hours, which is not unreasonable, then my DNS server has to recompile my
SPF record and retrieve all of the components of that record every 6
hours. On the other hand, if I send you an email, you have the SPF
record and all associated information for the same 6 hours, so if you
get another email from me, or simply claiming to be from me, then all of
what you need will be in your cache. And trust me, I know DNS and the
related protocols quite well and I'm not confusing client with server.
You need to keep in mind that more than one authoritative DNS servers
may be involved in the resolution of an SPF record. In my example,
there is my authoritative DNS server and my email service provider's
authoritative DNS server. And there could be more. I could have my
own, my ISP's, a colocation facility and an outsourced marketing
partner, among others. I have no control over their DNS configuration,
including TTL's which they could set at 60 seconds for all I know.
And all of this is for practically NOTHING. Bandwith and processing is
cheap. Simplicity is priceless. In another email, someone said that
the reason for SPF was efficiency. I counter that it is for the
efficiency of the people involved--not the machines.
Marc
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Guy
Sent: Monday, March 21, 2005 5:19 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Re: DNS load research
You are over thinking on this!!!
Yes, your DNS server will cache some stuff that it may not normally
cache.
The same thing happens when you go to a web site you normally don't go
to, or when you receive spam from someone that you don't normally
receive from.
Why is this a problem? If the info is dropped from the cache, then it
will be retrieved when needed, why is this a problem? Is your TTL just
a few minutes? If so, set SPF-FETCH = no. Problem solved, but no
benefits from compiling (in your example). :)
The TTL on the compiled SPF record can not exceed the TTL of any source,
so when anything else expires, so does the compiled SPF record!
You said:
"If they happen frequently, then you are increasing the liklihood that
the record is already in cache. As you said: "I think the DNS cache is
good enough.""
You are taking my comment out of context!
I said:
"I did not intend a DNS server to compile other people's SPF records.
However, maybe that is a viable option also. I think the DNS cache is
good enough."
I am comparing the cache to the compiled SPF record on the receivers DNS
server.
Maybe you are mixing client and server.
My client (someone that receives email from me) will not benefit from me
having stuff in my DNS server's cache. This is why it helps to compile
the SPF record. I can give them a record that does not need any extra
lookups, or at least less lookups. In your example, 0 extra lookups.
However, my cache will prevent extra lookups when my DNS server compiles
my SPF record.
My client would not care about my DNS cache.
My client would not compile my SPF record since once they retrieve my
record, they have the info in the cache. If they were to need my record
again, it would be in cache regardless if it was compiled or not.
I hope I made this clear. Maybe not. :( Remember, there are at lease
2 DNS servers involved when sending an email. The sender's DNS server
and the receiver's DNS server. I guess sometimes they could really be
using the same DNS server, but I believe that would be the exception!
Guy
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Marc
Alaia
Sent: Monday, March 21, 2005 4:44 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Re: DNS load research
Guy,
What about this simple scenario:
My domain is alaia.net. Let's just assume for a minute that my SPF
record is "v=spf1 MX -all". And let's assume that my mx record is
primarymx.myisp.net (10) and backupmx.myisp.net (20).
Since I have no control over the records at myisp.net, the DNS server
that you propose compile my SPF record must:
1) Keep a copy of the A records for primarymx.myisp.net and
backupmx.myisp.net in cache and fetch a fresh copy every time they
expire. And recompile my record when they do. -OR-
2) Automatically periodically recompile my SPF record, fetching the
current resolution of primarymx.myisp.net and backupmx.myisp.net.
AND, in either case once my record has been recompiled, I must now wait
for the TTL on MY record to expire so my SPF record is 'current'. This
means that I have to wait for two TTL's before my record is totally
current.
As you can see, this is about as simplistic of an example that there is
and does not even begin to address some of the macro-related directives.
A moderately-complex SPF record could involve a decent amount of caching
or checking. Your proposal would overly burden a moderately large DNS
provider, such as DNSMadeEasy (who I use). And what about DNS caching?
If the 'expensive' lookups only happen infrequently, then so what, they
are only a small portion of your overall lookups. If they happen
frequently, then you are increasing the liklihood that the record is
already in cache. As you said: "I think the DNS cache is good enough."
Marc
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Guy
Sent: 03/21/2005 4:07 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Re: DNS load research
Maybe you missed my point. What I am suggesting is that my DNS server
compile my SPF record and publish the compiled record. The TTL of the
compiled record must not exceed any TTL of any source info. So, the
compiled SPF record would stay in cache (I guess) until the TTL is
exceeded.
Then re-compile it, or wait until someone asks for it, then compile it.
All of the source info can be cached as normal (like includes), or
requested if not in the cache. The DNS protocol would not change!!!!!
Other than having a SPF record type. Maybe even the TXT SPF record
could be compiled, why not?
I can see 5 options:
SPF-COMPILE (yes/no) self explanatory IMO
SPF-FETCH (yes/no) request any remote info, examples:
include:myisp.com
a=smtp.myisp.com
SPF-PRECOMPILE (yes/no) Keep compiled SPF records handy so SPF-NODELAY
would not normally apply. I guess the
pre-compile should start before the old
record
expires.
SPF-NODELAY (yes/no) yes = if no compiled record is in memory,
then give un-compiled record now,
but also compile the record for future
use.
No = don't respond until the SPF record
is compiled.
SPF-COMPILE-OTHER (yes/no)
Yes = Compile other people's SPF records
when they
are requested. In this case, no need to
compile any
includes, those will be handled as
another
request. I don't think this is a good
option,
the DNS cache will handle this.
I don't understand you comment about the extra bandwidth. Compiling an
SPF
record(s) once every few hours would be less effort (bandwidth) than
having an expensive SPF record that takes 5-111 lookups every email
(including forged).
I did not intend a DNS server to compile other people's SPF records.
However, maybe that is a viable option also. I think the DNS cache is
good enough.
So far, I have devoted 20 or so minutes to this idea! I am sure it
could be improved.
Guy
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Marc
Alaia
Sent: Monday, March 21, 2005 3:12 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Re: DNS load research
Maybe one day there will be an SPF record type. Then the DNS servers
could optionally compile the SPF record to a simpler (less expensive)
form, automatically! Even "include:"s could be pulled in, as long as
the TTL is obeyed, and the SPF record re-compiled when something
expires.
That would be awsome. But even then we'll have to support 'legacy' SPF
clients, and they will seem awfully expensive by comparison to the
server-compiled SPF records, but we'll be stuck with them.
And how is this any better than the existing 'problem'? You are
proposing removing some processing and traffic in favor of more
processing and bandwith. Your proposal involves changing DNS servers so
that they would have to take a 'source' (i.e. SPF Classic) TXT record
(which they will have to keep on hand for periodic recompiling) and
compile it into a all-IP SPF record. Your proposal now also requires
that the authoritative DNS server for this domain must either keep in
cache every piece of information to compile the record or periodically
go out and re-request this information. So all of the bandwith and
processing that you propose to save has been reconsumed.
Marc
-------
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
-------
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
-------
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
-------
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