Subject: Re: [spfbis] #25: RFC 4408: Section 4.4 Parallel Query

From: S Moonesamy <[email-masked]>
Date: Thu, 08 Mar 2012 07:54:35 -0800

At 13:48 23-02-2012, spfbis issue tracker wrote:
>#25: RFC 4408: Section 4.4 Parallel Query
>
>  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.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg00580.html

[snip]

>Ticket URL: <http://trac.tools.ietf.org/wg/spfbis/trac/ticket/25>

Please comment on Issue #25.  As a reminder, please keep the subject 
line as it makes it easier to track discussions about each issue.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: "John Levine" <[email-masked]>
Date: 8 Mar 2012 17:33:20 -0000

>>     looked up, the queries MAY be done in parallel.

I don't see how this would be confusing for anyone who is familiar
with the way that the DNS works.  It means you send off the two
queries, then wait and see what if anything comes back in response to
both of them.  It's a normal technique that's used in a lot of
situations other than SPF, and does not require special client
libraries, special servers, or special anything else.

This sort of relates to the type 99 discussion, since there's only one
query to be made, but we can fix that when we decide about type 99.

On the third hand, if an SPF record refers to other records via a, mx, include,
and so forth, it's entirely reasonable to make those queries in parallel, too.
We don't need to say anything about it, it's a normal optimization.

So my suggestion is to close this issue, keeping in mind that we may come back
and remove the section if we deprecate type 99.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 08 Mar 2012 13:01:52 -0500

On Thursday, March 08, 2012 05:33:20 PM John Levine wrote:
> On the third hand, if an SPF record refers to other records via a, mx,
> include, and so forth, it's entirely reasonable to make those queries in
> parallel, too. We don't need to say anything about it, it's a normal
> optimization.
> 
> So my suggestion is to close this issue, keeping in mind that we may come
> back and remove the section if we deprecate type 99.

+1.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Mar 2012 19:05:25 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Thursday, March 08, 2012 10:02 AM
> To: [email-masked]
> Subject: Re: [spfbis] #25: RFC 4408: Section 4.4 Parallel Query
> 
> > So my suggestion is to close this issue, keeping in mind that we may
> > come back and remove the section if we deprecate type 99.
> 
> +1.

+1.  I find the cited text neither misleading nor confusing.  Anyone skilled in the art of DNS or writing code understands what "parallel" means.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Mon, 12 Mar 2012 14:27:52 -0700

I'll summarize Issue #25.  If I misinterpreted or misunderstood your 
comments, please let me know.

Issue #25 was opened based on a message posted on February 23 
[1].  John Levine mentioned that the issue sort of relates to the 
type 99 discussion, since there's only one query to be made, but we 
can fix that when we decide about type 99 [2].  He also commented on 
keeping in mind that we may come back and remove the section if we 
deprecate type 99 and Scott Kitterman agreed [3].  Murray Kucherawy 
also agreed and added that he does not find the cited text misleading 
nor confusing [4].

In an off-list contribution, a person agreed that if type 99 is 
removed, issue #25 is now moot.  The person does not think that the 
"Parallel method is a given and the basic sequential method needs to 
be described".

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00580.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00848.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00849.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00852.html