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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf