Subject: [xmpp] SRV record extension

From: Nobuo Ogashiwa <[email-masked]>
Date: Sat, 17 Mar 2012 01:27:24 +0900

Dear all,

We have submitted following I-D:
http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00

After the 2011/3/11 earthquake in japan, we are interested in
reliability and stability of XMPP-based systems.

The RFC6120 defines that the XMPP server and client use SRV record for
reliability.  However, most of standard libraries in client OS like
MacOS, Windows, Linux and *BSD does not support SRV record
resolution. Furthermore, many DNS hosting services do not support SRV
record registration. So that there are some cases that we can not get a
benefit of SRV record in the global internet environment.

So, we have proposed IQ message extensions to query and reply multiple
server hostnames in our I-D. If you want to know the details of
extensions, please see our I-D.

In technically, the above problem can be solved by using TXT record instead
of SRV record (and also extensions we proposed in our I-D).
The TXT record solutions is just like following:

 TXT="sv1.example.com:5269:0:10,sv2.example.com:5269:10:10".

We think this would be an alternative solution of the problem we
mentioned in the I-D.

We think that maybe extensions we proposed in our I-D should be
published as not I-D but XEP.  However, TXT record solution I
mentioned in this e-mail should be discussed not XSF but IETF XMPP WG.

So we would like to know how many people in IETF XMPP WG are
interested in reliability of the XMPP.

If you are interested in reliability and stability of XMPP-based
systems, please send comments or suggestions for our I-D.

Regards,
Nobuo Ogashiwa

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Mar 2012 11:15:17 -0600

> mentioned in this e-mail should be discussed not XSF but IETF XMPP WG.

Hello Ogashiwa-san!

Why not use XEP-0156 ("Discovering Alternative XMPP Connection Methods")?

http://xmpp.org/extensions/xep-0156.html

I realize that XEP-0156 says "A domain SHOULD NOT present information in
DNS TXT records that is available via the DNS SRV records defined in RFC
6120." However, it might make sense to relax that rule, or describe when
it is appropriate to override the SHOULD NOT.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Matthew Wild <[email-masked]>
Date: Fri, 16 Mar 2012 17:46:32 +0000

Hi,

Thanks for your draft. It's interesting. But I have a number of issues
with both its defined problems and solutions. Comments inline...

> MacOS, Windows, Linux and *BSD does not support SRV record

I think the widespread availability of clients and servers for all
these platforms suggests this isn't really that much of an issue.

> benefit of SRV record in the global internet environment.

I don't have data on the capabilities of DNS providers, but I
personally haven't encountered one that doesn't support SRV for years.
While I'm sure some are still out there, all the popular ones support
them. Adoption of SRV support was greatly increased by Google's usage
- anyone who wants to delegate a domain to Google must use SRV.

> extensions, please see our I-D.

Deploying this technique would not interop with the existing network.

>  TXT="sv1.example.com:5269:0:10,sv2.example.com:5269:10:10".

TXT is also a second-class citizen as far as resolvers and DNS
providers are concerned. If your stated problems with SRV are valid,
then I think you should be just as concerned about using TXT records.

> systems, please send comments or suggestions for our I-D.

I think this proposal has little to do with "reliability" as such.
Your goals are to solve perceived problems with the DNS location
mechanism currently used in XMPP, that are easily solved by using
appropriate DNS libraries and DNS hosting providers.

DNS is already a reliable distributed system for locating servers, and
is used successfully by XMPP clients and servers all over the internet
on every platform. Duplicating DNS at the XMPP level has a number of
problems, including interop with the current network.

If you have specific evidence to the contrary of anything I've written
here, I would be interested to see that.

Regards,
Matthew

---

From: Florian Zeitz <[email-masked]>
Date: Fri, 16 Mar 2012 19:14:46 +0100

Hi,

I have to agree with Matthew on this point. Just to stress this:
Microsoft Windows provides the DnsQuery() call, which can return a list
of SRV records (nicely put into structures even).

On MacOS X, Linux and *BSD (also Haiku and likely some others not in
your list) the res_search() function is usually available.
It is considerably harder to use than DnsQuery() (particularly parsing
the result), but that's far from necessitating a new RFC.

Regards,
Florian Zeitz

---

From: Jack Moffitt <[email-masked]>
Date: Fri, 16 Mar 2012 12:22:40 -0600

>> these platforms suggests this isn't really that much of an issue.

SRV support is readily available in system libraries on all modern
platforms, and has been for at least 4-5 years. On OS X and Linux, you
use res_query, and on Windows systems you use the APIs form
dnsapi.dll.

You do have to implement the server selection algorithm, but you can
easily get the contents of SRV records without any external
dependencies.

You can see examples of both of these here:
https://github.com/metajack/libstrophe/blob/master/src/sock.c

jack.

---

From: Philipp Hancke <[email-masked]>
Date: Fri, 16 Mar 2012 23:08:16 +0100

> please send comments or suggestions for our I-D.

As some other people I disagree with the statement about the 
availability of srv resolvers -- for *nix there is public domain code 
from 1997 written by Arnt Gulbrandsen which does SRV resolution in 250 
lines of code. SRV support in jabberd14 dates back at least to 2004 IIRC

In general, the examples remind me of very old stuff like iq-auth (the 
usage of jabber:iq hints at this as well).
It's not clear to me whether the stanza flow is supposed to happen 
before authentication (where it would be useful) or afterwards.

Since the "Reconnection Policy Information" relies on the client to 
query (poll?) the information I don't see how adapt this to "lively 
clients".

        to="[email-masked]"
is lacking a resource btw.

---

From: Nobuo Ogashiwa <[email-masked]>
Date: Mon, 19 Mar 2012 14:30:02 +0900

Hello Peter,

Thank you for your helpful comments.
We will consider using XEP-0156.

There are some another view about TXT record as the substitutes for
SRV record, so I will consider such all opinion.

However, I realized it might be in different situations for each
country that SRV records support status.
Especially, in japan, TXT record is supported by most of all famous
japanese DNS provider to support SPF, but SRV record is not supported
by most of all famous japanese DNS provider.
We have summarized SRV record support status in japanese famous DNS
providers, please see http://nlab.jp/japan-dns.pdf .

Regards,
Nobuo Ogashiwa

2012/3/17 Peter Saint-Andre <[email-masked]>:
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Akari Harada <[email-masked]>
Date: Mon, 19 Mar 2012 20:30:27 +0900

Dear Matthew,

I'm Akari Harada, first author of the draft.

As nobuo said in the above email, we recently realized that it
might be in different situations each country that SRV records support
status.
For example, the US's popular DNS hosting service, such as
networksolutions and godaddy supports SRV record. And we are using
networksolutions too.

However, unfortunately almost all Japanese popular that one doesn't
support SRV record.
In contrast, TXT record is supported large number of Japanese that one
for support to SPF.
We have summarized web pages of japanese DNS hosting service provider,
please see http://nlab.jp/japan-dns.pdf .

As most of Japanese company using SPF with TXT record, DNS hosting
service supports for a TXT record.
However, because of the reason it is supposed that no need to SRV
record by Japanese company, Japanese DNS hosting service does't
attempt to support SRV record.
For this reason, we introduced the idea in the mail before that is
using TXT record instead of SRV record.
TXT record is more used than SRV record in Japan.

I (and nobuo) personally would widely spread XMPP in the world.
But because of such as s2s, search for message destination, redundancy
and so on are depending heavily on the SRV record, it can also be said
to an obstacle of spread of XMPP for country that less supported to
SRV record like Japan.

Regards,
Akari Harada

2012/3/17 Matthew Wild <[email-masked]>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Mar 2012 15:37:21 -0600

Hi Nobuo,

Matthew and I chatted about this topic after we both sent our email
messages last week, and we realized that perhaps there are national
differences in the availability of DNS registrars that support SRV
records. Now it seems that this is true. In that case, I think that
using XEP-0156 is the second-best solution as a fallback. In fact,
using XEP-0156 is even mentioned in Section 3.2.2 of RFC 6120.
Although we prefer not to put into a TXT record the same information
that would normally be found in an SRV record, we might make an
exception here (especially because it is indeed a fallback method).

Peter

On 3/18/12 11:30 PM, Nobuo Ogashiwa wrote:
> Hello Peter,
> 
> Thank you for your helpful comments. We will consider using
> XEP-0156.
> 
> There are some another view about TXT record as the substitutes
> for SRV record, so I will consider such all opinion.
> 
> country that SRV records support status. Especially, in japan, TXT
> record is supported by most of all famous japanese DNS provider to
> support SPF, but SRV record is not supported by most of all famous
> japanese DNS provider. We have summarized SRV record support status
> in japanese famous DNS providers, please see
> http://nlab.jp/japan-dns.pdf .
> 
> Regards, Nobuo Ogashiwa
> 
>>> The RFC6120 defines that the XMPP server and client use SRV
>>> record for reliability.  However, most of standard libraries in
>>> client OS like MacOS, Windows, Linux and *BSD does not support
>>> SRV record resolution. Furthermore, many DNS hosting services
>>> do not support SRV record registration. So that there are some
>>> cases that we can not get a benefit of SRV record in the global
>>> internet environment.
>>> 
>>> So, we have proposed IQ message extensions to query and reply
>>> multiple server hostnames in our I-D. If you want to know the
>>> details of extensions, please see our I-D.
>>> 
>>> In technically, the above problem can be solved by using TXT
>>> record instead of SRV record (and also extensions we proposed
>>> in our I-D). The TXT record solutions is just like following:
>>> 
>>> We think this would be an alternative solution of the problem
>>> we mentioned in the I-D.
>>> 
>>> We think that maybe extensions we proposed in our I-D should
>>> be published as not I-D but XEP.  However, TXT record solution
>>> I mentioned in this e-mail should be discussed not XSF but IETF
>>> XMPP WG.
>> 
>> Hello Ogashiwa-san!
>> 
>> I realize that XEP-0156 says "A domain SHOULD NOT present
>> information in DNS TXT records that is available via the DNS SRV
>> records defined in RFC 6120." However, it might make sense to
>> relax that rule, or describe when it is appropriate to override
>> the SHOULD NOT.
>> 
>> Peter
>> 
>> -- Peter Saint-Andre https://stpeter.im/
>> 
>> 
>> _______________________________________________ xmpp mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/xmpp