Servers
The DNS records a federated server needs
Most federation failures are DNS failures. The records are short, the rules are written down, and the order matters.
Federation asks every server the same plain question: where does the machine behind this address live? The answer sits in DNS, and for an operator it comes down to two records, _xmpp-client._tcp and _xmpp-server._tcp, plus a short set of rules about what they may point at. A domain holding nothing but an ordinary address record often works anyway, because the protocol falls back gracefully. The named records exist for the cases where it cannot.
One domain, two callers
A JID reads username@domain, and the domain names the server that holds the account. Two parties resolve it: the user’s own client, to find where to log in, and a remote server, to hand over a message addressed to that user. RFC 6120 gives the reason early: streams travel over TCP, so whoever initiates a connection needs an IPv4 or IPv6 address and a port before anything can be opened. The domain part is a lookup key rather than decoration, a point developed in the anatomy of a JID.
What happens when no SRV record exists?
The specification prefers SRV but defines a fallback: an ordinary A or AAAA lookup of the origin domain, on port 5222 for client connections and 5269 for server to server traffic, the defaults registered with IANA. This is why most domains need no XMPP specific DNS at all; when the server runs on the domain itself, the address record already answers the question. One subtlety deserves remembering. If an SRV query receives an answer but the connection then fails, the initiator should not fall back to the address record; fallback applies only when the query returns nothing, which prevents a mismatch between inbound and outbound connections.
Delegation, borrowed from email
SRV records redirect an XMPP service at the DNS level, to another domain or another port, in principle the way MX records steer mail. The common case: users hold addresses like [email protected] while the server actually runs on xmpp.example.com. The service then publishes two SRV records, one for each kind of caller, and the DNS guide at prosody.im lays out the pair with every field annotated.
| Record name | Port | Who consults it |
|---|---|---|
_xmpp-client._tcp | 5222 | Clients connecting to their own server |
_xmpp-server._tcp | 5269 | Remote servers delivering to yours |
_xmpps-client._tcp | 5223 | Clients opening a direct TLS connection |
_xmpps-server._tcp | 5270 | Servers opening a direct TLS connection |
What the target field will not accept
The target must be a name that already holds an A record: not a bare IP address, and not a CNAME. The other fields are gentler. Priority and weight govern order when several targets exist, lower priority tried first and weight breaking ties, which allows load balancing or a fallback host when one machine is down. The worked example at prosody.im settles on 0 and 5 and calls them sensible defaults; most services never touch them. The TTL trades reach against patience: a higher value cuts DNS traffic and makes connections slightly faster, since answers are likelier to sit in a cache, while a lower one lets a change take effect sooner.
The RFC also binds the caller, not just the publisher. An initiator works through the IP addresses returned for one target, then moves to the next target in priority and weight order. And a single record whose target is ".", the root domain, carries a defined meaning: the service is, in the words of the underlying DNS specification, "decidedly not available at this domain".
Where does TLS enter the zone?
Two ways, and the first is a naming trap: a certificate must be valid for the virtual host name, not for the host the SRV records point at. Users at example.com whose connections terminate on xmpp.example.com still need a certificate for example.com. DNS says where, never what the bytes are worth; that split is taken up in how each hop is protected.
The second way is XEP-0368, which describes SRV records for XMPP over direct TLS: _xmpps-client._tcp on port 5223 and _xmpps-server._tcp on 5270, the extra s in the prefix marking the difference. These ports are not defaults and need explicit configuration; in Prosody the setting lives under direct_tls_ports. A related corner: _xmppconnect TXT records once advertised BOSH and WebSocket endpoints, but that use is called insecure on the prosody.im page, which points to an https lookup method instead.
Rooms are domains too
A chatroom at conference.example.com is a subdomain, and RFC 6120 treats such add-on services as full DNS citizens: a remote server resolves _xmpp-server._tcp.conference.example.com exactly as it would the parent service. An A record suffices if the component answers on the standard port 5269. Custom ports, or a conference host sharing a machine with the main server, call for an SRV record for _xmpp-server only, of the form _xmpp-server._tcp.conference.example.com pointing at xmpp.example.com.
Can the zone vouch for a certificate?
With DNSSEC, yes, through DANE. A TLSA record pins a certificate, or more commonly the public key part of it, by hash, standing beside or in place of the usual certificate authority system. The hash is derived from the private key, via openssl pkey -pubout -outform DER piped into openssl dgst -sha256, combined with the flags DANE-EE(3) SPKI(1) SHA2-256(1) and published under a name built from the port and target of the SRV records. A TLSA record under the bare domain as well speeds authentication of outgoing connections, since remote servers otherwise follow the SRV chain to find the pins. In Prosody 13.0, once use_dane = true is set, prosodyctl check certs prints the data fields.
Two habits cover most of this ground. Before moving a service to new hardware, drop the TTL, wait out the old value, then raise it again once the new target is in place. After any change, run prosodyctl check dns, the sanity tool that ships with Prosody, and let it read the zone back before a remote server does.
prosody.im is the site of the Prosody IM server and its documentation. Its DNS page, written to apply to any XMPP service rather than Prosody alone, covers A records, both SRV families, direct TLS entries, subdomains and DANE, along with the checking tool prosodyctl check dns.