Jordans IDN zone fails

In early May 2026 Jordan's IDN zone .xn--mgbayh7gpa (.الاردن) did not replace the DNSSec signatures it generated during April. They appear to have had expiries set for midday on the 6th of May (UTC). Since that time any consumer that validates DNS responses will have experienced a failure.

For the curious, this would result in a SERVFAIL response from your resolver.

Who is the Operator?

The Ministry of Digital Economy and Entrepreneurship (MoDEE) are responsible for the zone as well as 4 of the name servers. A RIPE nameserver provides a level of resilience to potential reachability and operational issues with the MoDEE managed hosts. It is also the only instance that is anycasted. c.cctld-servers.net.jo is deployed in AWS, which means the MoDEE managed hosts are announced from at least 2 distinct ASNs.

It is interesting to note that the serial for the zone is currently 2026040626 (I'm writing this 2026-05-21). Depending on how the serial is updated, its value may not represent the actual date it was last incremented. However since the serial appears to match the date that the signatures were generated, I'd say it is likely that no changes have occurred in the zone since early April.

What Happened?

Since this is an IDN zone, the likelihood that anyone has noticed the outage is low. This also gives us a clue as to what the issue might be. The .xn--mgbayh7gpa domain was delegated as part of the IDN Fast Track program which obliged operators to DNSSec sign the zone. However Jordan's primary domain .jo is not signed today. I suspect that this means the administrators do not have operational experience with managing a DNSSec signed zones. A key operational activity is refreshing signatures in the zone.

How can signing fail?

In order to sign a zone, a DNS host needs to access the private key for the Zone Signing Key (ZSK). As the name conveniently indicates, this is the key that is used to sign the zone. Sometimes that private key is online, meaning it is accessible to the host with no manual action. Other times that private key is offline, meaning an operator must manually connect a signing device (HSM in most cases) or transfer the private key material, before signing can occur.

Was the ZSK offline?

There is almost no sane reason to have an offline zone signing key. If your threat model suggests that leaving the ZSK on/connected to the primary DNS host is too great a risk, you probably shouldn't be in the DNS hosting game. Either your threat modeler is mad or your primary host is so vulnerable, that it shouldn't be serving a TLD zone to begin with.

Was the ZSK unreachable?

The other common ZSK accessibility issues are device failure or device reachability failure. From the point of view of the primary DNS host, these two are the same problem. This typically occurs when a Hardware Security Module (HSM) is used to sign DNS records.

HSMs have two main features, sign stuff and crash. Under normal operations HSMs receive material via network or other physical connection, they then respond to the host with the signed material. However because HSMs are general purpose security devices that are often rated for environments with far higher security requirements than a TLD, they possess a number of anti tamper and anti interception controls. All of these controls boil down to the HSM becoming unreachable and the client software deliberately crashing on the host in order to prevent a fail open scenario. Failing open is essentially a downgrade attack and is therefore not desirable in most cases.

Blame it on the tools

The final way signing can fail is as a result of poor tooling. Older DNS software implementations did not include DNSSec lifecycle management as fully integrated capabilities. Instead operators used separate tools to generate keys, sign records and update the zone. These activities were often difficult to automate and many operators instead chose to carry out at least some actions manually. It is not possible to assess what software MoDEE uses to manage the primary DNS host and to generate DNSSec records, but if it were from that past era of limited DNSSec lifecycle support, then it is easy to imagine that a manual task was missed or the procedure forgotten.

HSM are pets, not cattle

One of the security measures that HSMs can be deployed with and something which TLD operators the world over seem to have an unhealthy affection for, is the requirement for multiple people to be present with a card/pin/token for signing actions. Known as M of N signing, HSMs can require that a threshold of M people are present from a total of N who hold a card/pin/token. The important point here is that they generally need to be physically proximate to the HSM. There are HSMs with remote authorisation capability, but this isn't common and lacks the ceremony some organisations seem to crave.

I've never heard of a TLD operator requiring physical authorisation for ZSK operations and I think it is unlikely in this case. However M of N authorisation requirements can and often do apply to privileged administrative tasks on the HSM. So if a fault occurred or the device needs reconfiguring, people might need to be present.

It is typical for third party consultants who assist ccTLDs in configuring their DNS and Registry systems to include themselves amongst those who can authorise HSM operations. This is a convenience when deploying DNSSec initially, but can be problematic if there are not enough locals with authorisation.

Broader context

It's May 2026 and the biggest crisis in the middle east is not the bad DNSSec responses from an IDN ccTLD. There may well be physical risks preventing staff carrying out some operations or fixing hardware. In addition to immediate physical risks, if there are not enough local authorisers present, perhaps due to staff turn over, someone outside Jordan that is an authoriser may not be able to travel to the area. That might result in an inability to effectively administer the HSM.

What Can Be Done?

Without knowing the underlying cause, I can still recommend the most appropriate fix. Remove the DS record (31715) for .xn--mgbayh7gpa from the root zone. This can be done remotely and relatively easily. There's no increase in risk to Jordanian Internet users since .jo is unsigned already and this is most likely the TLD they would interact with day to day, given the real world limitations of IDNs. I'd also recommend removing the DNSKEY and RRSIG records, but this presumes access to the DNS host that may not be possible right now.

We Don't Know

I contacted MoDEE with a brief explanation of what I saw and my recommendation. For the time being they haven't responded, very few TLD operators do. I'll update this post if I learn more.

TLD Failures

This is the first outage I've tracked since restarting my TLD DNSSec availability project. If you have any information on this outage or would like to contact me regarding the project, the best way is: @kalfeher@infosec.exchange