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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jim Fenton
Sent: Monday, October 16, 2006 7:18 AM
To: Eliot Lear
Cc: Scott Kitterman; ietf-dkim(_at_)mipassoc(_dot_)org
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