DNSSEC arrin te .pk, por 1,230 domain-e të nënshkruara presin DS record

DNSSEC tani lidh country-code top-level domain .pk të Pakistanit me root of trust të internetit. DNS Security Extensions janë kontrolle që i mundësojnë një resolver të verifikojë se përgjigjet DNS janë autentike dhe nuk janë ndryshuar. Megjithatë, një skanim i raportuar në CircleID nga një inxhinier i EUNOMATIX zbuloi se vetëm një nga 158,561 domain-et .pk të marra si mostër u validua gjatë gjithë rrugës nga root deri te domain-i individual.

Ndryshimi ndodhi gjatë tetorit 2026. Më 5 tetor, .pk nuk kishte implementim DNSSEC: root zone, niveli më i lartë i Domain Name System, nuk përmbante DS record për .pk; .pk zone nuk publikonte DNSKEY; dhe nuk jepte dëshmi të nënshkruara kur një emër i kërkuar nuk ekzistonte. DNSViz vazhdoi ta paraqiste domain-in si insecure gjatë gjithë shtatorit. Seriali 2026100600 i root zone, i publikuar më 6 tetor, dhe seriali 2026100901, i arkivuar në orën 15:00 UTC më 9 tetor, ende nuk përmbanin DS record për .pk.

Nënshkrimet më të hershme të gjetura në .pk zone fillonin në orën 08:34 UTC më 8 tetor, duke treguar se zone ishte nënshkruar rreth një ditë para përditësimit të root. Deri në orën 22:20 UTC më 9 tetor, DNSViz e klasifikoi .pk si secure, ndërsa record i IANA për .pk shënon një përditësim në atë datë. DS record që tani gjendet në root ka key tag 34973 dhe përputhet me key-signing DNSKEY të dhënë nga nameservers të .pk. Gjashtëmbëdhjetë vjet pasi u nënshkrua vetë root, zinxhiri i autentikuar arrin kështu deri te .pk.

Zone përdor algoritmin 13, ECDSA P-256 me SHA-256, për të krijuar dhe verifikuar nënshkrimet e saj. Për emrat që nuk ekzistojnë, ajo përdor NSEC3, një metodë për të dhënë provë të nënshkruar se një DNS record mungon. Konfigurimi i saj NSEC3 nuk ka përsëritje shtesë dhe ka salt bosh, në përputhje me RFC 9276.

Skanimi u krye më 11 tetor, dy ditë pasi DS record u shfaq në root, dhe përdori validating resolvers, të cilët refuzojnë përgjigjet DNSSEC që nuk mund të autentikohen siç duhet. Për çdo domain, ai kërkoi DS record të mbajtur në .pk dhe DNSKEY të mbajtur në zone të vetë domain-it. Një emër u llogarit si plotësisht i nënshkruar vetëm kur u validua çdo hallkë nga root, përmes .pk, deri te ai domain.

Vetëm newspak.pk e kaloi këtë test. Ai kishte si DS record në .pk, ashtu edhe një domain zone të nënshkruar që përputhej me të. Asnjë nga afërsisht 1,360 emrat e shqyrtuar nën gov.pk dhe suffix-et e qeverive provinciale nuk u validua nga fillimi deri në fund.

Edhe 1,230 domain-e të tjera, ose 0.78 për qind e mostrës, publikonin DNSKEY records dhe kishin nënshkruar zone-et e tyre, por nuk kishin DS record në parent .pk zone. Kur një resolver pyet për këto domain-e, .pk kthen dëshmi NSEC3 të nënshkruar se nuk ekziston DS. Si pasojë, resolver e trajton domain-in si unsigned, edhe pse operatori i domain-it ka krijuar nënshkrime. Shembujt përfshinin accenture.pk, nexlinx.net.pk, 7dayz.com.pk dhe agajk.gov.pk.

Këto 1,230 domain-e shpërndaheshin në suffix-et kryesore të .pk: 759 drejtpërdrejt nën .pk, 317 nën com.pk, 58 nën edu.pk, 40 nën org.pk, 28 nën gov.pk dhe 17 nën net.pk. Nga emrat e mbetur, 117,572, ose 74 për qind, ishin unsigned; 25,875 nuk ekzistonin më; dhe 13,883 nuk mund të klasifikoheshin sepse nameservers e tyre pësuan timeout ose nuk mund të arriheshin.

Një DS record është fingerprint i key DNSSEC të një domain-i. Pronari i domain-it ose ofruesi DNS krijon materialin kriptografik dhe nënshkruan zone, por parent registry duhet të publikojë DS record. Pa atë hyrje në anën e parent, nuk ka lidhje të autentikuar me root dhe validating resolvers nuk kanë bazë për t’u besuar nënshkrimeve të domain-it.

Për shumicën e top-level domains, zotëruesit dërgojnë informacionin DS përmes një registrar. Implementimi mund të ngecë kur një pronar nuk e di se ky hap i veçantë është i nevojshëm, kur një registrar nuk pranon dërgimin e DS ose kur procesi i disponueshëm është manual dhe i prirur ndaj gabimeve. Record kërkon gjithashtu vëmendje kur një ofrues ndryshon materialin e vet DNSSEC ose kur një domain kalon te një ofrues tjetër. Një DS i vjetruar ose i pasaktë mund ta bëjë domain-in të shfaqet si bogus për validating resolvers, duke e bërë potencialisht të paarritshëm përmes tyre.

Rezultati është më ekstrem se modeli i dokumentuar në një studim të USENIX Security të vitit 2017 për .com, .net dhe .org, ku rreth 30 për qind e domain-eve të nënshkruara nuk kishin parent DS dhe hendeku përqendrohej te një numër i vogël operatorësh. Në .pk, rruga administrative është relativisht e përqendruar, sepse com.pk, org.pk, edu.pk dhe gov.pk nuk janë zone të deleguara veçmas. Ato mbeten brenda .pk, ndaj një organizatë e vetme do të publikonte çdo DS record të përfshirë në skanim.

Analiza i identifikon 1,230 domain-et tashmë të nënshkruara si mundësinë e menjëhershme. DNSKEY records të tyre janë publike, duke i lejuar registry ose registrar të kontaktojnë pronarët dhe të organizojnë publikimin e DS records përkatëse. Ajo argumenton se përfundimi i kësaj pune mund ta rrisë më shumë se një mijë herë numrin e domain-eve .pk që validohen, brenda pak javësh.

Opsionet afatgjata përfshijnë pranimin e informacionit DS nga registrar përmes EPP, Extensible Provisioning Protocol që përdoret për menaxhimin e domain records, duke ndjekur RFC 5910. Mbështetja për CDS dhe CDNSKEY sipas RFC 7344 dhe RFC 8078 mund të automatizojë një pjesë më të madhe të procesit, duke i lejuar një domain-i të nënshkruar të publikojë informacionin DS që dëshiron të përdorë parent i tij. RFC 10026 jep udhëzime të fundit për praktikat më të mira për këtë qasje.

Analiza rekomandon gjithashtu një DNSSEC Practice Statement që shpjegon se si registry krijon dhe mbron materialin e vet të nënshkrimit, sa shpesh e ndryshon atë material dhe si do të trajtohen emergjencat. RFC 6841 përcakton këtë lloj deklarate, ndërsa RFC 6781 jep udhëzime operacionale. Deklarata e .se përmendet si model, ndërsa dështimet e rollover që prekën .de në vitin 2026 dhe .nz në vitin 2023 ilustrojnë rëndësinë operacionale të procedurave të dokumentuara.

Një matje e veçantë e infrastrukturës më 5 tetor zbuloi se asnjë nga katër nameservers publikë të .pk nuk ndodhej në Pakistan. Dy përdornin shërbimin anycast të CIRA, i cili ofron të njëjtën adresë nga shumë vendndodhje, ndërsa një server ishte në Singapor dhe një tjetër në Holandë. Kohët e vajtje-ardhjes të matura nga Lahore dhe Islamabad varionin nga 130 deri në 263 milisekonda. Dy serverët pa anycast nuk kishin gjithashtu adresa IPv6. Analiza rekomandon shtimin e një nameserver brenda Pakistanit dhe të mbështetjes IPv6 në çdo server.

Gjetjet mbeten një snapshot dhe jo një regjistrim i plotë. Disa nga 1,230 domain-et mund të kenë marrë DS records pas 11 tetorit. .pk zone nuk lejon zone transfers dhe nuk publikohet, kështu që mostra nuk mund të konfirmohet si listë e plotë. Pothuajse 9 për qind e emrave të marrë si mostër mbetën gjithashtu të paklasifikuar, sepse nameservers e tyre nuk ishin të disponueshëm; disa prej tyre mund të jenë të nënshkruar.

Prandaj, pronarët e faqeve që përdorin .pk duhet të verifikojnë të dyja pjesët e DNSSEC: nënshkrimet te ofruesi i tyre DNS dhe një hyrje DS përkatëse te registrar ose registry.