remote chatroom joining

Clive Holloway clive.holloway at gmail.com
Sat Nov 3 02:07:22 UTC 2007


So, what I'm thinking is that because conference.HOSTNAME is a service
rather than an actual domain, that the DNS lookup is failing, based on
this part of the debug logs:

2007/11/02 23:07:35 Queuing stanza (DJabberd::Presence=ARRAY(0x97030f0)) for
2007/11/02 23:07:35   .. starting to connect to
2007/11/02 23:07:35 Starting connection to domain 'conference.HOSTNAME'
2007/11/02 23:07:35 pkt = Net::DNS::Packet=HASH(0x970b074)
2007/11/02 23:07:35 sock = IO::Socket::INET=GLOB(0x9736e4c)
2007/11/02 23:07:35   .. pushing queue item.
2007/11/02 23:07:35 DNS socket IO::Socket::INET=GLOB(0x9736e4c) became
readable for 'srv'
2007/11/02 23:07:35 DNS socket IO::Socket::INET=GLOB(0x9736e4c) for
'srv' had nothing, falling back to 'a' lookup
2007/11/02 23:07:35 DNS socket IO::Socket::INET=GLOB(0x96f94f8) became
readable for 'a'
2007/11/02 23:07:35 Resolver callback for 'conference.HOSTNAME': []
2007/11/02 23:07:35 Starting connection
2007/11/02 23:07:35 Failed to connect queue

SO, SRV lookup fails, then 'a' lookup fails. Now, I'm scanning XMPP
core, and I all I can find about DNS for server to server is:

"Inter-domain connections MUST NOT proceed until the DNS hostnames
asserted by the servers have been resolved. Such resolutions MUST
first attempt to resolve the hostname using an [SRV] (Gulbrandsen, A.,
Vixie, P., and L. Esibov, "A DNS RR for specifying the location of
services (DNS SRV)," February 2000.) Service of "xmpp-server" and
Proto of "tcp", resulting in resource records such as
"_xmpp-server._tcp.example.com." (the use of the string "xmpp-server"
for the service identifier is consistent with the IANA registration;
note well that the "xmpp-server" service identifier supersedes the
earlier use of a "jabber" service identifier, since the earlier usage
did not conform to [SRV] (Gulbrandsen, A., Vixie, P., and L. Esibov,
"A DNS RR for specifying the location of services (DNS SRV)," February
2000.); implementations desiring to be backward compatible should
continue to look for or answer to the "jabber" service identifier as
well). If the SRV lookup fails, the fallback is a normal IPv4/IPv6
address record resolution to determine the IP address, using the
"xmpp-server" port 5269, registered with the IANA." ( section 14.4)

But I don't see a comment anywhere on how to deal with a service on a
remote host.

ie, if "domainname.com" resolves through DNS, and "service" is running
on "domainname.com", "service.domainname.com" doesn't need to resolve
in DNS because it's actually "service" @ "domainname.com", but that's
not how the DNS lookup is approaching it.

For now, I'm hacking a solution for my needs, but I was wondering what
the correct approach would be to this? I can't see anything in XMPP
core or in the dialback XEP docs (220) giving hints on this.

Am I looking in the wrong place? Or is it just that there's no place
where this is actually documented?

cLive ;-)


More information about the Djabberd mailing list