Since the issue here seems to be precedent it seems more productive to discuss the choices draft. If people actually read choices they will realize that DKIM complies with the findings of fact there. Since 1) choices is not an RFC 2) the DKIM group have had extensive discussions with the DNS directorate and the choices draft author it seems to me that the effort in this forum would be better directed at examining choices and ask if this really reflects the best way to achieve everyone's goals. In particular there are architectural approaches proposed after the initial choices draft that have been raised with the editor of the draft and in DNSEXT that are not addressed in the draft. > From: Michael.Dillon@xxxxxxxxxxxxx [mailto:Michael.Dillon@xxxxxxxxxxxxx] > In fact, the issue of port 53 services being such an > important infrastructure leads me to think that the IETF > should freeze the DNS protocol definition for anything that > is not directly related to the job that port 53 servers MUST > do. Things like DNSSEC are OK, but leveraging DNS for a > global distributed database are not. Read the original discussions of SMTP that led to the development of DNS. You will find that the proposed use is entirely within the original scope that Jon Postel anticipated. DNS was originally designed to be multi-protocol and multi-network. That's why the class mechanism exists to support Heisod and CHAOS. The lack of protocol meta-data is a major reason for the difficulty of changing IETF protocols. The SRV record is a great leap forward, it would be even better if people actually used it to advertise their POP3, SUBMIT and IMAP services. > Since there is great interest in using the DNS protocol for a > distributed database, it would help to fork the DNS protocol > and deal with this work in a separate WG and using a separate > port number. There is already a revolt underway and people are using the DNS to distribute policy. One approach is to say 'we know best, la-la-la not listening'. A better approach that is more likely to have the desired effect is to define a protocol that meets these peoples needs. A second reason I intensely dislike this approach is that the DNS should be the one and only authoritative source for resolving information bound to a DNS name in the Internet class. There must be a single point of administration. A much better approach would be to specify a limited mechanism for distributing policy through the DNS. This would have two levels: 1) A very limited sequence of tag=value pairs to be used to encode the simplest forms of policy statement 'This sender always uses S/MIME', 'This sender always uses DKIM'. 2) A defined tag value that specifies a URI where a comprehensive XML encoded policy can be found. The reason for the two levels is that there are many useful protocol policy statements that are very simple and can be encoded in a very short response. It seems unnecessary to force people to pull a http URL out of the DNS and then extract a statement like 'DKIM' or 'STARTLS=TRUE' ot 'LDAP=ldap.example.com:2234'. We do not need to define a directory infrastructure to support the second level, URLs will do just fine. We use the DNS to provide the authoritative resolution protocol. Now lets consider the issues raised in CHOICES carefully Choices gives four options of which only two are viable: 1) Use a prefix record in the same manner as SRV and NAPTR To make this approach work we have to consider the prefix record as being in a sense a modifier to the semantics of the record being prefixed. So _DKIM.example.com TXT has its syntax defined by the DNS protocols and its semantics defined by the prefix. The disadvantage of prefix records is that it is not possible to define a wildcard of the form _prefix.*.example.com. So if an application requires the ability to make a default statement prefix records do not work without additional mechanism 2) Define a new RR This approach works so long as the deployed DNS infrastructure at the sender and receiver and all relays inbetween all support exchange of unknown record types. Wildcards work with a new RR ith the proviso that the wildcard semantics of DNS are not necessarily the semantics that the administrator would want. A wildcard only matches non-existant nodes. So some form of preprocessor is going to be required to define a default policy record that applies to every node in a zone. The disadvantage with this approach is that there are only 65,536 possible RRs. This is not currently a problem but is almost certain to become a problem if every protocol and every new Web Service requires a policy record. Now lets consider the essential goals that parties might want to achieve: 1) Deployment of DNSSEC This is dependent on the ability to deploy new RRs. 2) Deployment of DKIM base This does not need the ability to specify default keys and thus does not require wildcards 3) Deployment of DKIM policy This does require the ability to specify default policy and thus requires wildcards 4) Support for general extensibility of the DNS 5) Ensure general extensibility of the DNS does not lead to collapse of the DNS The last is critical of course but in a sense the DNS collapsed five years ago. It only operates today because a vast sum has been spent ($200 million+) keeping it running. The load on the core DNS is not caused by legitimate use. The load comes from misconfigured DNS systems and malicious attacks. The legitimate load is barely measurable. It is a major mistake to think that the DNS is so fragile that it can't be used to good purpose. We do however have a legitimate concern that goals 4 and 5 are potentially at odds. I don't think that the proposal made in CHOICES is optimal, that is I don't think that 'create a new RR for every use but establish a mechanism for vetting proposed uses' is optimal. The problem is that every RR that you add is a change to the DNS infrastructure, another opportunity for someone somewhere to mess up. The approach that CHOICES does not address is to solve the wildcard prefixing problem by introducing a new record that acts as a pointer, the Prefix Pointer record: PREPTR. To encode the wildcard record _prefix.*.example.com we create the following records: *.example.com PREPTR _preptr.example.com _prefix._preptr.example.com TXT "This is the default record" This has all the advantages of defining a new RR. Wildcards work, it is not necessary to define a new RR for every single protocol that might want a policy statement. All that is required to put out a policy statement is an IANA registered prefix. [In actual fact the PTR record could almost certainly be used for this purpose but introducing a new record has political benefits and creates a useful deployment incentive for DNS servers that support new records.] _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf