When two servers stop talking

Two federated servers that stop exchanging messages produce one symptom and four causes. The symptom is silence: messages sent, nothing received, no error that reaches the user. The causes live at different depths, DNS, certificates, the server-to-server handshake, and the remote operator’s own decisions, and they have to be checked in that order, because each layer assumes the one beneath it is sound. Digging at the wrong layer wastes an evening and learns nothing.

The drainage trade works the same problem and writes the order down. The diagnostic pages of a drainage firm in Chiclana insist on the same sequence in Spanish, distinguish what is yours from what is public, camera the pipe before digging, and only then decide between a spot repair and a replacement. Translated to federation: establish whose side is failing before touching anything, observe the path rather than the symptom, and do not rebuild what a record lookup could have explained.

Whose side is silent?

The first question, and the one a symptom never answers. A message from your server to theirs fails somewhere in the middle, and the failure can be yours, theirs, or the path’s. The discriminating test is cheap: does the same domain fail for other remote servers, and does your server fail for other remote domains? A server that cannot talk to anyone has a local problem; a server that cannot talk to one specific peer may have a remote problem, a listing problem, or a certificate the other side refuses.

The observability tools make this concrete. The public test suite at the IM Observatory grades both directions of a domain’s setup, client and server, DNS and certificate, and produces the plumbing-camera view: which hop, which record, which handshake parameter. Running it on your own domain before blaming a peer is the equivalent of checking your own drains before calling the water company.

The local log is the other half of the evidence, and it is the half most often skipped. A server-to-server failure that the remote side never saw is recorded only on your own machine, and the entry is usually one line among thousands, a dialback timeout, a TLS alert, a connection reset, timestamped and unglamorous. The discipline is to read it as a plumber reads a flow test: not looking for drama, looking for the point where the expected sequence stopped. A connection that opens and closes cleanly tells a different story than one that never opens at all, and the log knows which it was.

Which layer fails first?

DNS, most often, because it is the layer everything else trusts. An expired domain, a missing or mis-pointed SRV record, a hostname that resolves to the wrong machine: each produces silence rather than an error, because the connecting side simply never finds anyone to talk to. The records essay lists what should be published, and the name-and-DNS essay covers the layer above it, the registration itself. If the SRV answers and the host answers, the next layer up is the certificate.

Certificate failures are the noisiest silent failure in the stack. An expired certificate, a name mismatch between the certificate and the domainpart, or a chain the remote side cannot verify each end the handshake before a single stanza travels, and the encryption essay explains why the refusal is deliberate: the remote server is doing its job. Logs on both ends name this layer when an operator reads them; the difficulty is that half the operators never look.

And when the pipes are clear?

Then the blockage is a decision. The remote operator may have added your domain to a refusal list, for a documented incident or for a category judgement of the kind examined in the blocklist essay. Your own server may be refusing the peer for a reason long forgotten. These are the cases the camera cannot see, because the answer is a policy rather than a fault, and the fix is a conversation between operators rather than a record change. A short, dated message to the remote abuse contact resolves more of these than any amount of re-testing.

The order, kept

Symptom, scope, layers, policy. Whose silence is it, then DNS, then certificate, then handshake, then the human layer last, in that order and no other. The drainage technician’s rule is the honest summary: know what is yours before you dig, look before you open the ground, and let the observed path, not the loudest symptom, decide where the work happens.

What the order buys, beyond the fix itself, is a record. Each layer that is checked and cleared narrows the next failure, and a log of what was verified is worth more than the memory of having fixed it, because the same silence six months later starts from the notes instead of from zero. A federation failure read this way usually ends in a five-minute fix. Read the other way, it ends in a reinstall that changed nothing, which is how servers acquire their reputation for being haunted.