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

[Douglas Otis]

On Apr 16, 2007, at 5:34 PM, 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.

This assumes a simple authorization scheme is not effective at  
protecting a principal domain.  For example, if the industry creates  
a list of domains used for the purpose of registries, then this would  
identify precisely which domain should be queried.  As there are some  
TLDs publishing MX records, such a list becomes even more important  
from the prospect of limiting the scope of TLDs with respect to DKIM  
sub-domain validations.

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

This is a clever idea, but perhaps a bit late in DNS's evolution.   
The additional overhead is unlikely to become automated, or even  
supported within the corporate environment.  From a DDoS perspective,  
any wildcard scheme can be perilous.

As an industry, establish a list of domains used by registries.  This  
approach facilitates rapid discovery of any number of record types,  
and not just policy related records.

-Doug