> From: John C Klensin [mailto:john-ietf@xxxxxxx] > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf