RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02

"Hallam-Baker, Phillip" <pbaker@verisign.com> Fri, 26 August 2005 17:49 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8iKp-00080v-0m; Fri, 26 Aug 2005 13:49:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8iKm-00080a-Vt; Fri, 26 Aug 2005 13:49:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03866; Fri, 26 Aug 2005 13:49:43 -0400 (EDT)
Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8iLY-0006qV-Nb; Fri, 26 Aug 2005 13:50:33 -0400
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.1) with ESMTP id j7QHncgr016135; Fri, 26 Aug 2005 10:49:38 -0700
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Aug 2005 10:49:38 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 26 Aug 2005 10:49:37 -0700
Message-ID: <198A730C2044DE4A96749D13E167AD375A2AB9@MOU1WNEXMB04.vcorp.ad.vrsn.com>
Thread-Topic: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02
Thread-Index: AcWqPM6jSr92SuJoQe28JLtgGHW4DAAJs76g
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Andrew Newton <andy@hxr.us>, Bill Sommerfeld <sommerfeld@sun.com>
X-OriginalArrivalTime: 26 Aug 2005 17:49:38.0174 (UTC) FILETIME=[873571E0:01C5AA66]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: quoted-printable
Cc: Ted Hardie <hardie@qualcomm.com>, MARID <ietf-mxcomp@imc.org>, ietf@ietf.org, iesg@ietf.org
Subject: RE: Appeal: Publication of draft-lyon-senderid-core-01 in conflictwith referenced draft-schlitt-spf-classic-02
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

> Behalf Of Andrew Newton

> If this is the source of the conflict, then BOTH experiments should  
> not use the v=spf1 records.

Which would at the same time provide an opportunity to address the one
part of SPF/Sender-ID that does give me significant concern, the
exclusive appropriation of the TXT record.

A prefixed record would be much less likely to collide with other
records.

A proposal has been made to cut an new RR but as the group discovered
50% of the legacy infrastructure does not support new RRs despite claims
to the contrary. Support in this case has to be production quality, not
the ability to coax particular bits out of a server in certain limited
circumstances that no network admi is ever going to accept on a
production server.


The main objection to prefixed records is that they do not work with
wildcards. This is actually a failure of imagination rather than fact.
It is quite possible to develop a resolution procedure for prefix
records that works acceptably with legacy DNS resolvers and meets the
needs of network admins.

The first step is to address the problem that wildcards do not match an
existing node. As was demonstrated on the list this is easily solved
using a macro processor.

The second step is how to create a wildcard for _prefix.*.example.com
without changing legacy DNS servers.

The way to do this is to introduce a pointer record using CNAME as
follows:

_prefix.exists.example.com        TXT     "Policy1"
*.example.com                     CNAME   _wildcard.example.com
_prefix._wildcard.example.com     TXT     "Policy2"

The resolution algorithm for domain X is:

1) Check for a TXT record for _prefix.X if it exists, return the TXT
string and stop

2) Check for a CNAME at X, if it does not exist return 'NIL' and stop

3) Check for a TXT record for _prefix.Y where Y is the CNAME mapping. If
it exists return the TXT string, otherwise stop.

Applying these rules to the scheme above we get:

Lookup ("exists.example.com", "prefix") = "Policy1"   [cost 1 lookup]
Lookup ("empty.example.com", "prefix") = "Policy2"    [cost 3 lookups]
Lookup ("empty.example.com", "noprefix") = NIL        [cost 3 lookups]

This algorithm is 100% compatible with the deployed, legacy DNS and
meets all use cases that were proposed for wildcarding. It never takes
more than three DNS lookups. The first two can be requested in parallel,
an intelligent DNS server could return the CNAME as an additional record
for optimization purposes.

If this mechanism was adopted as policy for ALL prefixed records there
would no longer be any need to define new RRs unless there was a need to
define a new record syntax. It would also allow admins to manage their
policy records much more effectively, the default node is treated as if
it was just another node.


If folk really want to argue over the SPF=1 issue I think that they are
saying that the protocol is not really embedded enough to be beyond
change. If that is the case I think that we should fix the problem
caused by the exclusive appropriation of TXT.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf