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.
actually the SRV record can easily be a step sideways or backward if not
carefully used. let's see...it slows down session establishment;
increases the load on DNS; increases the potential for failures due to
misconfiguration, link congestion, link failure, or server failure; and
in some cases gives ISPs yet another hook to impose walled gardens on
their customers, decrease the transparency of the network, and thus
impair the ability of the network to support new applications.
there are cases where SRV is useful, but it's a big stretch to call it a
great leap forward.
(and of course none of this has any bearing on DKIM.)
p.s. rather than adding more and more burdens to DNS, what we really
need to be doing is figuring out how to replace it with something more
robust and more flexible. (Yes, you'd have to arrange that DNS queries
and queries to the new database would return consistent results; you'd
also have to make sure that DNSSEC didn't break, but those are both
DNS is getting very long in the tooth, and is entirely too inflexible
and too fragile. The very fact that we're having a discussion about
whether it makes more sense to add a new RR type or use TXT records with
DKIM is a clear indicator that something seriously is wrong with DNS.
Adding a new RR type should not require a single line of DNS server or
client library code to be recompiled, nor any changes to the
configuration of any server not advertising such records.
Ietf mailing list