IncidentSeverityCriticalStatusResolvedDNS Hosting

Catalog zone was sporadically not replicated to secondary nameservers

Jun 14, 2026, 10:00 PM – Jun 15, 2026, 03:00 PM

A separate, new error has now occurred affecting the central distribution zone, through which newly created zones are automatically distributed to the downstream nameservers. This error only occurred sporadically and was therefore not reliably reproducible in testing, which is why it was not caught during quality assurance.

The cause was a combination of two factors:

First, the transfer permission over the newer internet protocol. The permission to retrieve the zones was configured to a fixed set of the main server addresses in the older protocol. Since the distribution zone lists those addresses as the main server, I assumed the downstream servers would request the retrieval the same way. In reality they can also use the address of the newer protocol, which I had not anticipated. Over that path they lacked permission. Whenever a server performed the retrieval over the newer protocol, synchronization failed. Hence the sporadic behavior.

Second, the version identifier of the distribution zone. Under certain conditions it was artificially raised by a date-based calculation, pushing it above the automatically managed value. The downstream server then treated the lower, correct identifier as older and refused to accept it. Replication froze.

As a result, in these cases newly created or deleted zones were not reliably propagated to all authoritative nameservers. Existing, fully synchronized zones were not affected.

Resolution:

I identified and corrected the root cause. The retrieval permission now includes the main server addresses in both internet protocols, so the downstream servers may pull the zones over either path. The distribution zone now runs exclusively on its automatically managed, continuously increasing identifier. Replication has been restored and re-synchronized once. In addition, I added a safeguard that spaces out zone creation and deletion in time so that each change receives a unique identifier, even for actions performed in rapid succession.

Newly created zones are once again reliably transferred to all downstream nameservers and are available on every authoritative nameserver. No action is required on your part.

If you set up a nameserver delegation with your registrar during the disruption, please verify that it was applied correctly and repeat the process if necessary.

I apologize for the inconvenience.

Following the successful resolution of the previous disruption (2026-06-14), the synchronization of newly created zones worked reliably. That earlier correction was effective and fully resolved the original problem. A separate, new error has now occurred affecting the central distribution zone, through which newly created zones are automatically distributed to the downstream nameservers. This error only occurred sporadically and was therefore not reliably reproducible in testing, which is why it was not caught during quality assurance. The cause was a combination of two factors: First, the transfer permission over the newer internet protocol. The permission to retrieve the zones was configured to a fixed set of the main server addresses in the older protocol. Since the distribution zone lists those addresses as the main server, I assumed the downstream servers would request the retrieval the same way. In reality they can also use the address of the newer protocol, which I had not anticipated. Over that path they lacked permission. Whenever a server performed the retrieval over the newer protocol, synchronization failed. Hence the sporadic behavior. Second, the version identifier of the distribution zone. Under certain conditions it was artificially raised by a date-based calculation, pushing it above the automatically managed value. The downstream server then treated the lower, correct identifier as older and refused to accept it. Replication froze. As a result, in these cases newly created or deleted zones were not reliably propagated to all authoritative nameservers. Existing, fully synchronized zones were not affected. Resolution: I identified and corrected the root cause. The retrieval permission now includes the main server addresses in both internet protocols, so the downstream servers may pull the zones over either path. The distribution zone now runs exclusively on its automatically managed, continuously increasing identifier. Replication has been restored and re-synchronized once. In addition, I added a safeguard that spaces out zone creation and deletion in time so that each change receives a unique identifier, even for actions performed in rapid succession. Newly created zones are once again reliably transferred to all downstream nameservers and are available on every authoritative nameserver. No action is required on your part. If you set up a nameserver delegation with your registrar during the disruption, please verify that it was applied correctly and repeat the process if necessary. I apologize for the inconvenience.