[ietf-dkim] New Issue: Use of XPTR records in SSP

Scott Kitterman ietf-dkim at kitterman.com
Mon Apr 16 23:41:16 PDT 2007


On Monday 16 April 2007 20:34, Jim Fenton wrote:
> This is the first of a few issues that come in trying to rationalize at
> least two of the SSP proposals, draft-hallambaker-dkimpolicy-00 and
> draft-allman-dkim-ssp.  I'd like to keep the issues separate, because I
> think they're largely independent, so please respond in kind if at all
> possible.
>
> =====
>
> Phill Hallam-Baker has proposed the publication of a new PTR-like  RR
> type, tentatively called XPTR, in order to improve the scalability of
> the SSP mechanism to a large number (~1000?) of additional types of
> policy in the future.  To look up the signing policy of example.com, the
> sequence would be:
>
> 1.    Query for XPTR record for example.com.  If result is an NXDOMAIN
> error, the domain does not exist.  If result is a NODATA error, either
> the policy or the domain does not exist.
> 2.    Query for [RRtype TBD; separate issue] record for
> _dkimpolicy.{result of XPTR query}; policy record is stored at that
> location.
>
> Argument Pro:  Supports a potentially very large number of policies, as
> might be needed for WS-* (for example) in the future.  Permits a central
> point of control and modification for policies relating to different
> classes of nodes in the domain.
>
> Argument Con: Requires an additional lookup per query; other types of
> policy are out of scope for the WG.
>
Additional arguement Con is that a new RR type takes a LONG time to deploy.  
In 2 - 5 years when this new RR type is deployed, whatever problem it was 
trying to solve will likely be solved some other way.

Scott K


More information about the ietf-dkim mailing list