DNSSEC shton kontrolle të origjinës që HTTPS nuk mund t’i ofrojë i vetëm

DNSSEC shton një shtresë origin authentication që HTTPS nuk mund ta ofrojë i vetëm, sipas një rishikimi të deSEC të diskutuar nga APNIC më 3 nëntor 2026. DNSSEC, shkurtim për Domain Name System Security Extensions, i mundëson një sistemi të verifikojë se informacioni i nënshkruar DNS erdhi nga operatori i domain dhe nuk u ndryshua gjatë rrugës. Kjo ka rëndësi sepse DNS, Domain Name System që e shndërron emrin e një faqeje në destinacionin që përdorin kompjuterët, konsultohet përpara se një browser të mund të fillojë kontrollimin e lidhjes së enkriptuar të një faqeje interneti.

Rishikimi, i publikuar në CircleID, shqyrton pretendime të përsëritura rreth DNSSEC, përfshirë kompleksitetin e tij operacional, zbatimin jo të plotë dhe vlerën më të gjerë shoqërore. APNIC veçon listën IANIX si pjesë të rëndësishme të këtij diskutimi. IANIX është një regjistër që mirëmbahet në mënyrë aktive për ndërprerjet që lidhen me DNSSEC në të gjithë sistemin e emrave të domain, duke treguar se dështimet e konfigurimit dhe ato operacionale janë një shqetësim real dhe jo një kundërshtim hipotetik. deSEC ka diskutuar më parë edhe key drift midis parent dhe child domains, ku informacionet përkatëse DNSSEC nuk përputhen më, si edhe post-quantum cryptography në DNSSEC, që lidhet me metoda të synuara për të mbetur të sigurta ndaj sulmeve të ardhshme nga quantum computing.

Një argument i zakonshëm është se HTTPS tashmë i mbron faqet e internetit, duke e bërë DNSSEC të panevojshëm. HTTPS përdor TLS, ose Transport Layer Security, për të enkriptuar lidhjen e një browser dhe për të autentikuar server përmes një certifikate digjitale. Por browser duhet të përdorë fillimisht DNS për të mësuar se ku duhet të lidhet. Prandaj, TLS mbron lidhjen me endpoint që arrin browser, ndërsa DNSSEC ndihmon në verifikimin e të dhënave të nënshkruara DNS që përdoren fillimisht për ta gjetur atë endpoint. Të dy mekanizmat trajtojnë pjesë të ndryshme të rrugës.

Nëse një ndërmjetës ridrejton një DNS query të pambrojtur, përdoruesi mund të dërgohet në një destinacion tjetër përpara se browser të kontrollojë një certifikatë TLS. Diskutimi i APNIC vëren se, nëse certificate pinning nuk zbatohet me rreptësi, një kundërshtar mund të jetë ende në gjendje të krijojë një lidhje TLS të mbështetur nga një certificate authority. certificate pinning është një metodë që e bën një aplikacion të presë një certifikatë ose identitet të caktuar, në vend që të pranojë çfarëdo certifikate tjetër që konsiderohet e besuar. Më pas, browser mund të shfaqë një lidhje të enkriptuar edhe pse përdoruesi nuk ka mbërritur në destinacionin e synuar.

Homograph attacks krijojnë një mënyrë tjetër mashtrimi. Ato përdorin karaktere të ngjashme nga ana pamore për ta bërë një emër domain të ngjajë me një tjetër, duke dobësuar aftësinë e një personi për të dalluar se ku po shkon lidhja. HTTPS mund të autentikojë domain e ngjashëm që u hap në të vërtetë, por kjo nuk e bën atë domain që përdoruesi synonte të vizitonte. DNSSEC nuk e zëvendëson kontrollimin e kujdesshëm të adresave, por ofron prova të verifikueshme për të dhënat e nënshkruara të publikuara nga një registrant i domain, domethënë personi ose organizata që kontrollon regjistrimin.

Këto të dhëna DNS të autentikuara mund të mbështesin edhe sisteme të tjera sigurie. Rishikimi i deSEC identifikon DANE, ose DNS-based Authentication of Named Entities, si një aplikacion që mund të përdorë records të validuara nga DNSSEC për t’i lidhur shërbimet me informacionin e certifikatave. Ai përmend gjithashtu CAA, ose Certification Authority Authorization, që i lejon një domain të publikojë se cilat certificate authorities mund të lëshojnë certifikata për të. Argumenti qendror është se DNSSEC krijon një bazë besimi të pavarur nga një aplikacion ose metodë e caktuar shpërndarjeje, në vend që të konkurrojë me HTTPS për të njëjtën detyrë.

Rishikimi trajton edhe dy kundërshtime më të gjera. Njëri është frika se një strukturë hierarkike besimi mund të mundësojë kontroll shtetëror nga lart-poshtë mbi qasjen në informacion. APNIC pranon se kontrolli shtetëror i qasjes në internet është pjesë e përvojës reale të shumë njerëzve, por argumenton se kufizimet juridiksionale ndaj faqeve të internetit, përmbajtjes dhe shërbimeve online burojnë nga sisteme më të gjera ligjore dhe shoqërore, pavarësisht nëse DNSSEC është i pranishëm apo jo. Refuzimi i DNSSEC nuk do t’i eliminonte vetvetiu këto kontrolle.

Kundërshtimi tjetër është adoptimi jo i plotë. Zbatimi i pjesshëm kufizon numrin e domains për të cilat mund të validohet një zinxhir i plotë informacioni të nënshkruar, por refuzimi i zbatimit nuk mund ta zgjidhë këtë kufizim. APNIC e krahason procesin e gjatë të adoptimit me IPv6 dhe Resource Public Key Infrastructure, ose RPKI, një sistem për autentikimin e rrjeteve që janë të autorizuara të njoftojnë Internet routes. Teknologjive të këtij lloji mund t’u duhet kohë e konsiderueshme për të arritur adoptim të dobishëm dhe masë kritike.

Artikulli i deSEC përfundon me më shumë se 60 mbështetje nga profesionistë që përfaqësojnë DNS providers, registries, registrars, organizata mbikëqyrëse, kërkimin dhe punën për standardet. Mbështetjet nuk e eliminojnë kompleksitetin ose rrezikun e ndërprerjeve të DNSSEC, por tregojnë se përkrahja shtrihet në disa pjesë të ekosistemit DNS. Përfundimi praktik nuk është se DNSSEC zëvendëson TLS, certifikatat ose menaxhimin e mirë të domain. Përfundimi është se secili mbron një hallkë të ndryshme në zinxhirin që e çon përdoruesin nga një emër i shtypur te një shërbim i autentikuar.

Për lexuesit që duan edhe një shërbim privat DNS, AEU DNS ofron DNS privat dhe të sigurt për të gjithë, ndërsa DNSSEC mbetet mekanizmi i veçantë për autentikimin e informacionit të nënshkruar DNS. Pronarët e faqeve të internetit duhet ta trajtojnë DNSSEC si një veçori sigurie operacionale që kërkon konfigurim të saktë dhe vëmendje të vazhdueshme, jo si një switch që mund të aktivizohet dhe më pas të harrohet.