[Standards] Legacy SRV records with service _jabber._tcp.hostname

[Matthias Wimmer]

Hi!

I collected the promised statistics about the legacy SRV records not 
using _xmpp-server but _jabber as the service name. I tried to find out 
the adotion of the new/correct service name in two situations: 
publication in the DNS, and usage when resolving other XMPP servers.

My statistics where collected within the last week of operation on 
amessage and covers 1484 domain names of Jabber servers.


1. Usage of _jabber._tcp in DNS

Test case: I used the above collected 1484 domain names and resolved 
them using the DNS to find out, if they have a _xmpp-server SRV record 
and if they have a _jabber SRV record. The most interesting case for me 
were servers having a _jabber record, but no _xmpp-server record. If 
found 8 such servers (0,5 % of the tested servers). For one of these 
servers the SRV record was completely wrong and unusable, the other 
seven servers could be connected without resolving this record, as it 
pointed to the same host and port as doing a standard A/AAAA resolving.

It seems, that we are ready to drop support for resolving 
_jabber._tcp.hostname in our server implementations. None of the tested 
1484 servers needed this DNS record to be available.

(50 hosts had a _xmpp-server SRV record but no _jabber SRV record / 350 
hosts had both types of SRV records / 1076 hosts had no SRV record at all)


2. Adoption of _xmpp-server._tcp when resolving other hosts

Test case: I configured the DNS records of most domains of amessage in a 
way, that servers using _xmpp-server SRV records connected to ports 5260 
to 5267, while servers resolving amessage on _jabber SRV records 
connected to port 5268. Therefore by checking the incoming TCP port, I 
could find out which DNS SRV record has been used by the connecting 
Jabber server.

I found two groups of servers connecting to port 5268 (used _jabber._tcp 
SRV records to connect to amessage):
- the first group connected always to port 5268
- the second group connected to both port 5268 and to ports 5260 to 5267

It seems that the first group are servers, not doing _xmpp-server 
resolving, but finding amessage by resolving the _jabber SRV record. 
These are the servers, that would get into problems with servers relying 
on _xmpp-server SRV records, and that are not available on the default 
port 5269 on the IP address, that gets resolved on the hostname when 
doing an A/AAAA lookup.

The second group are servers, that seem to lookup both types of SRV 
records and that are then using both. I would consider this behaviour 
wrong. Resolving _jabber if it is done should be only the fallback if 
there where no _xmpp-server records. But the servers contained in this 
second group are not causing problems if the _jabber._tcp records are 
removed, as they continue to correctly connect to the location pointed 
by the _xmpp-server record.

In the first group still consist of 131 servers in my sample (nearly 10 
%). I would expect, that this are installations of old server 
implementations, that had been released before we switched from _jabber 
to _xmpp-server. Namely this should be most of the time jabberd prior to 
version 1.4.3 (since 1.4.3 jabberd's default configuration supports 
_xmpp-server resolving) or wpjabber (AFAIK all released version of 
wpjabber do not resolve _xmpp-server when using the default 
configuration). Both implementations can be upgraded to do the correct 
resolving using a simple configuration change.

I will try to get the administrators of these servers aware of the 
problem by sending a Jabber message to the admin address of these 
servers, explaining them how they can change their configuration.


Matthias


List of servers, that seem to to _jabber but not _xmpp-server SRV 
resolving (servers with faulty configuration):

0xbadc0ffe.org
acan.com.mx
aim.jabber.wiretrip.org
andbit.net
aurora.gen.nz
betizfest.kicks-ass.org
bluelinux.co.uk
bravegnuworld.com
burg.cx
cataclysm.cx
cco.cyt.cu
centova.net
corwin.fi.muni.cz
crooks.net
damazio.org
dannz.net.nz
datasink.webmonster.de
dev.ragtime.ru
dmzs.com
dohcrew.com
dvzmsfax.fh-muenster.de
egospodarka.pl
eiman.tv
eim.eds.com
fbo.no-ip.org
filip.eu.org
fkserveur.homelinux.com
gg.jabber.gda.pl
gg.toster.org
goodwin.ee
gristle.org
hol.gr
hosteurope.de
icq.jabber.earth.li
ified.ca
imise.uni-leipzig.de
im.latte.be
im.meetingone.com
im.rmilk.com
ioctl.codeblau.de
isnomore.net
jabber.accelance.net
jabber.bawue.net
jabber.binaryredneck.net
jabber.bleenet.eu.org
jabber.caldana.org
jabber.chatwana.net
jabber.com.mx
jabber.cv.ua
jabber.de.cw.net
jabber.devnullteam.org
jabber.dongames.net
jabber.earth.li
jabber.elektron.com.pl
jabber.ermarian.net
jabber.freiheit.com
jabber.gda.pl
jabber.gondor.com
jabber.gpul.org
jabber.grm.desoft.cu
jabber.icm.edu.pl
jabber.isst.fhg.de
jabber.jraf.org
jabber.kawo1.rwth-aachen.de
jabber.kern.nl
jabber.klaki.net
jabber.klaudyny.net
jabber.lugs.ch
jabbermac.com
jabber.marconi.cx
jabber.ngnet.it
jabber.nine.ch
jabber.opennms.org
jabber.palomine.net
jabber.paris-sansfil.info
jab.ber.pl
jabber.profane.eu.org
jabber.rocks.cc
jabber.sforce.org
jabber.shadrinsk-city.ru
jabber.sh.cvut.cz
jabber.shd.dk
jabber.snow-crash.org
jabber.te.ua
jabber.uni-paderborn.de
jabber.ventoso.org
jabber.vialibre.org.ar
jabber.wiretrip.org
jabber.woof.lu
jabber.zerties.org
jab.undernet.cz
jalix.net
jesseross.com
jis.mit.edu
kadarnet.com
kefro.st
kgraff.net
lavon.org
legalized.de
linux-quebec.org
lostfocusnet.com
lugro.org.ar
miernik.name
msn.jabber.earth.li
msn.jabber.wiretrip.org
ndump.com
niemueller.de
online.vlz.ru
openhotspots.net
outerpla.net
penza-gsm.ru
phraktured.net
plys.net
raffael.ch
rasasa.net
sabifoo.com
scirus.benran.ru
semanticgap.com
shih.parnanen.net
silc.ael.be
sunix.org
tddsworld.com
timaltman.com
tm.uka.de
usagainstthem.org
verse.org
vzljot.ru
wiscchat.wisc.edu
yahoo.jabber.wiretrip.org
yahoo.sweeney.ath.cx
zgzjabber.ath.cx