Rrotullimi i çelësit rrënjë DNSSEC caktohet për 11 tetor 2026

DNSSEC është sistemi i nënshkrimeve dixhitale që i lejon një kompjuteri të kontrollojë nëse një përgjigje që ka marrë nga Sistemi i Emrave të Domenit është e vërtetë, dhe një nga çelësat e tij më të rëndësishëm është gati të zëvendësohet. Ky ndryshim ishte një nga katër subjektet e diskutuara në APNIC 62, konferenca e Qendrës së Informacionit të Rrjetit të Azisë-Paqësorit, e mbajtur në Mumbai, Indi, nga 4 deri më 10 shtator 2026, ku operatorë rrjeti, studiues dhe ekspertë të infrastrukturës së internetit u mblodhën për të krahasuar përvojën operative dhe sfidat e vazhdueshme. Shkrimi i APNIC për Sesionin Teknik 1, Operacionet e Internetit, u publikua nga George Michaelson më 21 shtator 2026.

Marcin Siodelski, një inxhinier i lartë softueri në Konsorciumin e Sistemeve të Internetit (ISC), prezantoi Stork, një mjet të ri menaxhimi. Softueri DHCP dhe BIND i ISC kanë qenë në qendër të ofrimit të shërbimeve të internetit për dekada, dhe ndërsa organizata është ndoshta më e njohur sot për operimin e shërbimit global të DNS-së F-root, zhvillimi i softuerit mbetet një pjesë thelbësore e misionit të saj. BIND 9 vazhdon të fuqizojë shërbimet DNS në mbarë botën si një server autoritar (makina që mban të dhënat zyrtare të një domeni) dhe si një zgjidhës rekurziv (makina që kërkon përgjigje në emër të një përdoruesi). Kea DHCP zëvendëson serverin e vjetër ISC DHCP, i cili ka arritur fundin e jetës. Për shkak se mjediset DHCP, sistemet që shpërndajnë automatikisht adresat e rrjetit, mund të jenë komplekse, Stork paraqitet si një hap i rëndësishëm përpara: një platformë menaxhimi grafike që integrohet me BIND 9 dhe PowerDNS, dhe gjithashtu me Prometheus dhe Grafana për monitorim, raportim, panele dhe një ndërfaqe menaxhimi në web.

DHCP mbetet një pjesë themelore e ofrimit të shërbimeve të rrjetit. Ai menaxhon grupe adresash IP, alokon nënrrjeta dhe mban caktime statike adresash dhe prefiksesh për makina specifike të identifikuara nga adresat MAC (identifikuesi i harduerit i ndërtuar në një kartë rrjeti) ose identifikues klientësh. Përmes Kea, operatorët mund të menaxhojnë konfigurime të disponueshmërisë së lartë, sisteme failover, gjurmim qiraje dhe inspektim logësh, dhe Marcin demonstroi integrime Grafana, ndërfaqe menaxhimi nënrrjetash dhe mjete konfigurimi. Menaxhimi i DNS-së është një shtesë relativisht e re në Stork, dhe integrimi i tij me BIND 9 i lejon operatorët të menaxhojnë, monitorojnë dhe raportojnë mjedise komplekse DNS përmes një ndërfaqeje të vetme, duke dhënë dukshmëri në vendosjet e mëdha të serverëve dhe duke ndihmuar në lidhjen e ekipeve operative me infrastrukturën DNS. Aftësitë aktuale fokusohen në monitorim, pamje konfigurimi, shfletim zonash dhe monitorim transferimi zonash, duke përfshirë zbulimin e mospërputhjeve të numrave serialë midis serverëve, të cilat sinjalizojnë se dy kopje të të njëjtës zonë janë larguar nga njëra-tjetra. Integrimi me PowerDNS mbetet eksperimental dhe synon të ofrojë një përvojë të unifikuar menaxhimi në vendosje të përziera. Janë planifikuar veçori të mëtejshme, duke përfshirë zbulimin dhe heqjen e të dhënave DNS të vjetruara në mjedise DNS dinamike, e cila përputhet ngushtë me menaxhimin e grupeve DHCP, plus klonimin dhe validimin e zonave, redaktimin e konfigurimit BIND 9, mbështetjen e zonave katalog DNS dhe monitorimin e përmirësuar të logëve BIND 9. Këto veçori pritet të lëshohen gjatë 2026 dhe 2027.

Champika Wijayatunga, Drejtor i Angazhimit Teknik i ICANN për Azinë-Paqësorin, shpjegoi rrotullimin e ardhshëm të Çelësit Rrënjë të Nënshkrimit të Çelësave (KSK) të DNSSEC, i planifikuar për 11 tetor 2026. Ai përshkruan zinxhirin e besimit DNSSEC, i cili mbështetet në Pikën e Besimit të zonës rrënjë. Një pikë besimi qëndron në krye të hierarkisë dhe nuk mund të validohet kundër një çelësi tjetër: sistemet duhet të konfigurohen për ta trajtuar atë si një pikënisje të besuar, një aksiomë. Çelësi që rrotullohet është gjysma publike e një çifti çelësash publikë dhe privatë; çelësi privat qëndron jashtë linje brenda moduleve të sigurisë harduerike të menaxhuara nga ICANN në objekte të sigurta në brigjet lindore dhe perëndimore të Shteteve të Bashkuara. Çelësat privatë prodhojnë nënshkrimet kriptografike mbi të dhënat DNS, ndërsa çelësat publikë të publikuar u mundësojnë zgjidhësve të verifikojnë vërtetësinë, integritetin dhe plotësinë e atyre të dhënave. Rrotullimet periodike konsiderohen praktikë e mirë operative: ato reduktojnë rreziqet afatgjata të sigurisë dhe lejojnë futjen e algoritmeve dhe gjatësive të çelësave më të forta ndërsa teknologjia evoluon, gjë që ka rëndësi për kërcënimet në zhvillim si kompjuteri kuantik që mund të shkurtojë jetëgjatësinë efektive të çifteve të çelësave RSA. ICANN kryen menaxhimin e çelësave përmes ceremonive publike të çelësave në të dy objektet, me pjesëmarrjen e Përfaqësuesve të Komunitetit të Besuar, dhe ceremonitë transmetohen drejtpërdrejt. Në rrethana normale materiali i çelësave do të rifreskohej çdo tre deri në katër vjet, megjithëse ky rrotullim u vonua. Operatorët që kryejnë validimin DNSSEC duhet të sigurojnë që sistemet e tyre zgjidhëse të mbajnë pikat e besimit të përditësuara: shumë sisteme përditësohen automatikisht përmes RFC 5011, por disa vendosje kërkojnë ndërhyrje manuale, dhe Wijayatunga theksoi rëndësinë e verifikimit se si sillen zgjidhësit gjatë dhe pas rrotullimit. Pikat e besimit të përditësuara janë të disponueshme nga IANA dhe mund të validohen në mënyrë të pavarur nga përditësimet RFC 5011.

Geoff Huston, Shkencëtari Kryesor i APNIC, shqyrtoi sfidat e vazhdueshme të menaxhimit të certifikatave X.509, sistemi që mbështet mekanizmat e autentikimit dhe privatësisë të përdorura nga HTTPS dhe TLS. Një certifikatë është dëshmia e një pale të tretë për identitetin: autoriteti certifikues lëshues është një organizatë private që krijon kredenciale kriptografike bazuar në informacionin e dhënë nga aplikantët, dhe nuk është domosdoshmërisht autoriteti që ka lëshuar një emër kompanie, një emër domeni ose ndonjë formë tjetër identiteti. Duke përdorur një faqe interneti bankare të paautorizuar si shembull, Huston bëri një pyetje të thjeshtë: a e parandalon vërtet anulimi i certifikatave njerëzit nga përdorimi i një faqeje të komprometuar? Duke shikuar www.westpac.com.au, ai tregoi se domeni zgjidhet në infrastrukturë të hostuar nga Amazon dhe jo në infrastrukturë të operuar drejtpërdrejt nga Westpac, dhe se faqja përdor një certifikatë të lëshuar nga DigiCert më shumë se nëntë muaj më parë. Gjatë një periudhe të tillë mund të ndodhin një sërë dështimesh sigurie, duke përfshirë komprometimin e autoritetit certifikues, vjedhjen e një çelësi ose një gabim operacional, dhe pjesa e vështirë është se si të pavlefshëmosh një certifikatë kur ndodh një nga këto ngjarje.

Mekanizmi tradicional është Lista e Anulimit të Certifikatave (CRL) X.509, e cila publikon numrat serialë të certifikatave që nuk duhet të besohen më; në parim një shfletues merr listën, validon nënshkrimin e saj dhe kontrollon nëse certifikata përpara tij shfaqet atje. Huston tregoi një shembull liste që përditësohej çdo javë dhe përmbante 17,527 certifikata të anuluara. Në praktikë procesi është shumë i ngadaltë për të mbështetur validimin rutinë të shfletuesit: është teknikisht i shëndoshë por rrallë përdoret siç ishte menduar fillimisht. Protokolli i Statusit të Certifikatave në Linjë (OCSP), i përcaktuar në RFC 2560, ofroi një alternativë përmes pyetjeve të statusit në kohë reale, por krijon shqetësime privatësie duke zbuluar aktivitetin e shfletimit dhe paraqet rreziqe të mundshme të mohimit të shërbimit përmes kërkimeve të centralizuara, dhe vendosja e tij mbetet e paplotë dhe e paqëndrueshme. HTTPS dhe TLS gjithashtu mbështesin kapjen e OCSP, në të cilën një server furnizon një përgjigje OCSP të nënshkruar gjatë dorëzimit TLS; kjo përmirëson privatësinë dhe zvogëlon vonesën, megjithatë një server i komprometuar nuk ka gjasa të japë dëshmi se certifikata e tij është anuluar, gjë që kufizon efektivitetin e mekanizmit. Mbështetja e shfletuesve ndryshon ndjeshëm. Let's Encrypt, tani autoriteti certifikues më i madh në botë, ndërpreu shërbimet e tij OCSP në 2025 pasi përpunoi më shumë se 140,000 kërkesa në sekondë përmes Akamai, dhe mbështetja për Must Staple në thelb u zhduk në të njëjtën kohë. Chrome ndaloi së mbështeturi në OCSP në 2014 dhe nuk adoptoi kurrë kapjen si mekanizëm primar validimi, ndërsa Safari ndjek një qasje të ndryshme.

Huston testoi lëshimin dhe anulimin e certifikatave duke përdorur Let's Encrypt brenda një cikli publikimi CRL shtatë-ditor. Certifikata e anuluar u shfaq në listë, por Chrome dhe Safari nuk e njohën anulimin. Firefox e njohu. Duke pasur parasysh pjesën e tregut që mbajnë Chrome dhe Safari, anulimi i certifikatave mbetet kryesisht i paefektshëm në praktikë. Një përgjigje ka qenë shkurtimi i jetëgjatësisë së certifikatave: Let's Encrypt ka reduktuar vlefshmërinë e certifikatave nga 90 ditë në 45 ditë, dhe disa autoritete certifikuese tani lëshojnë certifikata të vlefshme për vetëm gjashtë ditë. Huston argumentoi se edhe kjo është e pamjaftueshme, sepse incidentet e sigurisë ndodhin në milisekonda ndërsa jetëgjatësia e certifikatave matet ende në ditë. Si alternativë ai propozoi përdorimin e DNS-së dhe mekanizmave të saj të integruar të skadimit të cache-it. DANE (Autentikimi i Entiteteve të Emërtuara bazuar në DNS), i kombinuar me DNSSEC, lejon që materiali i çelësave të publikohet me jetëgjatësi shumë më të shkurtra, dhe ekziston gjithashtu një model DANE i kapur që ofron funksionalitet të ngjashëm me certifikatat X.509 dhe kapjen OCSP. Ai përfundoi se arritja e kredencialeve vërtet të shkurtra në web mund të kërkojë një zhvendosje larg ekosistemit X.509 drejt modeleve të besimit të bazuara në DNSSEC, dhe se sfida qëndron në kalimin nga infrastruktura e projektuar rreth jetëgjatësisë së certifikatave të matura në ditë në një që mund t'u përgjigjet kërcënimeve pothuajse menjëherë.

Ritesh Mukherjee, një lider i menaxhimit të produkteve për NOS dhe AI në Nokia, diskutoi fazën e ardhshme të sigurisë për BGP, protokollin me të cilin rrjetet i tregojnë njëra-tjetrës cilat adresa mund të arrijnë. Validimi i Origjinës së Rrugës (ROV) verifikon nëse një rrjet është i autorizuar të origjinojë një rrugë, ndërsa Autorizimi i Ofruesit të Sistemit Autonom (ASPA) ndihmon në validimin e integritetit të shtegut AS, lista e rrjeteve nëpër të cilat kalon një rrugë. Ai prezantoi disa shembuj të incidenteve të rrugëtimit.

Njëri përfshinte Reliance (AS18101) duke blackholuar prefikset e Telegram. Sistemi RIPE RIS e zbuloi shpejt ngjarjen si një origjinim të rremë rruge, dhe Telegram u përgjigj duke shpallur prefikse më specifike, të cilat AS18101 gjithashtu i përhapi; për shkak se ato shpallje u shtrinë përtej Indisë, rrjetet jashtë vendit zgjodhën atë që dukej si shtigje më të shkurtra. Incidenti u bë një rrëmbim BGP sepse të dhënat e Regjistrit të Rrugëtimit të Internetit treguan se AS18101 nuk ishte i autorizuar të origjinojë rrugët e prekura, dhe ROV do ta kishte zbuluar problemin dhe do të kishte parandaluar përhapjen më të gjerë. Megjithatë vetëm 27% e sistemeve autonome aktualisht zbatojnë ROV, dhe adoptimi në Indi mbetet veçanërisht i ulët. Një shembull i dytë përfshinte SingNet (AS3758): një shpallje rruge nga AS17894 u filtrua nga AS37100, por trafiku u devijua gjithsesi përmes Sparkle (AS6762), i cili përhapi një rrugë më specifike. Seacom kishte aktivizuar ROV, por varësia e tij nga Sparkle zvogëloi përfitimin, duke treguar se si vendosja e pjesshme krijon pika të verbëra që lejojnë rrëmbimet të vazhdojnë brenda seksioneve të zonës pa default, bërthama e internetit që përcjell trafikun pa një rrugë alternative. Një rast i tretë ishte një rrjedhje rruge nga Vodafone Idea (AS55410), e cila shpalli mijëra prefikse që Bharti Airtel (AS9498) më pas i përhapi, duke shkaktuar keqdrejtim të gjerë trafiku drejt AS55410. Adoptimi i ulët i ROV, filtrimi i kufizuar i shtigjeve dhe mungesa e kontrolleve maksimale të prefikseve kontribuan të gjitha në shkallën e atij incidenti.

Këta shembuj ilustrojnë sfidat e sigurisë së rrugëtimit që kanë prekur rrjetet në të gjithë rajonin e Azisë-Paqësorit për gati dy dekada. Vendosja e ROV në rajon mbetet prapa rajoneve të tjera të Regjistrit të Internetit Rajonal, megjithëse disa ekonomi, duke përfshirë Vietnamin, Indonezinë dhe Filipinet, kanë arritur nivele më të forta vendosjeje; India ka arritur 88% mbulim të Autorizimit të Origjinës së Rrugës, por zbatimi mbetet i kufizuar. Mukherjee propozoi një model mbrojtjeje me tre pjesë: BMP për zbulimin e anomalive, ASPA për validimin e shtegut, dhe ROV me zbatim. Ai gjithashtu theksoi RAVEN, Monitorin e Sigurisë së Rrugëtimit BGP të Nokia, i cili është i disponueshëm përmes depove GitHub të Nokia dhe ndihmon operatorët të vlerësojnë ekspozimin e tyre ndaj sigurisë së rrugëtimit përpara se të zbatojnë politika bllokimi. RAVEN funksionon si një binar i vetëm, merr të dhëna rrugëtimi përmes BMP, dhe mund të integrohet me validues RPKI si Routinator; gjithashtu mbështet panele Grafana, webhooks, integrim FlowSpec dhe auditime nga rreshti i komandave. Vendosja e BMP në Adj-RIB-In, tabela e rrugëve që një router ka marrë nga një fqinj përpara se të zbatohet politika, ofron dukshmëri në sjelljen e rrugëtimit dhe mund t'i ndihmojë operatorët të bëhen fqinjë më të mirë. Ai mbrojti fuqishëm kufizimet maksimale të prefikseve në sesionet eBGP për të parandaluar që rrjedhjet e rrugëve të mbingarkojnë infrastrukturën e rrugëtimit, dhe inkurajoi vendosjen afatgjatë të ASPA, të ROV me politika hedhjeje dhe pjesëmarrjen aktive në MANRS.

Për përdoruesit e përditshëm, fijet që kalojnë nëpër sesion kthehen të gjitha në besim: çelësat që nënshkruajnë përgjigjet DNS, certifikatat që synojnë të provojnë se një faqe interneti është ajo që pretendon se është, dhe informacioni i rrugëtimit që vendos nëse trafiku arrin në vendin e duhur. Shumica e routerëve shtëpiakë dhe zgjidhësve të ofruesve do ta trajtojnë automatikisht ndryshimin e çelësit DNSSEC, por kushdo që drejton zgjidhësin e vet, ose varet nga dikush që e bën këtë, duhet të kontrollojë pas 11 tetorit 2026 që validimi ende funksionon, sepse një zgjidhës që ndalon në heshtje validimin ka humbur një mbrojtje që kishte më parë. Për lexuesit që nuk duan të varen fare nga një zgjidhës ofruesi, AEU DNS është një shërbim DNS privat dhe i kriptuar, dhe dokumentacioni i tij publik përshkruan validimin DNSSEC dhe qasjen pa regjistrime që ofron, kështu që kushdo mund të kontrollojë detajet dhe të vendosë nëse i përshtatet atij.