Servers
A server starts with a name: domain and DNS first
Every guide to running a server begins with the software. The dependency nobody lists comes earlier: a name that resolves.
A federated XMPP server exists before its software does. Before ejabberd or Prosody is installed, the node needs three things, in this order: a registered domain name, a set of DNS records under the operator’s control, and a host that answers on the right ports. Almost every early failure of a new server is a failure of that foundation rather than of the daemon, and the foundation is the part the installation guides spend the least time on.
The order is not arbitrary. The domainpart of every JID the server will ever issue is the domain itself, so the name is fixed before the first account exists. Certificates are issued against the name, so the records must resolve before encryption can be tested. And federation, the reason for running a server at all, begins the moment another server tries to look the name up. A name that does not resolve is not a small problem: it is the whole problem, expressed early.
The practical layer underneath is mundane: a registrar, a zone file, a renewal date, a host account. For the vocabulary of that layer, registrars and transfer locks, record types, renewal and grace periods, the reference kept by domain names, DNS and hosting is a tidy documentary source. None of it is specific to XMPP, and none of it needs to be: a federated server consumes the same public naming infrastructure as an ordinary website, plus a handful of records a website never asks for.
Where does the name come from?
From a registrar, for an annual fee, under rules set by the registry of the chosen extension. The choice carries more weight than it looks. The domain becomes part of every address the server issues: [email protected] is a brand as much as an identifier, and changing it later means migrating every account, every certificate and every contact list that has ever stored one of those addresses. Operators who treat the name as a temporary decision discover that nothing about it is temporary.
Two properties matter more than the string itself. The first is control of the zone: the registrar must allow the operator to publish the records federation needs, including SRV, which some budget panels still hide behind an advanced screen. The second is continuity: a name lost at renewal can be re-registered by someone else, and a federated address that changes hands quietly is a worse outcome than a server that is simply off. Auto-renewal, a working contact address and a registrar account the operator actually opens are boring answers to a question that only looks administrative.
What has to resolve before the installer runs?
At minimum, the hostname of the machine must resolve to its addresses, A for IPv4 and AAAA for IPv6 where the host has it. Everything else can come afterwards, but in practice the SRV records are published at the same sitting, because they are what turn a resolvable host into a reachable service. A client looking for example.org asks for _xmpp-client._tcp.example.org first; a server looking for the same domain asks for _xmpp-server._tcp.example.org. The records point at a hostname and a port, 5222 and 5269 in the standard case, and the hostname they point at must itself resolve.
The detail that matters, and that the essay on the records themselves covers record by record, is that SRV is a delegation: the domain says where the service lives, not where the domain lives. That is how a small VPS in one data centre can serve a domain registered somewhere else entirely, and it is also why a missing SRV record produces such a confusing failure, half the world can reach the name and the other half cannot find the service.
| Layer | Record or fact | Looked up by |
|---|---|---|
| name | registered domain, unexpired | everyone, always |
| host | A and AAAA for the machine | clients and servers |
| service | _xmpp-client._tcp and _xmpp-server._tcp SRV | clients and servers |
| trust | a certificate covering the domain | whoever connects |
Certificates follow the name, not the server
Because a certificate is issued for a name, the certificate question is really a DNS question asked twice. First, the name must resolve for the authority doing the checking, which means the records above have to be live and correct before any certificate request succeeds. Second, the name on the certificate has to match the domainpart of the JIDs being served, which is why serving example.org from a certificate for chat.example.org produces warnings that look like a software bug and are actually a naming mismatch. The two encrypted hops each make their own use of that name, and both fail the same way when it is wrong.
The core specification describes this lookup order formally: RFC 6120 defines how a client finds its server, and the same logic is mirrored for server-to-server traffic. Reading it once is worth the hour: the DNS section is short, and it explains exactly which record is asked for, in which order, and what a fallback looks like.
Ownership is a maintenance fact
A domain is not bought, it is rented, and the rent is easy to forget because nothing on the machine complains about it. Renewal lives in the registrar’s panel and in the operator’s calendar, not in the server logs. The failure mode is silent: the zone keeps resolving until the day it does not, and by then the grace period is already running. A name that lapses can be picked up by a stranger within weeks, and every JID ever issued under it is now an address on somebody else’s property.
Transfer locks, registry holds and expiry reminders exist for this reason, and the sensible posture is to treat the registrar account as part of the server: a mailbox that is read, a payment method that is current, and a note of which panel controls which name. None of this is glamorous. All of it is load-bearing, in exactly the way the daemon’s uptime is load-bearing, and a federated address is only as permanent as the weakest renewal in the chain.
The order, again
Name, records, host, certificate, software. Each step assumes the one before it is true, which is why the sensible debugging order is the same list read backwards: when federation fails, check the certificate, then the records, then the name, before touching the daemon’s configuration at all. The essay on silent federation failures walks that order in detail, because the pipes metaphor is the honest one: most of the time, the blockage is in the plumbing, not the pump.