DNSSEC reaches .pk, but 1,230 signed domains await DS

DNSSEC now connects Pakistan’s .pk country-code top-level domain to the internet’s root of trust. DNS Security Extensions are checks that let a resolver verify that DNS answers are authentic and have not been altered. However, a scan reported on CircleID by an EUNOMATIX engineer found that only one of 158,561 sampled .pk domains validated all the way from the root to the individual domain.

The change happened during October 2026. On 5 October, .pk had no DNSSEC deployment: the root zone, the highest level of the Domain Name System, contained no DS record for .pk; the .pk zone published no DNSKEY; and it provided no signed evidence when a requested name did not exist. DNSViz continued to show the domain as insecure through September. Root-zone serial 2026100600, published on 6 October, and serial 2026100901, archived at 15:00 UTC on 9 October, still contained no .pk DS record.

The earliest signatures found in the .pk zone began at 08:34 UTC on 8 October, indicating that the zone was signed about a day before the root was updated. By 22:20 UTC on 9 October, DNSViz classified .pk as secure, while IANA’s .pk record lists an update on that date. The DS record now present in the root has key tag 34973 and matches the key-signing DNSKEY supplied by the .pk nameservers. Sixteen years after the root itself was signed, the authenticated chain therefore reaches .pk.

The zone uses algorithm 13, ECDSA P-256 with SHA-256, to create and verify its signatures. For names that do not exist, it uses NSEC3, a method for providing signed proof that a DNS record is absent. Its NSEC3 configuration has no extra iterations and an empty salt, in line with RFC 9276.

The scan took place on 11 October, two days after the DS record appeared in the root, and used validating resolvers, which reject DNSSEC answers that cannot be authenticated correctly. For every domain, it requested the DS record held in .pk and the DNSKEY held in the domain’s own zone. A name counted as fully signed only when every link from the root through .pk to that domain validated.

Only newspak.pk met that test. It had both a DS record in .pk and a matching signed domain zone. None of the approximately 1,360 names examined under gov.pk and the provincial government suffixes validated end to end.

A further 1,230 domains, or 0.78 percent of the sample, published DNSKEY records and signed their own zones but had no DS record in the parent .pk zone. When a resolver asks about those domains, .pk returns signed NSEC3 evidence that no DS exists. The resolver consequently treats the domain as unsigned, even though the domain operator has created signatures. Examples included accenture.pk, nexlinx.net.pk, 7dayz.com.pk and agajk.gov.pk.

Those 1,230 domains were distributed across the main .pk suffixes: 759 directly below .pk, 317 below com.pk, 58 below edu.pk, 40 below org.pk, 28 below gov.pk and 17 below net.pk. Of the remaining names, 117,572, or 74 percent, were unsigned; 25,875 no longer existed; and 13,883 could not be classified because their nameservers timed out or could not be reached.

A DS record is a fingerprint of a domain’s DNSSEC key. The domain owner or DNS provider creates the cryptographic material and signs the zone, but the parent registry must publish the DS record. Without that parent-side entry, there is no authenticated connection to the root and validating resolvers have no basis for trusting the domain’s signatures.

For most top-level domains, registrants send DS information through a registrar. Deployment can stall when an owner does not know this separate step is required, when a registrar does not accept DS submissions, or when the available process is manual and prone to errors. The record also needs attention when a provider changes its DNSSEC material or a domain moves to another provider. A stale or incorrect DS can make the domain appear bogus to validating resolvers, potentially making it unreachable through them.

The result is more extreme than the pattern recorded in a 2017 USENIX Security study of .com, .net and .org, where about 30 percent of signed domains lacked a parent DS and the gap was concentrated among a small number of operators. In .pk, the administrative route is comparatively concentrated because com.pk, org.pk, edu.pk and gov.pk are not separately delegated zones. They remain within .pk, so one organisation would publish every DS record covered by the scan.

The analysis identifies the 1,230 already signed domains as the immediate opportunity. Their DNSKEY records are public, allowing the registry or registrars to contact owners and arrange publication of matching DS records. It argues that completing this work could increase the number of validating .pk domains by more than a thousand times within weeks.

Longer-term options include accepting DS information from registrars through EPP, the Extensible Provisioning Protocol used to manage domain records, following RFC 5910. Support for CDS and CDNSKEY under RFC 7344 and RFC 8078 could automate more of the process by letting a signed domain publish the DS information it wants its parent to use. RFC 10026 provides recent best-practice guidance for that approach.

The analysis also recommends a DNSSEC Practice Statement explaining how the registry creates and protects its signing material, how frequently it changes that material, and how emergencies will be handled. RFC 6841 defines this type of statement, while RFC 6781 provides operational guidance. The .se statement is cited as a model, and the rollover failures affecting .de in 2026 and .nz in 2023 illustrate the operational importance of documented procedures.

A separate infrastructure measurement on 5 October found that none of the four public .pk nameservers was located in Pakistan. Two used CIRA’s anycast service, which serves the same address from multiple locations, while one server was in Singapore and another in the Netherlands. Round-trip times measured from Lahore and Islamabad ranged from 130 to 263 milliseconds. The two servers without anycast also lacked IPv6 addresses. The analysis recommends adding a nameserver inside Pakistan and IPv6 support to every server.

The findings remain a snapshot rather than a complete census. Some of the 1,230 domains may have gained DS records after 11 October. The .pk zone does not permit zone transfers and is not publicly released, so the sample cannot be confirmed as a full list. Almost 9 percent of sampled names were also left unclassified because their nameservers were unavailable; some could be signed.

Website owners using .pk should therefore verify both halves of DNSSEC: signatures at their DNS provider and a matching DS entry at the registrar or registry.