Subject: Re: [spfbis] #47: domain-spec

From: Arthur Thisell <[email-masked]>
Date: Wed, 29 Aug 2012 13:42:08 -0700 (PDT)

First off, when drafting RFC4408, we were scolded by the DNS folks not to use things like NXDOMAIN, SERVFAIL, etc. because those are labels for particular libraries/APIs, rather than from RFCs.  Instead, we should use RCODE.  I don't know if the opinion within the IETF has changed since then, I see IANA now has a registry with names for DNS RCODEs.  I think we should be consistent, either use only RCODE numbers, or only use IANA names.

>>>  or new:
>>>
>>>     The domain-spec is expanded as per Section 8.  The resulting domain
>>> name is used for a DNS A RR lookup (even when the connection type is
>>> IPv6). If any A record is returned, this mechanism matches.  In all
>>> other cases (no A records, DNS error, etc.), the mechanism doesn't match.

My mistake, DNS errors should be handled as per section 5's general description for DNS lookups.  Saying "In all other cases" might imply overriding general description.

The new text that was added to 4408bis is almost duplicate information, except where it is contradictory to previous text.   This, of course, is one of the dangers of saying the same thing twice, you have to make sure both places say the same thing.

>my take:
>
>  Note that the queried type MUST be A:  This mechanism doesn't work
>  for sites returning TXT RRs, nor allows discrimination based on the
>  returned value.  Only the returned RCODE is meaningful for the
>  result, NOERROR yields a match and NXDOMAIN a non-match.  Other
>  codes imply a DNS error and break the evaluation.

This is wrong.

>BTW, http://www.ietf.org/mail-archive/web/spfbis/current/msg01754.html
>discusses SERVFAIL.  Is that the only DNS case, besides timeout, that
>yields temperror?  Should Section 2.5.6 mention it?
>
>The current I-D mentions SERVFAIL only in Appendix C, annotating the
>option to turn repeated SERVFAIL into permerror.  Shouldn't such
>criterion be applicable to "exists" mechanisms as well?
>
>How about non-DNS errors, e.g. database unavailable and similar?

One of my there comments was section 2.5.6 (temperror) seemed to imply that only DNS errors could generate it.  This is wrong, other local temporary errors can cause it also.  Dababases being unavailable, out of memory, out of disk space, etc. can also use temperror.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Aug 2012 00:13:03 -0400

On Wednesday, August 29, 2012 01:42:08 PM Arthur Thisell wrote:
> First off, when drafting RFC4408, we were scolded by the DNS folks not to
> use things like NXDOMAIN, SERVFAIL, etc. because those are labels for
> particular libraries/APIs, rather than from RFCs.  Instead, we should use
> RCODE.  I don't know if the opinion within the IETF has changed since then,
> I see IANA now has a registry with names for DNS RCODEs.  I think we should
> be consistent, either use only RCODE numbers, or only use IANA names.
> >>>  or new:
> My mistake, DNS errors should be handled as per section 5's general
> description for DNS lookups.  Saying "In all other cases" might imply
> overriding general description.
> 
> The new text that was added to 4408bis is almost duplicate information,
> except where it is contradictory to previous text.   This, of course, is
> one of the dangers of saying the same thing twice, you have to make sure
> both places say the same thing.

i may have lost track of this issue.  What is the new text you're referring to 
here?

> One of my there comments was section 2.5.6 (temperror) seemed to imply that
> only DNS errors could generate it.  This is wrong, other local temporary
> errors can cause it also.  Dababases being unavailable, out of memory, out
> of disk space, etc. can also use temperror.

Every single reference to TempError in RFC 4408 is DNS related.  The addition 
of the parenthetical (DNS) was meant to clarify this.  I don't think that 
having every "my system is broken" condition return an SPF result of temperror 
is consistent with general usage or a good idea.  For example, if you screw up 
postfix policy configuration and get into a non-working condition, postfix will 
reply is 451 System Configuration Issue (or similar, I'm doing that from 
memory) until it's fixed.

If broken system is an SPF temperror, I can see all kinds of unrelated 
failures tagged as SPF failures.  This has no benefit I can see and could 
certainly cause confusion.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 30 Aug 2012 01:49:58 -0400

No hat.

> First off, when drafting RFC4408, we were scolded by the DNS folks not to use things like NXDOMAIN, SERVFAIL, etc. because those are labels for particular libraries/APIs, rather than from RFCs.  In…

Error codes _always_ had names.  My personal preference has always
been to include the RCODE and, on first use, the symbolic name as
well.  I'm also happy if people use the symbolic name, with the RCODE
on first use.  But I think both need to be in the document at first
use, no matter what.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 30 Aug 2012 13:03:11 +0200

On Thu 30/Aug/2012 06:13:03 +0200 Scott Kitterman wrote:
>> One of my there comments was section 2.5.6 (temperror) seemed to
>> imply that only DNS errors could generate it.  This is wrong,
>> other local temporary errors can cause it also.  Dababases being
>> unavailable, out of memory, out of disk space, etc. can also use
>> temperror.
> 
> Every single reference to TempError in RFC 4408 is DNS related.
> The addition of the parenthetical (DNS) was meant to clarify this.
> I don't think that having every "my system is broken" condition
> return an SPF result of temperror is consistent with general usage
> or a good idea.  For example, if you screw up postfix policy
> configuration and get into a non-working condition, postfix will 
> reply is 451 System Configuration Issue (or similar, I'm doing that
> from memory) until it's fixed.
> 
> If broken system is an SPF temperror, I can see all kinds of
> unrelated failures tagged as SPF failures.  This has no benefit I
> can see and could certainly cause confusion.

I see your point.  However, DNS timeout will always be dubious, as it
can depend on an outage or misconfiguration at the verifier's, at the
publisher's, or anywhere in between.  I don't think an out-of-memory
error can be caused by names longer than 63, but, in principle, I
neither think we can limit local errors due to SPF to DNS timeouts
exclusively.

What is the reason to deny an SPF qualifier to a local error occurring
during SPF verification?

If the verifier replies 4xx, or crashes without replying, the SPF
qualification doesn't matter.  OTOH, if the server recovers from the
error after the verification failed, it may be able and willing to
accept the message at hand.  I'd assume it writes its trace header
field also in such cases.  What SPF result should it report?

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 30 Aug 2012 13:03:35 +0200

On Thu 30/Aug/2012 07:49:58 +0200 Andrew Sullivan wrote: No hat.
>> First off, when drafting RFC4408, we were scolded by the DNS
>> folks not to use things like NXDOMAIN, SERVFAIL, etc. because
>> those are labels for particular libraries/APIs, rather than from
>> RFCs.  Instead, we should use RCODE.  I don't know if the opinion
>> within the IETF has changed since then, I see IANA now has a
>> registry with names for DNS RCODEs.  I think we should be
>> consistent, either use only RCODE numbers, or only use IANA
>> names.
> 
> well.  I'm also happy if people use the symbolic name, with the
> RCODE on first use.  But I think both need to be in the document at
> first use, no matter what.

Is there a better place than 1.3. *Terminology* ?

In http://www.iana.org/assignments/dns-parameters I find, for example,
that decimal 3, name "NXDomain" means Non-Existent Domain and its
reference is [RFC1035].  However, RFC 1035 does not contain the
symbolic name string.  RFC 2136 does.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Aug 2012 06:56:16 -0700

> First off, when drafting RFC4408, we were scolded by the DNS folks not to use things like NXDOMAIN, SERVFAIL, etc. because those are labels for particular libraries/APIs, rather than from RFCs.  In…

I've gotten away with stuff like "NXDOMAIN (DNS RCODE 3)" before, and
then use NXDOMAIN in the rest of the document.

> The new text that was added to 4408bis is almost duplicate information, except where it is contradictory to previous text.   This, of course, is one of the dangers of saying the same thing twice, y…

+1.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Aug 2012 10:04:40 -0500

>field also in such cases.  What SPF result should it report?

If it can't complete the evaluation, then there can't be an SPF result.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Aug 2012 10:08:01 -0500

>symbolic name string.  RFC 2136 does.

We've survived half a decade with just the rcodes.  The appendix won't get published as part of 4408bis.  Can we just drop this?

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 30 Aug 2012 17:56:50 +0200

> If it can't complete the evaluation, then there can't be an SPF result.

Hm... omitting the trace field entirely should mean that the sender
was whitelisted from SPF checking (e.g. submission.)  So, the server
might want to write:

  Received-SPF: none (can't complete the evaluation)

That conflicts slightly with Section 2.5.1.  Then, one would expect no
neat demarcation between the above and:

  Received-SPF: temperror (the DNS made a boo boo)

For comparison, RFC 5451 doesn't say "a transient (DNS) error" but
"some error that is likely transient in nature, such as a temporary
inability to retrieve a policy record from DNS."  IMHO, the latter
includes local malfunction, albeit it indicates the DNS as a typical case.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Aug 2012 12:27:46 -0700

> includes local malfunction, albeit it indicates the DNS as a typical case.

Is the distinction important?  The salient point is that the software
has determined that, whatever the error was, it's possible it will
self-resolve rather than being an error that requires operator
intervention.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 Aug 2012 12:52:10 -0700

> self-resolve rather than being an error that requires operator

Certainly it's not significant at a protocol specification level.

On the other hand, it probably has some pedagogic benefit to remind the
reader that there is an end-to-end integration that has to work properly
and when it doesn't, the problem could be anywhere in the sequence.

So, perhaps:

   ...such as a temporary a network problem or a remote host's inability
to retrieve a policy record from its portion of the DNS.

d/

-- 
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Aug 2012 16:06:28 -0400

> to retrieve a policy record from its portion of the DNS.

My plan is to change (DNS) to (generally DNS).  Any objections?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 Aug 2012 13:14:36 -0700

> My plan is to change (DNS) to (generally DNS).  Any objections?

It's a bit subtle for the pedagogical point I was noting, but it also
isn't wrong.  And of course, it's less wordy...

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 31 Aug 2012 10:15:34 +0200

> My plan is to change (DNS) to (generally DNS).  Any objections?

Works for me.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 31 Aug 2012 08:51:31 -0400

> > My plan is to change (DNS) to (generally DNS).  Any objections?

Done locally.

Scott K