DNSSEC erreicht .pk, doch 1.230 signierte Domains warten auf DS

DNSSEC verbindet Pakistans country-code top-level domain .pk nun mit der root of trust des Internets. DNS Security Extensions sind Prüfmechanismen, mit denen ein resolver feststellen kann, ob DNS-Antworten authentisch sind und nicht verändert wurden. Ein auf CircleID veröffentlichter Scan eines EUNOMATIX-Ingenieurs ergab jedoch, dass nur eine von 158.561 untersuchten .pk-Domains vollständig von der root bis zur jeweiligen Domain validiert werden konnte.

Die Änderung erfolgte im Oktober 2026. Am 5. Oktober war DNSSEC bei .pk noch nicht eingerichtet: Die root zone, die höchste Ebene des Domain Name System, enthielt keinen DS record für .pk; die .pk zone veröffentlichte keinen DNSKEY; und sie lieferte keinen signierten Nachweis, wenn ein angefragter Name nicht existierte. DNSViz zeigte die Domain bis einschließlich September weiterhin als „insecure“ an. Die am 6. Oktober veröffentlichte root-zone serial 2026100600 und die am 9. Oktober um 15:00 UTC archivierte serial 2026100901 enthielten ebenfalls noch keinen .pk DS record.

Die frühesten in der .pk zone gefundenen Signaturen begannen am 8. Oktober um 08:34 UTC. Dies deutet darauf hin, dass die zone etwa einen Tag vor der Aktualisierung der root signiert wurde. Am 9. Oktober um 22:20 UTC stufte DNSViz .pk als „secure“ ein, während der .pk record von IANA eine Aktualisierung an diesem Datum aufführt. Der nun in der root vorhandene DS record hat den key tag 34973 und stimmt mit dem key-signing DNSKEY überein, den die .pk nameservers bereitstellen. Sechzehn Jahre nach der Signierung der root selbst reicht die authentifizierte Kette damit bis zu .pk.

Die zone verwendet algorithm 13, ECDSA P-256 mit SHA-256, um ihre Signaturen zu erstellen und zu überprüfen. Für Namen, die nicht existieren, verwendet sie NSEC3, eine Methode zum Bereitstellen eines signierten Nachweises dafür, dass ein DNS record fehlt. Ihre NSEC3-Konfiguration verwendet keine zusätzlichen Iterationen und einen leeren salt, entsprechend RFC 9276.

Der Scan fand am 11. Oktober statt, zwei Tage nachdem der DS record in der root erschienen war, und verwendete validating resolvers, die DNSSEC-Antworten ablehnen, wenn diese nicht korrekt authentifiziert werden können. Für jede Domain wurden der in .pk hinterlegte DS record und der in der eigenen zone der Domain hinterlegte DNSKEY abgefragt. Ein Name galt nur dann als vollständig signiert, wenn jedes Glied von der root über .pk bis zu dieser Domain erfolgreich validiert wurde.

Nur newspak.pk bestand diesen Test. Die Domain verfügte sowohl über einen DS record in .pk als auch über eine dazu passende signierte Domain-zone. Keine der rund 1.360 untersuchten Domains unter gov.pk und den Endungen der Provinzregierungen wurde durchgehend validiert.

Weitere 1.230 Domains beziehungsweise 0,78 Prozent der Stichprobe veröffentlichten DNSKEY records und signierten ihre eigenen zones, verfügten jedoch über keinen DS record in der übergeordneten .pk zone. Wenn ein resolver diese Domains abfragt, liefert .pk einen signierten NSEC3-Nachweis dafür, dass kein DS vorhanden ist. Der resolver behandelt die Domain daher als unsigniert, obwohl der Domainbetreiber Signaturen erstellt hat. Zu den Beispielen gehörten accenture.pk, nexlinx.net.pk, 7dayz.com.pk und agajk.gov.pk.

Diese 1.230 Domains verteilten sich auf die wichtigsten .pk-Endungen: 759 direkt unter .pk, 317 unter com.pk, 58 unter edu.pk, 40 unter org.pk, 28 unter gov.pk und 17 unter net.pk. Von den übrigen Namen waren 117.572 beziehungsweise 74 Prozent unsigniert; 25.875 existierten nicht mehr; und 13.883 konnten nicht eingeordnet werden, weil bei ihren nameservers eine Zeitüberschreitung auftrat oder diese nicht erreichbar waren.

Ein DS record ist ein Fingerabdruck des DNSSEC key einer Domain. Der Domaininhaber oder DNS-Anbieter erstellt das kryptografische Material und signiert die zone, doch die übergeordnete Registry muss den DS record veröffentlichen. Ohne diesen Eintrag auf übergeordneter Ebene besteht keine authentifizierte Verbindung zur root, und validating resolvers haben keine Grundlage, den Signaturen der Domain zu vertrauen.

Bei den meisten top-level domains übermitteln Domaininhaber die DS-Informationen über einen Registrar. Die Einführung kann ins Stocken geraten, wenn ein Inhaber nicht weiß, dass dieser separate Schritt erforderlich ist, wenn ein Registrar keine DS-Übermittlungen akzeptiert oder wenn das verfügbare Verfahren manuell und fehleranfällig ist. Der record muss außerdem beachtet werden, wenn ein Anbieter sein DNSSEC-Material ändert oder eine Domain zu einem anderen Anbieter umzieht. Ein veralteter oder falscher DS kann dazu führen, dass die Domain für validating resolvers als „bogus“ erscheint und über diese möglicherweise nicht mehr erreichbar ist.

Das Ergebnis ist extremer als das Muster, das eine USENIX-Security-Studie aus dem Jahr 2017 für .com, .net und .org ermittelte. Dort fehlte bei etwa 30 Prozent der signierten Domains ein DS bei der übergeordneten Ebene, und die Lücke konzentrierte sich auf eine kleine Zahl von Betreibern. Bei .pk ist der Verwaltungsweg vergleichsweise stark gebündelt, da com.pk, org.pk, edu.pk und gov.pk keine separat delegierten zones sind. Sie verbleiben innerhalb von .pk, sodass eine einzige Organisation sämtliche vom Scan erfassten DS records veröffentlichen würde.

Die Analyse bezeichnet die 1.230 bereits signierten Domains als unmittelbare Chance. Ihre DNSKEY records sind öffentlich, sodass die Registry oder Registrar-Unternehmen die Inhaber kontaktieren und die Veröffentlichung passender DS records veranlassen können. Der Analyse zufolge könnte der Abschluss dieser Arbeiten die Zahl der validierenden .pk-Domains innerhalb weniger Wochen um mehr als das Tausendfache erhöhen.

Zu den längerfristigen Möglichkeiten gehört, DS-Informationen von Registrar-Unternehmen über EPP anzunehmen, das Extensible Provisioning Protocol zur Verwaltung von Domain records, entsprechend RFC 5910. Die Unterstützung von CDS und CDNSKEY gemäß RFC 7344 und RFC 8078 könnte weitere Teile des Prozesses automatisieren, indem eine signierte Domain die DS-Informationen veröffentlicht, die ihre übergeordnete Ebene verwenden soll. RFC 10026 enthält aktuelle Best-Practice-Empfehlungen für diesen Ansatz.

Die Analyse empfiehlt außerdem ein DNSSEC Practice Statement, das erläutert, wie die Registry ihr Signaturmaterial erstellt und schützt, wie häufig sie dieses Material wechselt und wie mit Notfällen umgegangen wird. RFC 6841 definiert diese Art von Erklärung, während RFC 6781 betriebliche Leitlinien bereitstellt. Die Erklärung von .se wird als Vorbild genannt, und die rollover-Fehlschläge bei .de im Jahr 2026 und bei .nz im Jahr 2023 verdeutlichen die betriebliche Bedeutung dokumentierter Verfahren.

Eine separate Infrastrukturmessung vom 5. Oktober ergab, dass sich keiner der vier öffentlichen .pk nameservers in Pakistan befand. Zwei nutzten den anycast-Dienst von CIRA, der dieselbe Netzwerkadresse von mehreren Standorten aus bereitstellt, während sich ein Server in Singapur und ein weiterer in den Niederlanden befand. Die von Lahore und Islamabad aus gemessenen round-trip times lagen zwischen 130 und 263 Millisekunden. Den beiden Servern ohne anycast fehlten außerdem IPv6-Adressen. Die Analyse empfiehlt, einen nameserver innerhalb Pakistans einzurichten und jeden Server mit IPv6-Unterstützung auszustatten.

Die Ergebnisse sind eine Momentaufnahme und keine vollständige Erhebung. Einige der 1.230 Domains könnten nach dem 11. Oktober DS records erhalten haben. Die .pk zone erlaubt keine zone transfers und wird nicht öffentlich bereitgestellt, sodass nicht bestätigt werden kann, dass die Stichprobe eine vollständige Liste darstellt. Fast 9 Prozent der untersuchten Namen blieben zudem ohne Einordnung, weil ihre nameservers nicht verfügbar waren; einige davon könnten signiert sein.

Websitebetreiber, die .pk verwenden, sollten daher beide Seiten von DNSSEC überprüfen: die Signaturen bei ihrem DNS-Anbieter und einen dazu passenden DS-Eintrag beim Registrar oder bei der Registry.