From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
Hallam-Baker, Phillip wrote:
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Jim Fenton
(2) SSP record type (TXT vs. something new). Only 4 messages in
discussion, mostly saying "if you support TXT, don't bother with
anything else." Again, no clear consensus.
I see no value in an SSP record type. The downside for DKIM
is serious - we are gated on new deployments of DNS server
code. The downside for the DNS described above is equally serious.
If we would be gated on new deployments of DNS server code,
wouldn't this be equally true for XPTR records?
No, wildcard policy is a luxury, not an essential part of the spec.
As I point out the policy for my domain is likely to be
verisign.com "ALL Mail is signed"
ops.verisign.com "ALL Mail is signed"
**.verisign.com "No mail is sent"
I don't see how I would end up in a situation where I attach a wildcard to a
policy that says all mail is signed. Since NOMAIL is out of scope it is
entirely acceptable to present the following options:
1) You can deploy DKIM policy for specific domain records using your existing
DNS server.
2) To deploy a wildcard policy you will need to upgrade your server if it does
not support new RRs
If I thought there was a serious deployment issue here I would still be pushing
my original scheme to hijack PTR in the forward DNS for the same purpose as
XPTR.
I would have expected this comment from the DNS directorate
if there was threat of running out of DNS RRs, but much the
opposite: the IAB "DNS choices" draft recommends creation
and use of new RRs.
The DNS choices draft represents old thinking on the problem. It does not
address the situation we now face in Web services.
We are not in an imminent danager of running out of RRs because nobody who is
using the DNS for policy distribution is following the advice in choices.
Instead people are defining their own prefix schemes and ignoring choices.
I'm not clear on what "only do TXT" means in this context --
do you mean a directly referenced TXT record or one retrieved
via an XPTR lookup or both?
The policy record is only expressed using TXT
The discovery process being first look for TXT, if that is not find look for an
XPTR and if found a TXT of the XPTR node.
3) There is an advantage to DKIM in encouraging deployment
of DNS servers capable of DNSSEC.
Yes, but I don't see how that is relevant here.
It is the real reason why choices is written the way it is.
I think that this is where we reach the 'non-negotiable'
issue for the DNS cabal. Misimplementation of upward query is
a major cause of load on the DNS. The DNS cabal will complain
loudly on this issue and they will actually have a case.
"...is a major cause": currently? I don't see how we can
design any protocol that is misimplementation-proof.
An algorithm that contains a loop is more likely to be error prone than one
that always completes in a finite number of steps.
Agree that the NOMAIL policy is the more interesting one to
express with a wildcard. There are some cases where it might
be convenient to express a signing policy for subdomains, but
in every case I can think of it's practical for the
subdomains to publish their own SSP record.
Hence my belief that gating wildcards on a new RR is acceptable while gating
policy itself is not.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html