--On Tuesday, 21 November, 2006 21:28 -0800 Dave Crocker
<dhc2(_at_)dcrocker(_dot_)net> wrote:
John C Klensin wrote:
And, to add one more observation to Keith's list, unless one
is extremely careful, especially when considering using SRV
to add
...
there are cases where SRV is useful, but it's a big stretch
to call it a great leap forward.
As usual, I am confused.
The MX record was, in fact, a great leap forward (after a
number of false starts.) I can tout its success vigorously
because I had nothing to do with it but have always marveled
at how profound its benefit has been. Indeed I'd be happy to
wax extensively on the basis of my views, but I suspect that a
scholarly consideration of the MX contribution is not quite
the focus for this thread.
And, one way or the other, we would also agree about that.
SRV instantiates the MX service model, except for other
protocols.
Whatever you mean by "service model" (I can think of several
definitions in this context), there are some important
differences. First, MX is based on an RR type that is very
protocol-specific. Nothing but email sending uses it.
Discussions a few years ago (in DRUMS, I think) as to whether it
would be useful to have sending MUAs who were looking for
submission servers to query for MX records led to a "no"
conclusion: it is used strictly by SMTP MTAs looking for a host
to which to deliver the mail. By contrast, SRV records depend,
not on a per-protocol RR type, but on naming conventions in the
labels and on the content of the data field as a key part of
what I think of as the service model.
That "RR per protocol" model was, in the case of MX, coupled
with a clear and required fallback when the MX record was not
available, made transition to it feasible for deployed
applications. The fact that it is RR per protocol also made it
more feasible for MX queries to return the A RRs associated
target to be returned as additional information in the obvious
case, reducing turnaround times. And, of course, it facilitates
a solution to the wildcard issue that Phillip has raised
repeatedly.
As long as we ignore the underscore names, etc. "encoding"
methods that were chosen for defining a particular SRV -- and
by ignore, I mean ignore, rather than imply anything positive
or negative -- then I do not see why SRV is more (or less)
dangerous than MX.
Because SRV is multi-protocol, rather than single-protocol, in
the definition of the RR type, and the way of distinguishing
protocols is via that particular naming convention, I don't see
how one can ignore them. They are part of the very nature of
SRV and of what makes SRV and MX not strictly comparable.
If we ignore the fact that getting pigs to fly requires
extraordinary means...
Or perhaps I should be asking: MX was excellent for a
particular service model. And rendezvous requirements do
suggest that there is benefit is being able to have different
services, under a generic domain, vectored to different actual
hosts.
Sure. No disagreement there. But, if one gets that far, and
equates the "service model" of SRV with that of MX, then we
plunge into the argument about per-protocol RR types rather than
various interesting workarounds. And I think that topic has
been discussed adequately in recent days -- at least I've seen
nothing new.
So:
1) Aren't there other instances of that model -- I'll call
it a proxy or store-and-forward model;
I think there is a persuasive case to be made for the DNS to be
used to locate servers for particular services. I think that
case is broader than anything I would describe as "proxy" or
"store-and-forward", but it does not seem to me that puts us in
disagreement.
2) Aren't there other models that it could be useful for?
See above. However, it seems to me that we have three different
models for doing this right now. I would characterize them as
the MX one (one record per protocol), the SRV one (multiple
protocol, protocol differentiation based on label naming
conventions), and the NAPTR one (multiple protocol, protocol
differentiation based on information in the data field). I
assume that each model has advantages that outweigh the others
in different situations. Whatever the merits of each, or their
appropriateness to particular situations, I don't think one can
extrapolate from the success or failure of one to the
desirability another.
If there are cases for which SRV is "dangerous" for, what are
they? What makes them more dangerous than, say, using MX
records?
I saw the long list of generic dangers of using the DNS for
anything. My question is for what cases using SRV is
particularly bad and why?
While I find SRVs distasteful for various aesthetic reasons
having to do with dependence on naming conventions and on
difficulties in figuring out whether to construct a name based
on the local domain, the target domain, or some domain
determined out of band, I wouldn't presume to try to answer that
question (except for the one case mentioned below). It also is
no part of what I said. What I did say was in the piece of my
comment you didn't quote. Several people have made arguments
that I construed as "the advantage of an SRV record is that, if
it is present, you can tell that the service is supported and,
if it is not, then the service is not supported".
For existing protocols suggested for upgrading to SRV (POP,
IMAP, SMTP Submission were mentioned, if I recall), neither is
true and we should have learned that from the failure of WKS to
tell us anything useful. For new protocols that are defined in
terms of "find the SRV record or give up", the presence of such
a record tells us that the service was offered once, or intended
to be offered in the future, or perhaps is offered now, but
doesn't tell us anything about service availability (another WKS
lesson). The absence of such a record does tell us something,
but that information requires that the absence be authoritative.
And, since SRV depends on a specific set of naming conventions,
wildcards become even more dangerous than they are with address
RRs (which are more dangerous than wildcards on single-protocol
RRs such as MX).
And, of course, having protocol decisions depend on a
requirement for authoritative negative responses does have DNS
performance issues, but there are others more qualified to
address that issue than I am. And some protocols may not care
-- as long as no one makes the assertion that the absence of a
relevant SRV record is used to determine that a service is not
supported (rather than not being accessible right now).
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf