> From: Jim Fenton [mailto:[EMAIL PROTECTED]
> Hallam-Baker, Phillip wrote: > >> [mailto:[EMAIL PROTECTED] 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
