Subject: use of MX by SIP

From: Keith Moore <[email-masked]>
Date: Fri, 25 Sep 1998 16:50:43 -0400

Someone pointed out to me that the current SIP draft specifies use of
DNS MX records to determine the location of SIP servers.

I think this is a Bad Idea, for the following reasons:

1. It is NOT reasonable to assume that SIP queries should go to the 
same hosts as incoming mail.  There is an increasing tendency to
centralize/consolidate mail services and redirect incoming mail 
for several different domains to one or more central mail servers, 
or even to an external service provider.  It's not reasonable to
assume that SIP services for a domain are maintained by the same 
administrators as maintain email for that domain.

2. It's confusing and counterintuitive.  If a mail administrator
wants mail for domain X to go to host Y, he has to set up an MX record
of the form X MX Y.  But if he doesn't want SIP queries to go to Y,
he then has to set a separate SRV record of the form X SRV {somewhere}.
Also, if the mail admin and the SIP admin are separate people, and
the mail admin changes MX records, he disrupts the SIP service without
the SIP admin knowing about it.  Why should the mail admin have to consider
the needs of the SIP service when deciding where incoming mail goes? 

3. It sets a lousy precedent.  What if SIP weren't the only non email
service using MX as a default?  If there were several such services, the
above problems would be considerably multiplied.

I believe SIP's proposed use of MX is an architectural violation
which requires strong justification before it can be endorsed in a standard.

Keith

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Sep 1998 17:36:27 -0400

> administrators as maintain email for that domain.

But it may well turn out to be quite common, since the idea is that my
published email and "phone" address are one and the same in many cases.
Indeed, the expected behavior is that I would have a business card with
a line of the form

email/ephone: [email-masked]

Why wouldn't I want to farm out these two services to the same central
server? The motivation (more "global" address and reliability) are
similar for both.

Also, in many cases, SIP and email service will both the only service
outside the firewall. They will often share databases, such as
vacation/"has moved" forwarding information or name mapping (John.Doe to
jd48). Since both services rely heavily on managing people information,
it doesn't seem completely unlikely that in all but the largest domains,
postmaster and "sipmaster" will be the same person, just like the
secretary who answers the phone also sorts the mail :-) 

Large domains should set up SRV records. 

> above problems would be considerably multiplied.

I agree that in the longer term, *only* SRV records should be used (or A
records).

I'm not sure I follow this completely. There are two scenarios:

- None of the mail servers host a SIP server (and there is no SRV
record).

In that case, the only drawback is that the SIP client will end up
trying to connect to the SIP port and get an ECONNREFUSED. Except for an
additional SYN packet, the mail server won't be affected. If this
becomes an issue for a particular domain, the fix is easy: set up an SRV
record. It is tried first, so that the mail servers will never see an
errant SIP query again. If this encourages the deployment of SRV records
in large domains, this can't be altogether bad :-)

Note that this scenario can only exist successfully at all if the mail
server also has an A record of the same name. Otherwise, SIP queries
will fail completely for that particular SIP URI.

- One or more of mail servers also hosts a SIP server, but the mail
admin moves the mail server to a non-overlapping set of servers and
doesn't tell the SIP admin.

In organizations of the size where responsibilities are as finely
divided, the mail admin should've told the SIP admin to please find a
different host and either tell people to use SIP URIs with A or SRV
records.

The only consequence is again that SIP service fails; mail service is
completely unaffected. The SIP admin will learn quickly not to rely on
the mail admin and learn about SRV records.

Thus, it is completely up to the organization to decide where to place
servers. Absence of SIP servers at an MX record does not in any
significant way impact the operation of mail servers.

The use of MX records offers a transition period until SRV records are
more widely deployed (particularly in terms of access software). If we
do not allow that, then we are basically back to host-specific addresses
for SIP, which defeats a major purpose of the protocol. Requiring use of
SRV records, which aren't even an Internet standard at this point, seems
to hurt more than it helps.

I would support strong language to the effect that all domains
implementing SIP service SHOULD use SRV records, assuming the previous
item (lack of standards status of SRV) does not prevent such a
statement.

-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 25 Sep 1998 16:56:49 -0500

There are many Internet services used by the same people at the same time,
mail and phone probably foremost on the list. Consolidating the records can
be considered a nice service integration feature in the operational domain.
In this light, using the MX records looks like good idea.

Thanks, Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Keith Moore
> Sent: Friday, September 25, 1998 3:51 PM
> To: [email-masked]
> Cc: [email-masked];
> "authors:;authors:;authors:;;;;"@cs.utk.edu;;;;;;;;;;;;;;;;;;;;;;
> Subject: use of MX by SIP
>
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Sep 1998 22:27:50 -0400

> In this light, using the MX records looks like good idea.

I'm not convinced.

Just because people want to use the same names in different services,
it doesn't follow that the locations of the services corresponding to
a name should be the same.  In fact, there are compelling reasons for 
allowing the services to be in different locations, and for using simple 
and easily understood algorithm to do the mapping.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Sep 1998 23:58:28 -0400

> published email and "phone" address are one and the same in many cases.

Indeed the "addresses" (actually they're "names") may often be the
same, and this is a Good Thing.  That's not the same thing as
expecting the phone service (or even the SIP service) to be handled by
the mail host.

Using the email and phone example, I might well want email for
[email-masked] to go to the email server for the CS department, but
I might want phone calls for [email-masked] to go to a gateway that
does a directory lookup and routes the incoming call to my desktop
POTS phone via the UTK campus phone switch.  The same name is used in
either case, but it maps to dissimilar services, ultimately handled by
very different kinds of hardware, in different administrative domains.

> jd48). 

Not clear, as given in the example above.

> Since both services rely heavily on managing people information,

Not completely unlikely, and it should certainly be possible to do
things that way.  What we're arguing about is whether MX should be
assumed as a *default* (in effect, subtly changing the meaning of MX).

> I agree that in the longer term, *only* SRV records should be used (or A

I don't agree with this either, unless you're referring only to the
use of MX records by SIP.  Mail should continue to use MX records.  To
change the behavior of mail would introduce operational instability
for no good reason.

> record. 

Yes, but the admin for that mail server somehow has to realize that
he/she needs to do this.  It fails the principle of least surprise.

> It is tried first, so that the mail servers will never see an

On the contrary, there's no reason that the admin should have to
install a SRV record for SIP unless he's/she's actually supporting
SIP.

> doesn't tell the SIP admin.

As I've illustrated above, there are good reasons to insist that a
mail admin should NOT have to coordinate with the SIP admin at all on
this.  Having SIP using MX introduces unnecessary administrative
hassles in the long-term, for dubuious short-term benefits.  I don't
think that makes a good engineering tradeoff, especially for something
that might be as widespread as internet telephony

Continuing my example above of the mail/phone split: For the UTK CS
mail server admins to coordinate with the UTK campus phone people
(*and* the UTK.EDU DNS people) on the arrangement of servers, takes
something similar to an act of Congress.  I don't think it is at all
unusual for an organization's phone people to be distant from it's
computer networking people.

> the mail admin and learn about SRV records.

What ensures that the SIP admin will notice the problems and properly
diagnose them?  As the need for sysadmins increases, and the demand
for talented people in more interesting jobs increases, the average
level of sysadmin expertise is decreasing.  We need to be making new
systems simpler to administer than those that already exist.  Most of
the new sysadmins I meet these days are not very adept at diagnosing
cross-system failures.

Also, in analyzing bounced mail messages from my mailing lists, I have
found that that approximately 40% of it is due to mail system or DNS
mis-configuration (e.g. SMTP server doesn't know it's an MX for domain
foo, or inconsistent DNS zones with the same serial #), and 10% due to
resource limitations (out of memory, or disk space) which often go
undetected by the mail system administrator for several days or weeks,
and occasionally months.

> significant way impact the operation of mail servers.

The problems occur when the people who run the MX servers and the
people who run the SIP servers change things without consulting one
another.  And in general it's a good idea to minimize confusion and
the liklihood of configuration errors whenever possible.

> for SIP, which defeats a major purpose of the protocol. 

No, I don't think so.  When I looked at a similar question with regard
to NAPTR deployment, if I recall correctly, most DNS servers could
cache unknown record types and forward queries of unknown types.  So
only the zones that wanted to provide NAPTR records had to upgrade
their DNS servers.  In the worst case when the query through the
resolver failed, the client could still explicitly ask for NS records
for the zone, and consult one of those servers directly, to do the
query for NAPTR records.  We wrote client code to do this, and it
seemed to work.  Why wouldn't the same technique work with SIP?

Keith

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 26 Sep 1998 21:53:26 -0400

> expecting the phone service (or even the SIP service) to be handled by

Just to review for the general audience what currently is supposed to
happen, in a nutshell, when resolving [email-masked]:

(1) SIP client attempts to access SRV record for example.com

(2) If and *only* if there is none, it tries to see if example.com has
an MX record and checks if any SIP server is at whatever the MX record
points to.

(3) If that should fail, it uses A records.

Thus, this mechanism allows, but does not in any way require the SIP
service to be handled by the mail service. This choice is made by each
organization, depending on local needs.

> very different kinds of hardware, in different administrative domains.

Nothing in the current arrangement prevents this solution.

> Not clear, as given in the example above.

It's obviously hard to predict the exact uses of a protocol which isn't
exactly widely deployed. By the time we reach draft standard, we
hopefully have a much better idea.

> change the behavior of mail would introduce operational instability

Since only SIP is up for discussion here, that's what I meant.

> he/she needs to do this.  It fails the principle of least surprise.

The mail server doesn't have to do anything. It won't notice what's
happening. If we were to take out MX records, the functionality would be
exactly the same.

> install a SRV record for SIP unless he's/she's actually supporting

Exactly. SRV records are only useful if you support SIP. If you just
provide email service, you do nothing.

> computer networking people.

As I've tried to say in a few different ways, if you don't want to
coordinate, don't. In your case, just install an SRV record for the SIP
server and don't even mention it to the mail folks. They'll never get
bothered by your internet telephony services. By taking the MX option
away, you are taking the *possibility* of doing coordination away. You
will have to install SRV records unless you want to have just an A
record (something like the old [email-masked].)

> the liklihood of configuration errors whenever possible.

Once again, if your organization is large enough to have this problem,
by all means, separate the functionality. Just don't take the
possibility of coordinated servers away from everybody.

> seemed to work.  Why wouldn't the same technique work with SIP?

The client side is reasonably easy, although I had to rewrite resparse
to handle SRV records.  The MX solution allows to install SIP servers in
some/many circumstances without having to change your DNS records. Once
SRV records are widespread on DNS servers, clients will automatically
cease to look at MX, with no harm except an additional few lines of
client code. Clients are  mandated to support SRV (if the IESG lets us
get away with it because of the current status of SRV records, as
mentioned earlier), but changing DNS servers to support SRV is often
even more difficult than coordinating email service, particularly if you
get your DNS service from a third party such as your ISP. This seems to
be quite common for many smaller domains. 

In summary, the use of MX records in no way constrains the operation of
your domain as nothing forces you to offer SIP service on your MX host. 
It just gives you another option when changing your DNS service/software
is harder than adding a SIP server to the email server under your
control.

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Sep 1998 23:47:29 -0400

> organization, depending on local needs.

That's clearly not the case when the SIP admin relies on the MX
record being there.

If on day one the MX record happens to point to the SIP server
host, and the SIP admin relies on the MX record being there, then
when the mail admin changes the MX record to point to some other
host, the SIP users lose.

> Nothing in the current arrangement prevents this solution.

No, but the current arrangement is needlessly complex and difficult
to understand, and leads to subtle and surprising behavior.  

> server and don't even mention it to the mail folks. 

Why not make the rule even simpler:

"if you want your SIP server to work, install an SRV record".

It's simple, easy to understand, and makes it easy to analyze failures.

Why tempt people to rely on the MX records when they're very 
well-established as being specific to mail?

> They'll never get
> away, you are taking the *possibility* of doing coordination away. 

nonsense.  IF you want to do coordination, install both MX and SRV
records and make them point to the same place.  

You have complete flexibility with either scheme about whether
your coordinate servers or not, but in the case where SIP clients 
use MX you introduce a greater potential for misconfiguration.

> possibility of coordinated servers away from everybody.

again, that's nonsense.

I'm not suggesting anything of the sort - just that it's completely
inappropriate to overload the meaning of a well defined DNS RR for 
new purposes, and that it will cause harm to do so.

> some/many circumstances without having to change your DNS records. 

"not having to change your DNS records" doesn't sound very compelling.

(though I suspect you meant "without having to change your DNS servers."
even then, my understanding is that named with SIP support has been
around for a while now...and as long as you're installing a SIP server,
how great a hardship is it to also upgrade your DNS server anyway?)

> Once
> client code. 

not so.  the client code will be there to bite people for a long time,
for the odd case where the SRV record disappears.  it's not inconceivable
that the MX host also supports a SIP server for a different domain, so
using MX might even cause SIP queries to go to the *wrong* server.

> Clients are  mandated to support SRV (if the IESG lets us
> mentioned earlier), 

the opinion of several IESG folks is that SRV can go to proposed (perhaps 
with minor tweaks) as soon as anything that needs to refers to it  
goes to proposed.  but maybe we should go ahead and advance SRV to put
DNS implementors/admins on notice that standard protocols will be using it.

> but changing DNS servers to support SRV is often

in that case it's more difficult for the first customer who wants to
use SRV, but less difficult for customers 2..N (as compared to customers
who run their own DNS servers, where each one has to upgrade)
 
> is harder than adding a SIP server to the email server under your

Adding more options isn't necessarily a good thing.

Keith