RE: [ietf-dkim] New Issue: New resource record type

["Hallam-Baker, Phillip" <[e-mail]>]

There are currently two proposals:

1) Use the existing prefix scheme to a TXT record
	PRO: Is the status quo
	PRO: Is 100% compatible with legacy infrastructure
	CON: Does not wildcard unless heuristics are used 
		that change DNS administrative boundaries

2) Define a new record
	PRO: Wildcards well
	CON: Only 50% compatible with legacy infrastructure
	CON: Bifurcated deployment, changeover will be slowly 
		completed if ever
	PRO: Acts as forcing function for deployment of 
		DNSEXT/DNSSEC
	CON: Deployment is at the pleasure of the providers of 
		DNS server infrastructure.

The following vital interests are identified (whether or not they are legitimate is irrelevant, they are considered to be vital by the promoters).

1) Promote deployment of DKIM

2) Promote deployment of DNSEXT/DNSSEC

3) Ensure that DKIM policy retrieval resolves in fixed number of steps and does not change the DNS semantics.

4) Support definition of policy records for other protocols (inbound email, HTTP, Web Services, etc.)

I believe that it is possible to meet all of these interests so it is not necessary to debate whether they are essential.


The proposal I have is that we stick to the current prefix mechanism for advertising policy but introduce a new record POLICY that acts as a pointer to a location where the policy prefix can be resolved.

Existing policy records are unaffected. The only thing that is changed is the method of handling wildcard lookups. If the prefix lookup fails the resolver looks for an unprefixed POLICY record. If the record is found the resolver attempts to find a prefixed policy record at the location specified in the POLICY record.


This mechanism has all the advantages of the existing proposals and none of the disadvantages. It is also more convenient to use since pointers may be used for more than implementing wildcards. A network administrator for a large site would probably want to create different classes of policy record corresponding to different classes of host. This allows for a single point of administration for the class rather than requiring individual changes to each host record.




> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jim Fenton
> Sent: Monday, October 16, 2006 7:18 AM
> To: Eliot Lear
> Cc: Scott Kitterman; [e-mail]
> Subject: Re: [ietf-dkim] New Issue: New resource record type
> 
> Eliot Lear wrote:
> > Jim,
> >
> > Fair points.  One possibility, by the way, is that we use the SAME 
> > prefix but simply with new attributes.  That way you get the whole 
> > thing in one shot.
> >   
> I'm not sure what you have in mind here.  One of the benefits 
> of using a new RR type is that it may allow us to get away 
> from the use of a prefix entirely, which in turn may shorten 
> the search process by detecting nonexistent domains more 
> easily.  I'm not certain how well this mechanism works, but 
> you can see what I'm talking about in draft-allman-dkim-ssp-02.
> 
> -Jim
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html