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

[Matthias Wimmer]

Hi Bruce!

The s2s component in jabberd 1.4.4 will merely ignore the "." entry. It 
will try to finde a A record for "." and as this does not resolve skip 
to the next resolved entry, if there are entries with lower priority for 
the same service.
jabberd 1.4.4 will NOT try to resolve "example.com" after it found a 
_xmpp-server._tcp.example.com record. - Doesn't matter if one of the 
result records contained a "." or not. If there has been a 
_xmpp-server._tcp.example.com record, there are no further tries. If 
there is no _xmpp-server._tcp.example.com record, it will try 
_jabber._tcp.example.com - and if there is also no such record, it will 
fall back to example.com.
Other service names are not tried by default, but can be configured - 
with the exception, that you cannot distinguish between _pres for 
<presence/> and _im for <message/>.

Therefore I'd say jabberd 1.4.4 works like it should in most of the 
cases, even if there is a "SRV 0 0 0 ." record - which will result in 
jabberd 1.4.4 stopping further DNS resolution.

Just in the case, that there is something like the following in DNS, 
jabberd 1.4.4 would be wrong (but I think this example is of academic 
nature, and can hardly imagine, that this could be really used in DNS):

_xmpp-server._tcp.example.com 3600 SRV 5 0 0 .
_xmpp-server._tcp.example.com 3600 SRV 10 0 5269 s2s.example.com

In that case jabberd 1.4.4 would contact s2s.example.com on port 5269 - 
while it shouldn't.


Tot kijk
    Matthias


Bruce Campbell schrieb:
>
> 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        192.168.1.1
>     jabber.example.com.        IN A        192.168.2.2
>     imhandler.example.com.        IN A        192.168.3.3
>     presence.example.com.        IN A        192.168.4.4
>
> 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 )
>  or
>     '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 ).
>  or
>     'fallback to looking up "_jabber.example.com."'
>     ( the "I haven't read XMPP-IM" response ;) )
>  or
>     '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 ;)
>