A records

A records are the standard record type, and are used in XMPP when there are no XMPP SRV records for a domain. This allows simple setups to work with no extra DNS configuration.

SRV records

SRV records essentially allow transparent DNS-level redirects of XMPP services to another domain or port. A simple example is when you want users to have addresses like [email protected], but your XMPP server is really installed on xmpp.example.com. In principle they work the same way as MX records do for email.

SRV records are not XMPP-specific, but are defined for a number of protocols. XMPP actually has 2 different types of SRV records, those for clients to use (client-to-server, or 'c2s'), and those for other XMPP servers to use when they look up your domain (server-to-server, or 's2s').

Following the previous example of a server 'example.com' wanting to delegate its XMPP services to the server at 'xmpp.example.com', here are some example records:

The bold text indicates parts of the record that you can change. The underlined bold text indicates parts of the record that you must replace with your domain (in this case example.com), and your target domain (in this case xmpp.example.com), respectively.

The target domain MUST be an existing A record of the target server, it cannot be an IP address, and cannot be a CNAME record.

The 3600 in this example is the TTL (time-to-live), it tells other servers how long they should cache your record for - a higher number will reduce DNS traffic, and result in slightly faster connections (since DNS info will be more likely to be cached, and won't need to be re-fetched). A lower TTL is more useful if you are going to be changing your record, since you have to wait for the TTL until all caches have expired your old record.

The 0 and 5 are the record's priority and weight. These values are specific to SRV records, and allow you to have multiple targets with different priorities (e.g. for load balancing or fallback in case of a down server) - lower priority targets are tried first. The weight is used to bias resolvers towards certain targets in case of a priority tie. Most services will not need to change these values, and 0 and 5 are sensible defaults.

Next is the port the service is running on. Clients will typically connect to 5222, and servers will connect to 5269, and these are Prosody's defaults. You are free to change them if you wish (for example to run multiple XMPP servers on a single machine), if you do this then be sure to inform Prosody of the port numbers in the configuration file.

Note about certificates: When requesting/generating certificates for your domain, you need your certificates to be valid for the virtual host name, not the domain that your SRV records point to. For more information see 'Which domain?' in our certificate documentation.

TXT records

Subdomains

If you provide services on subdomains, such as MUC chatrooms and other components, that you wish to be accessible from other servers, these will require DNS entries too. If you are using the standard server-to-server port (5269), an A record is enough. If you are using custom ports, or need to run Prosody on another hostname (e.g. xmpp.example.com) then you will need to specify SRV records, for _xmpp-server only. For example:

An explanation of each of these fields is given in the SRV records section above.

DANE

If your zone is secured with DNSSEC you can use this to securely pin your certificates that way instead of, or as a complement to the regular Certificate Authority system, using DANE. This works by adding hashes of the certificates, or more commonly the public key part of the certificate in a TLSA record in DNS.

To find out the hash of the public key the openssl tool can be used to derive it from the private key:

openssl pkey -pubout -outform DER -in /etc/prosody/certs/example.com.key | sha256sum - | cut -d' ' -f1

Combine this with the flags 3 1 1 (DANE-EE, public key, SHA256) and add this to your zone using names constructed from the port and target fields from your SRV records.