> 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. And since SMTP has been an utter and complete failure in operations, I find that to be a dubious point. In any case, we are not talking about a small research network here, we are talking about the global ubiquitous public communications network that is in the process of replacing the telephony network. SMTP and DNS were originally developed for that small research network. Many years of operational experience have shown that domain naming services, when properly implemented and properly maintained, are wildly successful and widely used. Success like that should be left alone. SMTP, on the other hand is an operational failure and even today, no one really knows how to properly implement and properly maintain an SMTP service. The actions of criminals exploiting weaknesses in the SMTP architecture have led to a series of bandaids that still have not proven to be effective. If the IETF wants to continue defining a stream of bandaids for SMTP, that is fine as long as they do not screw up the existing DNS infrastructure. One simple way to ensure this is to refuse to extend the DNS protocol as defined for use on port 53, the domain naming service. It might be a good idea to get to work on a new mail architecture which would replace SMTP, POP, SUBMIT and IMAP. At least now we know the use-cases very well including many corner cases exploited by criminals in their businesses. > DNS was originally designed to be multi-protocol and multi-network. > That's why the class mechanism exists to support Heisod and CHAOS. That's why it seems quite reasonable to continue work on the protocol as a more general distributed database service. But not on port 53 which is mission critical for the ONE NETWORK which rules them all. > 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. If that protocol was defined on a port other than 53, people would still use it. In fact, more people would use it because it can be deployed operationally without disrupting port 53 services. Decoupling this from domain naming makes it easier for people to get approval from their bosses who are terrified that their website might become unaccessible. That's life in the real world. > 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. Many years ago LDAP became a second authoritative source. The real issue here is whether LDAP or DNS is a better protocol for a distributed database. There is no need for that battle between LDAP and DNS to play out on port 53. As for a single point of administration, that is not a protocol design issue nor an engineering issue. > 2) A defined tag value that specifies a URI where a comprehensive > XML encoded policy can be found. Last time I looked, a URI was a string of text. Why wouldn't you just use a TXT record for this? In fact, why wouldn't you put all this extra information in another server somewhere and just put one TXT record with URI into the DNS. That way, the IETF does not need to weigh the costs and benefits of monkeying with domain naming services. > 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'. To me it seems unneccessary to force someone to decide whether or not to trust the source of an email message after the message has been received. If we had an email architecture based on a chain of trust, none of these band-aids would be necessary. > 5) Ensure general extensibility of the DNS does not lead to collapse > of the DNS In my view, this is job ONE! However I don't think the concern should be about global collapse. Rather I think the concern should be that monkeying with the DNS causes an increase in the frequency of local collapse, i.e. a single DNS server becomes unable to continue providing domain naming services. The owners of the domain naming infrastructure intend for it to be used for domain naming, not for solving everybody's need for a global distributed database. 1) The DNS protocol is a proven way to build a global distributed database. 2) There is a need for global distributed databases other than domain naming. 3) For some reason, LDAP has not gained traction as a solution for this need. 4) Therefore, the IETF should define a DNS protocol based alternative to LDAP that runs on a port other than 53. Once this is done, all new RRs should go into the new distributed database protocol. This also provides the opportunity for a new version of DNS, the domain naming service, that strips out all the unused cruft to enable domain naming service operators to simplify the software that they use. --Michael Dillon _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf