On 5 October 2026, the .pk zone had no DNSSEC at all. There was no DS record for it in the root, no DNSKEY in the zone, and no signed proof of non-existence when a name was missing. Six days later, the chain of trust from the root down to .pk validated. Pakistan’s country-code TLD had joined the signed part of the namespace.

Signing the TLD is only the first step. A scan of 158,561 .pk domains on 11 October, two days after the DS record appeared in the root, found exactly one domain that validates end to end. Another 1,230 domains have signed their own zones and are waiting for a DS record that the .pk zone does not yet hold.

What Changed, and When

The transition can be dated fairly precisely from public sources. DNSViz showed .pk as insecure throughout September. The root zone published on 6 October (serial 2026100600) had no DS for .pk, and neither did serial 2026100901, archived at 15:00 UTC on 9 October. The earliest signatures in the .pk zone carry an inception time of 08:34 UTC on 8 October, so the zone was signed about a day before the root was updated. By 22:20 UTC on 9 October, DNSViz reported .pk as secure, and the IANA record for .pk shows a last update on the same day. The DS now in the root (key tag 34973) matches the key-signing key served by the .pk nameservers.

The zone uses algorithm 13 (ECDSA P-256 with SHA-256). Denial of existence uses NSEC3 with no additional iterations and an empty salt, as RFC 9276 recommends.

One Domain out of 158,561

The scan ran on 11 October through validating resolvers. For each name, it queried the DS record, held in the .pk zone, and the DNSKEY, held in the domain’s own zone. A domain was counted as fully signed only if the whole chain, root to .pk to domain, validated.

The result was one domain: newspak.pk, which has a DS record in .pk and a matching signed zone. No other name in the scan validated. That includes the government namespace. None of the roughly 1,360 names under gov.pk and the provincial government suffixes is fully signed.

The more telling number is the 1,230 domains (0.78 percent) that publish DNSKEY records and sign their zones but have no DS in the parent. For these domains, the .pk zone returns a signed NSEC3 proof that no DS exists, so a validating resolver treats them as unsigned. Their owners have done the technical work, and none of it counts. They include accenture.pk, nexlinx.net.pk, 7dayz.com.pk, and agajk.gov.pk, spread across every major suffix: 759 directly under .pk, 317 under com.pk, 58 under edu.pk, 40 under org.pk, 28 under gov.pk, and 17 under net.pk.

The rest of the scan breaks down as follows: 117,572 names (74 percent) are unsigned, 25,875 no longer exist, and 13,883 could not be classified because their nameservers were unreachable or timed out.

This pattern is familiar. The 2017 USENIX Security study of .com, .net, and .org found that roughly 30 percent of signed domains had no DS in the parent, and that the gap was concentrated at a few operators. The .pk case is more extreme, but it is also simpler to fix. Names such as com.pk, org.pk, edu.pk, and gov.pk are not delegated zones. They are part of the .pk zone itself. Every DS record for every name in this scan would be published by one organization.

Why the DS Step Matters

Signing a zone and getting its DS into the parent are separate tasks, done by different parties. The domain owner, or their DNS provider, generates keys and signs the zone. The DS record, a hash of the domain’s key, has to reach the registry and be published in the parent zone. Until it does, nothing links the domain’s signatures to the root, and resolvers have no reason to trust them.

In most TLDs, this second step goes through a registrar, and it is where DNSSEC deployments most often stall. A registrant may not know the step exists. A registrar may not offer a way to submit DS records, or may offer one that is manual and easy to get wrong. When a DNS provider rolls its keys or a domain moves to a new provider, the DS has to be updated again, and if it is not, the domain goes from insecure to bogus, which is worse.

The 1,230 domains in this scan show that demand already exists in .pk. The next question is how a DS record gets from a registrant into the zone, and how quickly.

What the Registry Can Do Next

Publishing the DS records that are already waiting. The 1,230 signed domains are an obvious starting point. Their DNSKEY records are public, so the registry, or their registrars, can contact the owners and publish the corresponding DS records. Doing this would multiply the number of validating .pk domains more than a thousandfold within weeks.

Automating DS provisioning. Manual DS submission does not scale and breaks during key rollovers. Accepting DS data from registrars over EPP (RFC 5910) is the baseline. Supporting CDS and CDNSKEY records (RFC 7344 and RFC 8078) goes further: a signed zone publishes the DS it wants, and the registry picks it up automatically. The IETF’s recent RFC 10026 sets out best practice for exactly this.

Publishing a DNSSEC Practice Statement. A DPS explains how the registry generates and protects its keys, how often it rolls them, and what it will do in an emergency (RFC 6841, with operational guidance in RFC 6781). It lets resolver operators and registrants know what to expect. The .se DPS is a good model. The rollover failures at .de in 2026 and .nz in 2023 show why this is more than a formality.

There is also one change unrelated to DNSSEC that is worth making. Measurements on 5 October found that none of the four public .pk nameservers is located in Pakistan. Two run on CIRA’s anycast service, one is in Singapore, and one is in the Netherlands. Round-trip times from Lahore and Islamabad ranged from 130 to 263 milliseconds, and the two non-anycast servers have no IPv6 address. A nameserver inside the country, and IPv6 on every server, would improve resolution for the users who query .pk most.

Limitations

These figures are a snapshot. The scan ran two days after the DS appeared in the root. Some of the 1,230 signed domains may have submitted DS records since, and a later scan is the only way to know how quickly the gap is closing.

The scan also is not a complete list of .pk. The .pk zone does not allow zone transfers and, like most ccTLD zones, is not published, so no outside list can be confirmed complete. The 158,561 names are a large sample, not a census.

Finally, almost 9 percent of the names could not be classified because their nameservers were unreachable or timed out. They were kept separate from the signed and unsigned counts rather than counted as failures. Some of them may be signed.

Wrapping Up

Signing .pk was the step only PKNIC could take, and it came sixteen years after the root was signed. The chain from the root now reaches the TLD. For 158,560 of the 158,561 names in the scan, the chain still stops there.

The gap is not technical. The 1,230 domain owners who have already signed their zones show that the work is being done below the registry. What remains is the path between them and the parent zone. If that path becomes simple and automatic, DNSSEC in .pk will grow on its own. If it does not, .pk will have a signed TLD protecting almost nothing beneath it.