[Standards] [Fwd: [jdev] How to handle SRV lookups when the root domain is referenced]

Peter Saint-Andre stpeter at stpeter.im
Thu Sep 18 15:41:33 UTC 2008

I found this old email in my rfc3920bis folder...

My sense is that we'd keep trying until we exhausted all avenues of 
connection, and I think that's the philosophy behind RFC 3920/3921.


-------- Original Message --------
Date: Sun, 30 Apr 2006 23:16:57 +1000 (EST)
From: Bruce Campbell <list-jdev at vicious.dropbear.id.au>
To: jdev at jabber.org
Subject: [jdev] How to handle SRV lookups when the root domain is referenced

In XMPP-IM (rfc3921), the appropriate SRV name to look up for server to
server connections is '_xmpp-server._tcp.HOST', followed by
'_im._xmpp.HOST' or '_pres._xmpp.HOST', followed by '_jabber._tcp.HOST'
(if one wishes compatibility with old records) finally followed by A/AAAA
lookups for 'HOST'.

In both XMPP-CORE and XMPP-IM, the wording used is 'if the (previous)
address record resolution fails, (continue with the next resolution)'.
In DNS terms, 'fails' usually means 'if there was no positive answer'.

Both of these documents also refer to DNS-SRV (rfc2781), which states that
if the target of the sole (successful) SRV answer is the root domain
('.'), then 'abort'.

Since there appear to be two sides of the fence in what to do after
encountering the DNS-SRV 'abort', I'm interested in knowing what have
Jabber server implementors done with the following corner case, assuming
that they want to deliver a <presence/> and initial <message/> to a JID
@example.com :

	_xmpp-server._tcp.example.com.	IN SRV 0 0 5269 .
	_im._xmpp.example.com.		IN SRC 0 0 5269 imhandler.example.com.
	_pres._xmpp.example.com.	IN SRC 0 0 5269 presence.example.com.
	_jabber._tcp.example.com.	IN SRV 0 0 5269 jabber.example.com.
	example.com.			IN A
	jabber.example.com.		IN A
	imhandler.example.com.		IN A
	presence.example.com.		IN A

Since the lookup of _xmpp-server._tcp.example.com is successful, but
returns just one record with a target of '.', have implementors treated
this record as:

	'stop attempting to look up an address for "example.com"',
	( my personal intrepretation )
	'fallback to looking up "_im._xmpp.example.com." or
	 "_pres._xmpp.example.com." as appropriate',
	( after all, there wasn't anything with an address resulting
	  from the first lookup ).
	'fallback to looking up "_jabber.example.com."'
	( the "I haven't read XMPP-IM" response ;) )
	'stop attempting to look up SRV records and fallback to looking
	 up A/AAAA for "example.com"'

Various giggle searches on this topic haven't really answered the
question, and I'm not really keen on examining source code ;)

   Bruce Campbell.

 From - Fri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080918/faf154c3/attachment.bin>

More information about the Standards mailing list