DNS resolving problems of the uber.space zone Wednesday 24th September 2025 14:56:00

We are currently experiencing DNS resolving problems of the uber.space zone. There's no problem with our DNS servers: They happily serve the uber.space zone. The problem seems to lie within the .space registry that no longer seems to serve a delegation to our nameservers. The registration of the uber.space domain is fine though, the domain is still listed with our domain registrar and Whois records show zero updates and a correct delegation. However the [abef].nic.space nameservers responsible for delegating the zone to our nameservers don't provide records any more.

We have receive similar reports from other .space domain owners, using registrations through other registrars, so we have good reason to believe that this is indeed a bigger problem of the .space registry in general, not specifically with our uber.space domain. We will keep you updated.

We have received an Incident Report from the CentralNic Registry, responsible for the .space DNS zone. We're quoting the following information from that document.

Impact Assessment:

• Initial degradation of service at 10:15 UTC, followed by partial failure of .SPACE zone update, resulting in a number of .SPACE domain names failing to resolve.

• No Impact on Shared Registry Service, new registrations or registry updates.

• Duration of incident: Approximately 3 hours and 24 minutes from initial degradation to resolution.

• Impact of incident: Intermittent depending upon resolver. (First indication of failure logged at 11:15 UTC – Resolved at 13:39 UTC

Root Cause Analysis:

• Immediate Cause:

− Failure triggered by an operating system failure on the primary node responsible for the domain zone.

• Detailed Root Cause:

− The operating system on the primary node failed partway through writing the zone file, generating only part of the zone data before halting.

− As a result, approximately half the DNS records within the zone were not published to DNS, leading to some domains being inaccessible on some resolvers.

− While some resolvers and systems temporarily served cached entries, the TTL for this zone resulted in customers experiencing some service disruption once caches expired.

• Contributing Factors:

− Due to excessive DNS traffic the initial problem presented as a DDOS attack, rather than an internal issue.

Posted 3 weeks ago by :username

It seems like the .space TLD registry has fixed something on their side - the delegation of the uber.space zone to our nameservers is back:

$ dig +noall +authority @a.nic.space. uber.space. ns
uber.space.             3600    IN      NS      ns1.jonaspasche.com.
uber.space.             3600    IN      NS      ns2.jonaspasche.com.
uber.space.             3600    IN      NS      ns3.jonaspasche.com.

$ dig +noall +authority @e.nic.space. uber.space. ns
uber.space.             3600    IN      NS      ns1.jonaspasche.com.
uber.space.             3600    IN      NS      ns2.jonaspasche.com.
uber.space.             3600    IN      NS      ns3.jonaspasche.com.

The b and f .space TLD nameservers still give timeouts, but that might be the aftermath of excessive requests due to expired caches. We can indeed confirm that uber.space subdomains start becoming available again.

We're still waiting for some official confirmation/post-mortem of the .space TLD registry about what happened here.

Posted 1 month ago by :username

Seems indeed to be a problem with the .space zone in general, others are reporting similar problems:

  • https://x.com/atticoos/status/1970823253091631132
  • https://x.com/nikro_md/status/1970827722219020408
  • https://x.com/marcelritter_/status/1970837156173119735
  • https://news.ycombinator.com/item?id=45359627
Posted 1 month ago by :username