From: John C Klensin [mailto:john-ietf(_at_)jck(_dot_)com]
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.
I don't see a contrast there, I see only a minor technical difference that has
no real consequence.
If you want to make the case that there should be clearly defined sematics for
each defined SRV label, possibly backed by a separate RFC I agree. We do not
need to define a new RR for that.
For example every ISP has to spend time and money helping their customers to
configure their email clients to locate their POP3, IMAP and SUBMIT servers.
Those costs could be eliminated if email clients looked at the relevant SRV
records rather than requiring the user to become an administrator and enter
this data.
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.
Again, none of this requires a new RR, all that it requires is that someone
document the process.
The use of prefix versus new RR has no bearing. I see no reason to believe that
the outcome would have been any different if people had anticipated other uses
and defined the SRV record instead of MX and reserved the _smtp._tcp protocol
for use with SMTP.
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.
The issue that Phillip has raised repeatedly is that the wildcard record has no
bearing on the choice of a prefix record versus a new RR. The wildcard issue
can be solved without creating a new RR (the PTR record would work fine in
place of PREPTR).
The issue here are
1) DKIM does not have a requirement for specifying default key records. The
need to solve the wildcarding problem does not therefore arise and there is no
TECHNICAL reason to prefer RR over a prefixed record and significant DEPLOYMENT
reasons to choose prefixed records over TXT.
2) CHOICES should not proceed until and unless it specifically addresses the
pointer mechanism for handling prefixed wildcards. I am willing to propose text
and even to take over the editorship of the draft if the current editor is
unwilling.
I note that nobody responding to these threads ever acknowledges or contradicts
either of these points above. Instead we simply get a reiteration of the claim
'do it our way it might not be as bad as you imagine and if it does turn out to
be a problem you can blame the Redmond club'. That does not persuade me.
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.
A prefix label is simply a sequence of octets in one part of a DNS query, an RR
is simply a sequence of two octets in another part of a DNS query. I see no
reason to imbue this with any more significance than that.
If we ignore the fact that getting pigs to fly requires
extraordinary means...
All it needs is an airplane http://www.bookmice.net/darkchilde/janime/porco.html
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.
From which a reasonable conclusion would be that all three approaches are
appropriate and that we should not falsely conclude that only new RRs are ever
appropriate.
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).
This would still be an issue if you define a new RR unless you have
documentation to resolve the ambiguity.
SRV prefixes are no different to new RRs both are (potentially) IANA issued. We
can resolve the ambiguity by writing appropriate RFCs.
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.
Why does this matter for the case of non-litterate user trying to configure
their email?
If there is no SRV record their email client will ask them to enter the data
manually and the user will have a more unpleasant, less satisfactory experience
(try finding the documentation on this on the comcast.net site in less than ten
minutes).
If there is an SRV record and there is no service the user will call customer
service and if the ISP is going to stay in business very long the problem will
be fixed same as any other network operator foulup would be.
The mere fact that something failed thirty years ago in one particular form
does not tell us useful information about today.
WKS died because the information it provided was never acted on by application
programs. The typical Internet user either had an advanced degree in Computer
Science or was studying for one. The cost and complexity of administrative
action were effectively hidden.
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).
If you resolve an SRV record, find the list of fallover services, try each one
and none of them respond to you then empirically that service is not available
at that particular time.
What could be a more convincing demonstration?
In fact I would state that BY DEFINITION if you complete the service resolution
steps specified by a protocol and fail to find a service that that service is
not available.
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).
There is no question that wildcarding an SRV record is a very bad idea
So given that we have SRV and NAPTR records it would seem to be a good idea to
provide a way for people to achieve wildcard functionality without wildcarding
a prefixed record.
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).
The DNS only makes authoritative statements about the present. It makes no
assertions about the past or the future.
If you find an SRV record but cannot resolve it to a service then that is a
good indication that there might be a service that might be available at
certain times.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf