As the bottle is opened, I hereby state my objection to Section 3.1 of
draft-ietf-spfbis-4408bis-19 for the reasons explained below. I do agree (as
stated below) that the section of RFC 4408 that specify how to use both SPF and
TXT resource record types include an error as it does not lead to
interoperability.
As the intention with use of both TXT and SPF originally was to migrate from
TXT to SPF I instead of what is outlined in the draft suggest that a proper
migration strategy is laid out (look up mandatory to implement SPF and fall
back to TXT). This instead of deprecation of the SPF record.
In general I do believe, for example when looking at IPv6 and DNSSEC and
similar technologies, that the lifetime of RFC 4408 is too short to deprecate
any of the proposed records that are in use, specifically as RFC 4408
explicitly do allow use of both.
Patrik
On 20 aug 2013, at 20:36, S Moonesamy <sm+ietf(_at_)elandsys(_dot_)com> wrote:
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