Subject: [spfbis] new issue: Section 4.4 Parallel Query

From: Hector Santos <[email-masked]>
Date: Thu, 23 Feb 2012 15:59:43 -0500

In question:

    4.4.  Record Lookup

    In accordance with how the records are published (see Section 3.1
    above), a DNS query needs to be made for the <domain> name, querying
    for either RR type TXT, SPF, or both.  If both SPF and TXT RRs are
    looked up, the queries MAY be done in parallel.

I have seen this before and was very curious about how literal is that 
in term of the technical methods used to perform "parallel" queries. 
But with the group postings today related to type SPF and TXT queries 
and terms like "asynchronous" or "Same time"  made me think this might 
an item to be clarified.

The statement "the queries MAY be done in parallel" should be expanded to

   - Explain what "Parallel""  means,
   - The reasons whe on MAY wish to do this, and
   - What are the possible issues and considerations with it.

The term "Parallel" has a specific meaning (in terms of computers and 
software) which correlates to time independent concurrency of 
different thread, process, task, etc.  To the SPF implementator, this 
may mean using two different threads, fibers, task each doing a DNS 
query - SPF and TXT, or in DNS parley, it can a batch of multiple 
query packets.   This should be perhaps be explained.

The reasons is to lower overhead, I suppose, which may implies the 
"Multiple Query Packets" method, to help avoid the need to do two 
separate queries.

The possible issues as I basically understand it:

    - Multiple Query Packets (MQP) is not a universally support 
feature and in some reported -
      broken and unreliable, and

Now, the main issue starts with the idea that the end result of a 
parallel or MQP query MUST be the same for the result of two 
sequential queries.

In theory, the sequential order would be SPF type first, then TXT type 
as a fall back. The current text offer a functional spec requirement. 
What is needed is a technical specification description.  That should 
be done as if there as no parallelism or MQP capability, only 
sequential.  The parallel or MQP is essentially an DNS overhead 
optimization of the sequential method.

No question, the ideal query of two related types would be to batch it 
as one call.  But the reality is it is not an universal DNS server 
supported feature and since it must be described using the lowest 
common denominator method, this section should expand how the SPF and 
TXT queries should are done sequentially with translations of results.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Feb 2012 17:16:33 -0800

Hi Hector,
At 12:59 23-02-2012, Hector Santos wrote:
>I have seen this before and was very curious about how literal is 
>that in term of the technical methods used to perform "parallel" 
>queries. But with the group postings today related to type SPF and 
>TXT queries and terms like "asynchronous" or "Same time"  made me 
>think this might an item to be clarified.

The issue which you posted is being tracked as Issue #25.  Were these 
group postings about Issue #1?

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Hector Santos <[email-masked]>
Date: Thu, 23 Feb 2012 21:25:52 -0500

S Moonesamy wrote:
>> [be] an item to be clarified.
> 

Thanks.

They were among the issue #9 thread, subject: [spfbis] #9: RFC 4408 
SPF RR type.  Starting with Philip's data posting:

http://www.ietf.org/mail-archive/web/spfbis/current/msg00573.html

Scott's and Levine's follow up:

http://www.ietf.org/mail-archive/web/spfbis/current/msg00574.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg00577.html

---

From: Stuart Gathman <[email-masked]>
Date: Fri, 24 Feb 2012 09:23:45 -0500

Long ago, Nostradamus foresaw that on 02/23/2012 03:59 PM, Hector Santos
> optimization of the sequential method.
I disagree.  An implementation MAY query TXT only, or SPF only.  So a
parallel implementation could query both in parallel, then use whichever
comes back first.  The implementation can be thought of as a quantum
superposition of TXT only and SPF only, which resolves to a specific
choice when the first response packet arrives.

This is important, because a common problem is DNS servers that ignore
SPF queries (no reply at all) rather than returning "no such record". 
Checking for SPF first sequentially is impractical because of this DNS
server bug.  But querying in parallel and using the first response works
in all cases.

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Feb 2012 13:55:36 -0500

> I disagree.  An implementation MAY query TXT only, or SPF only.  

Agree. I did not intend to suggest otherwise.  Speaking of the dual 
type support only.

> So a

and may I add... successful first response or first response 
satisfying the query, necessary to signal, abort, ignore the first 
pending response.

> server bug.  

Well bug (not supported), yes, the RFC3597 issue was long understood.

> But querying in parallel and using the first response works
> in all cases.

My point is that its just a method, so unless you are noting it SHOULD 
be the only recommended method, it needs to be expanded and explained.

Primarily because A) it comes with an inherent design assumption about 
the SPF software integrated method for DNS client operations, and B) 
in lieu of A, the end result MUST|SHOULD match the most common 
possible, easier to do, synchronous sequential method.

What is implies the SPF-BIS assumes the DNS resolver component of an 
SPF package is expected to have an asynchronous DNSQuery solution 
already embedded in its API.

I don't think this technical requirement for the DNS API should be 
assumed, not assumed that the SPF software can be written to support 
asynchronous callback, event or messaging based frameworks.  It can be 
100% procedural or functional programming based with a synchronous 
programming model.

In any case, it should explained anyway. :)

--
Sincerely

Hector Santos
http://www.santronics.com
jabber: [email-masked]