Julian Mehnle wrote on Thursday, January 11, 2007 6:14 PM -0600:
I still think the spec has a bug. It should have looked like this
instead:
| SPF no record | SPF timeout or
| SPF no v=spf1 | RCODE not 0/3
-----------------+----------------+---------------
TXT no record | None | None
TXT no v=spf1 | |
-----------------+----------------+---------------
TXT timeout or | TempError | TempError
RCODE not 0/3 | |
That's quite reasonable, though it would explicitly make TXT the primary
record. The brand new SPF record type would be secondary and thus never used
(at least for SPFv1).
I've no clue how Stuart has implemented his tolerance for broken
name servers. My naive approach would be take whatever I get first
(after two queries) as the "real" reply, not waiting for a "better"
or conflicting second reply.
This isn't a good approach if your objective is discovering data.
"Place 1 says no-data-here, so let's not wait what place 2 says.
We'll just assume there's no data at all." Sorry, it doesn't make
any sense.
I tend to agree. Querying for two records should mean waiting for both
results. If you only query for one record, getting back an empty record is a
definitive answer and a DNS error is obviously temperror. The fact that
reasonable people have rather different opinions as to what is definitive when
you query for two similar but distinct records shows why this is not such a
great idea.
I hate to say it, but the easiest and most reliable solution is to query only
for TXT records. I wasn't being facetious when I suggested that people who
don't like the confusing situation for DNS errors with two record types should
consider only querying for one. That's not to mention the fact that the
type99 query is wasted 99% of the time (is that where the name came from?) and
we are supposed to be concerned with DNS usage.
--
Seth Goodman
If this "death by tables of error codes" thread flows from a desire to
migrate to a new DNS record type for SPF
by forcing implementors to use it immediately, this is not wise.
The implementations should use existing facilities (TXT) and migrate
to the new record type if/when it makes sense, and with reasonable rules
as to when the "new stuff" is appropriate, and how fallback should
work. We should not try to build the fallback into the semantics of
the "single query".
-dgl-
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735