DNS SRV/TXT lookup for Openfire?


how can you provide a DNS SRV lookup for Openfire server?

E.g. XMPP domain is:


Client makes a DNS SRV lookup for this domain and the result should be 2 DNS records, like: (external IP)

168.x.x.x (internal IP)

The problem is our clients are sometimes connected via internal Intranet and sometimes over external Internet.

Client then first tries to connect to the external IP and if this doesn’t work, the client is probably in the “intranet” network and tries the internal IP.

If that doesn’t work either, the client should make a DNS TXT lookup and should try to connect with BOSH.


Related links:



The question is, how to install such lookup tables on the server, so that the client receives a result.

I am not sure if I got your question right.

DNS is not provided by Openfire, but by your DNS server. You have to configure the DNS zone for domain.com with the SRV RRs for XMPP. Some goes for XEP-156 2 style “DNS lookup method”. How exactly this is configured depends on your used DNS server software. See also http://wiki.xmpp.org/web/SRV_Records

Thanks. The answer for me is, that I have to ask my system admin :wink:

The problem is:

People are connected in company’s intranet to IP address 199.xxx.xxx.xxx to the Openfire server (via cable).

Then they disconnect the cable, take their notebook and are now connected via external network (WLAN) over internet (no longer in the intranet).

Openfire is reachable from internet and intranet. So the reconnection logic needs to find/try the correct IP address.

I thought this maybe could be resolved with 2 DNS SRV entries.

I would first disable the Java DNS cache to make sure that the clients do lookup the new IP address with “-Dnetworkaddress.cache.ttl=1” in Spark.vmoptions This should work, but one may still use tcpdump/wireshark to make sure that DNS requests are sent.

If you are still using IPv4 It makes sense to set also: “-Djava.net.preferIPv4Stack=true”


Update: And you may want to use two DNS servers - one for the internal and one for the external lookups.

Returning two IP addresses with one active and the other not reachable may work for some clients, it is nothing I can recommend.**

You should never multi-home a service. Never! There is zero advantage in doing so and it only causes problems (like the one you described).

Not sure, what you with multi-home. I didn’t setup the network structure + Openfire, but our system admins told us, that when you are in the company’s intranet you can reach it ONLY via an internal IP address and NOT the external one. I don’t know why this is, but this is how it is configured.

If you are in the internet, e.g. at home, you obviously cannot reach it via the internal IP, but only via an external one.

So, you basically have 2 IP addresses pointing to the same server, but depending on where you are (intranet vs internet), then one will work and the other not.

So I thought somehow one DNS server which returns both IP addresses and is reachable from external and internal network may solve this problem, so that collegues don’t need to switch between server settings.

But maybe I am misunderstanding things. I am not very familiar with networking and DNS resolution.

Not sure, what you with multi-home.

When a service is avaiable under multiple IPs in different subnets.

our system admins told us, that when you are in the company’s intranet you can reach it ONLY via an internal IP address and NOT the external one

That’s madness. You will only run into problems with this setup, as it makes things unnecessarily complex. Even if your company policy is to restrict access to internet IPs, services like your companies XMPP server belong into a DMZ, which is reachable by your internal IPs and externally.

I could tell a dozens examples why you will run into problems with that setup. Good luck with that. DNS is your smallest problem, as that’s where SRV records are really useful.

Use an internal and an external DNS server, every one should return the proper IP address.

I see no problem having multiple IP addresses and NATing the external one.

Anyhow I agree that it is a rather uncommon setup that the external IP can not be reached from the internal network.

I guess, it’s because of the general proxy stuff within a company. E.g. we can reach the external IP address from intranet, but only on port 80 over the company’s HTTP proxy server.

That means we can’t connect from intranet to external IP on port 5222 and therefore have to use the internal IP.