Subject: Re: [dnsext] Deprecating SPF

From: S Moonesamy <[email-masked]>
Date: Tue, 20 Aug 2013 11:36:55 -0700

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

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 20:45:23 +0200

On 20 aug 2013, at 20:36, S Moonesamy <[email-masked]> wrote:

> 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.

Understood, and thanks.

The reason why I did not post there at first was that a) I did not feel I had followed the rules laid out for discussions [read all messages in the mailing list archives] and b) the discussion on the dnsext list was more general on overload of TXT records [something DNS people have always been against -- see IAB document on DNS choices].

But, when having that discussion on the dnsext mailing list, to which I cc:ed Pete as responsible AD for full disclosure, Pete did ask me for a complete explanation of my view, which I posted.

Once again, without re-reading the mailing list archives.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 20:58:10 +0200

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 <[email-masked]> 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.
>> 
>> 
>> 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.
> 
> 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.
>

---

From: S Moonesamy <[email-masked]>
Date: Tue, 20 Aug 2013 12:30:48 -0700

Hi Patrik,
At 11:45 20-08-2013, Patrik Fältström wrote:
>The reason why I did not post there at first was 
>that a) I did not feel I had followed the rules 
>laid out for discussions [read all messages in 
>the mailing list archives] and b) the discussion 
>on the dnsext list was more general on overload 
>of TXT records [something DNS people have always 
>been against -- see IAB document on DNS choices].
>
>But, when having that discussion on the dnsext 
>mailing list, to which I cc:ed Pete as 
>responsible AD for full disclosure, Pete did ask 
>me for a complete explanation of my view, which I posted.
>

First of all, I apologize for copying the message 
to ietf@.  The advice given was to read the 
comments in the SPFBIS mailing list archives.  It 
is not a rule.  If a person did not read all the 
messages and the person raises a point or 
provides arguments which were not discussed 
previously I will ask the SPFBIS WG to address them.

I don't know whether to process your comments or 
the other comments posted on dnsext@ as part of 
the Last Call or not.  It is unclear to me as to 
whether I should only consider messages with the 
appropriate Last Call subject line.  My sense is 
that I should listen to your concerns.

Regards,
S. Moonesamy

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 20 Aug 2013 21:37:15 +0200

On 20 aug 2013, at 21:30, S Moonesamy <[email-masked]> wrote:

> First of all, I apologize for copying the message to ietf@.

No apology needed.

> I don't know whether to process your comments or the other comments posted on dnsext@ as part of the Last Call or not.  It is unclear to me as to whether I should only consider messages with the appropriate Last Call subject line.  My sense is that I should listen to your concerns.

I was the one making mistakes.

Mea culpa.

   Patrik

---

From: S Moonesamy <[email-masked]>
Date: Wed, 21 Aug 2013 13:35:02 -0700

Hi Patrik,
At 11:58 20-08-2013, Patrik Fältström wrote:
>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.

draft-ietf-spfbis-4408bis-19 is not the usual 
Proposed Standard effort.  The SPFBIS WG was 
tasked to move RFC 4408 to Proposed Standard with 
restrictions.  One of the restrictions is not to 
review the design.  I hope that explains why 
draft-ietf-spfbis-4408bis-19 is what it is.  I 
suggested to the working group to review the 
issue of the migration strategy (see 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03934.html ).

 From Section 3.1.1 of RFC 4408:

   "It is recognized that the current practice (using a TXT record) is
    not optimal, but it is necessary because there are a number of DNS
    server and resolver implementations in common use that cannot handle
    the new RR type.  The two-record-type scheme provides a forward path
    to the better solution of using an RR type reserved for this purpose."

There isn't similar text 
in  draft-ietf-spfbis-4408bis-19.  Hector Santos commented that:

   "we will add SPF type support in our implementation once the infrastructure
    is ready. For us, as a windows shop, namely Microsoft DNS servers."

I read 
http://social.technet.microsoft.com/Forums/windowsserver/en-US/5841e884-db22-42a1-8530-615a375662cc/dns-server-support-for-new-or-unamed-rr-type-records 
My conclusion is that there is a DNS server that cannot handle the new RR Type.

The question is how to address the objection about the migration strategy.

Regards,
S. Moonesamy (as document shepherd)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 23 Aug 2013 07:23:37 +1000

Part of the question is whether the IETF is going to work with ICANN, IANA
and the ccTLD to audit delegations for servers that are not RFC 103[45]
compliant and suspend delegations where the servers are not compliant.

	* no responding to queries based on query type
	* not having a NS rrset at the delegation point

Enforcing that ccTLD and ICANN TLD regularly audit delegations and
have mismatches corrected.  This is REQUIRED by RFC 1034 in part to
stop the sorts of problems we are seeing today.

We don't have to put up people putting up misconfigured / broken servers.

For the non responding servers I have written
draft-andrews-dns-no-response-issue to try to capture the issues.
It was on the dnsop agenda for Berlin but didn't get covered as time
ran out.  I would like everyone to read it and comment on it.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]