Subject: RE: SRV records considered dubious

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Nov 2006 12:02:16 -0800

> From: John C Klensin [mailto:[email-masked]] 

> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Tony Finch <[email-masked]>
Date: Wed, 22 Nov 2006 20:45:25 +0000

On Wed, 22 Nov 2006, Hallam-Baker, Phillip wrote:
>
> 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.

A matter that is close to my heart :-)

Why did this draft not get any further?
http://www.watersprings.org/pub/id/draft-hall-email-srv-02.txt

Looking back at something I wrote a year ago, I said that SRV records
don't provide higher-level settings, such as security requirements. The
email configuration problem is much more than just typing in the right
host names and port numbers: MUAs are generally dreadful at configuring
themselves securely using the in-band capabilities listed by the servers.
(e.g. whether to use TLS, what SASL mechanism to use, etc.) without
detailed hand-holding from the user.

In fact it would be pretty simple for an MUA to configure itself given
just an email address and some intelligent guesses, falling back to asking
the user for more information if the guesses fail. The intelligent guesses
are just based on informal host naming conventions (i.e. imap.domain,
smtp.domain, etc.) and standard port numbers, which together make SRV
redundant.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: EAST OR NORTHEAST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9.
ROUGH OR VERY ROUGH, BECOMING HIGH. RAIN OR SHOWERS. MODERATE OR GOOD.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 23 Nov 2006 12:35:29 +0100

Hello Philip,

You wrote:
> 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.

Personally, I favor of the more elegant solution of creating a new  
RR. I do understand the reality of being 'held hostage' by  
implementations that are not transparent to new RRs. Given that the  
trade-off has been made and the lack of wildcard support does not  
seem to be a problem I hesitantly consent with the use of TXT RRs in  
this case.

In general I think that we should make the 'being held hostage' part  
into account when doing the tradeoff. Supose 'Bob' has vested  
interest in deploying protocol FOO and there is an installed base of  
application X that does not work well with FOO.  We (protocol  
engineers) should drive to the cleaner approaches (a new RR type in  
this context) when Bob is in control of implementation X. If bob  
relies on Alice to upgrade application X then we may try to engineer  
around that (with label prefixes in this context).  That is a  
difficult case-by-case, and often a esthetic,  tradeoff between a  
clean future and fast and cheap way to market.

> 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.

I would like to make sure I understand. "The pointer mechanism"  
refers to your Nov 21st message:

> The approach that CHOICES does not address is to solve the wildcard  
> prefixing problem by introducing a new record that acts as a  
> pointer, the Prefix Pointer record: PREPTR.
>
> To encode the wildcard record _prefix.*.example.com we create the  
> following records:
>
> *.example.com                 PREPTR _preptr.example.com
> _prefix._preptr.example.com   TXT   "This is the default record"

So in order to solve the wildcard problem, that exists because we  
choose to use label prefixing, which we do because we cannot deploy a  
new RR type, we introduce a PREPTR RR?  That sounds like a broken  
circular dependency so I think I miss something.

Speaking as the IAB stuckee for draft-iab-dns-choices:
dns-choices is almost a done deal. It will need to be reved to refer  
to RFC2929bis (that doc should ease the process of getting RR type  
assignments). That reference is the sole remaining issue.

I also do not agree that the document should not proceed without  
addressing the pointer mechanism. The document is not of the type  
that specifies new solutions, it documents tradeoffs. If your pointer  
mechanism would be more than 'mail-ware' (i.e. had sufficient review  
and consensus) then it could have been part of the equation. I think  
that its to late for that.

(I've CC-ed the editor, too)

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/