Hi Patrik,
I am copying the message to ieft@ as there is an ongoing Last Call.
At 08:28 20-08-2013, Patrik Fältström wrote:
The consensus related to how to fix RFC 4408
will be very rough. That is clear. And I feel
sorry for responsible AD and IESG to be forced
to make a decision that such a large rough part
of the rough consensus will not be happy with.
Regardless of what the decision will be.
An architectural correct solution is to change:
OLD:
An SPF-compliant domain name SHOULD have SPF records of both RR
types. A compliant domain name MUST have a record of at least one
type. If a domain has records of both types, they MUST have
identical content.
NEW:
An SPF-compliant domain name SHOULD have SPF records of both RR
types. A compliant domain name MUST have a record of at type SPF,
code 99. Lookup MUST first be of type SPF and SHOULD if no response
is received be of type TXT.
Reasoning: The use of the TXT record for SPF is
not sounds for a number of reasons:
1. The TXT record already can have multiple
fields, and it is very unfortunate that the SPF
use of TXT records do not use that feature.
Instead the SPF specification do say that the
first field should be used, and if there are
more than one they should be concatenated. After
one have one and only one field, that field
should be parsed and divided in fields.
2. It is even (compared to some other TXT
related documents) pointed out in RFC 4408 that
collisions as described in RFC 5507 might happen.
3. It is also pointed out that there might be
size issues with the records, and experience
from use of NAPTR show that selecting a
preferred mechanism that potentially blows the
size of the RRSet is not very wise. This is btw
why the URI RR Type do not use a prefixed length
"text" field in the RDATA but do set the string
the URI is to the full length of the RDATA, i.e.
without any 255 byte limitation.
4. DNS is by design (as pointed out in RFC 5507)
created with a tuple consisting of owner, type
and class for selection by the client what
record set to be retrieved. This RRSet
architecture is something that comes back not
only in the query/response architecture of the
DNS protocol, but also in the DNSSEC
architecture where RRSets are the units that are
signed. Not explicitly ensuring an RRSet is used
for SPF (and nothing more) is an architectural choice I strongly am against.
Because of these reasons, I do believe the
choice is wrong to say that TXT MUST be
implemented and instead I am in favor of having
type SPF be mandatory for interoperability with fallback to lookup of TXT.
From Section 3.1 of draft-ietf-spfbis-4408bis-19:
"SPF records MUST be published as a DNS TXT (type 16) Resource Record
(RR) [RFC1035] only. The character content of the record is encoded
as [US-ASCII]. Use of alternative DNS RR types was supported in
SPF's experimental phase, but has been discontinued."
There is a message from Pete Resnick about RFC
2119 usage (
http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html
). The interpretation of "SHOULD" and MUST" in
that part of RFC 4408 was an issue which the SPFBIS WG discussed about.
It would be better to have the discussion on the
ietf@ mailing list as that's the venue which the
IESG identified for last Call comments.
Regards,
S. Moonesamy