This text describes how network names are used in XMPP. The intended audience is people looking to set up an XMPP-based service.
An XMPP domain consists of 1 or more XMPP servers. If there are more servers in the same domain, then that's referred to as "clustering".
When multiple XMPP domains communicate with each-other, at least one server of each domain connect to each-other. This is typically referred to as "federation" or "server-to-server comunication."
The difference between an XMPP domain and an XMPP server is illustrated by looking at the associated users. Each XMPP domain has its own user base. XMPP servers that are part of the same domain will all operate on behalf of that same userbase.
An XMPP address (a 'Jabber Identifier' or JID) looks like this: localpart@domainpart/resourcepart. Typically, the domainpart matches the XMPP domain name, while the localpart matches a username.
Each XMPP server has its own fully qualified domain name (like all internet-facing servers typically have). For example: server1.example.org, server2.example.org.
Frequently, when an XMPP domain consists of just one server (which is a very common scenario), then the XMPP domain name and the FQDN of the server are the same. This simplifies things, but is by no means a requirement.
When software wants to connect to an XMPP domain name, it needs to figure out what server (IP address) it needs to connect to. The procedure that is taken is the same for both clients wanting to connect to an XMPP domain (eg: users logging in), as well as other XMPP servers (belonging to different XMPP domains) connecting to the XMPP domain:
first, a DNS SRV lookup is performed against the XMPP domain name (and service type), to return eligible hosts. An XMPP client would perform this query:
dig SRV _xmpp-client._tcp.example.org
Or replace 'dig' with your favorite DNS query tool.
in this query, SRV refers to the DNS record type being queried, xmpp-client refers to the service being queried ("xmpp for clients"), and example.org is the XMPP domain for which hosts are to be returned.
The query performed by XMPP servers is very similar:
dig SRV _xmpp-server._tcp.example.org
They're using a slightly different service identifier ("xmpp for servers") but the processing is otherwise the same.
Results to the query look like this:
_xmpp-client._tcp.example.org. 86400 IN SRV 5 0 5222 server1.example.org.
There's a lot in there - please refer to the DNS SRV specification for the exact details. The most relevant bits are the two last items.
- The service is provided by a host named
server1.example.orgon port5222
Next, the software performs a DNS A (or AAAA if you want IPv6) record lookup to obtain the IP address for the host, which is exactly the same lookup like all other internet traffic. After that the software knows where (IP + port) to connect to.
If you want to make use of TLS, then your server needs to have a certificate that ideally covers both the XMPP domain name (example.org) as well as the fully qualified domain name of the server (server.example.org), but also a couple of XMPP-based addresses that are typically used in server-to-server communication. It is by far easiest to have a wildcard certificate, that covers both example.org as well as *.example.org, assuming that the XMPP domain name is example.org and FQDN of the server(s) all are covered by the wildcard.