Saltu al enhavo

DNSSEC

El Vikipedio, la libera enciklopedio

DNSSEC (angle Domain Name System Security Extensions) estas aro de etendoj fare de IETF por la protokolo DNS ebligantaj minimumigi atakojn, ligitajn al fia anstataŭo de DNS-adreso ĉe resolvo de domajnaj nomoj. Ĝi estas celita provizi al DNS-klientoj aŭtentajn respondojn je DNS-demandoj (aŭ aŭtentan informon pri foresto de datumo) kaj garantii ilian tutecon. Estas uzata kriptografio kun nefermita ŝlosilo. Ne estas garantiataj disponebleco de datumo kaj konfidenco de demandoj. Garantiado de sekureco de DNS estas krize grava por la interreta sekureco ĝenerale.

Priskribo

[redakti | redakti fonton]

Origine DNS estis ellaborata ne por sekureco, sed por kreo de skaleblaj distribuitaj sistemoj. Kun paso de tempo DNS iĝas ĉiam pli vundebla. Fiuloj facile alidirektas demandojn de uzantoj pri alfabeta nomo al falsaj serviloj kaj tiamaniere ricevas aliron al pasvortoj, numeroj de bankaj kartoj kaj aliaj konfidencaj informoj. La uzantoj mem nenion povas fari pri tio, ĉar en plej multaj okazoj ili eĉ ne suspektas, ke la demando estis alidirektita — la enhavo de la adreslinio de foliumilo kaj la retejo mem estas precize tiaj, kiaj ilin supozas vidi la uzanto. DNSSEC estas provo garantii sekurecon kun samtempa retroira kongruo.

DNSSEC estis ellaborita por garantii sekurecon de klientoj kontraŭ falsa DNS-datumo, ekzemple kreita per veneno de DNS-kaŝmemoro (angle DNS cache poisoning; ankaŭ nomata falsado de DNS (angle: DNS spoofing)). Ĉiuj respondoj de DNSSEC havas ciferan subskribon. Kontrolante ciferan subskribon, DNS-kliento kontrolas ĝustecon kaj tutecon de la informo.

DNSSEC ne ĉifras datumon kaj ne ŝanĝas ĝian administradon, estante kongrua kun fruaj versioj de la nuna sistemo DNS kaj de aplikaĵoj. DNSSEC povas certigi ankaŭ tiajn informojn kiel ĝeneralcelajn kriptografiajn certigilojn enhavatajn de CERT-rikordo. RFC 4398 (angle) priskribas kiel distribui tiujn certigilojn, en tiu nombro per retpoŝto, kio ebligas uzi DNSSEC kiel mondskalan deponejon de certigiloj subskribŝlosilaj.

DNSSEC ne garantias konfidencon de datumo; interalie, ĉiuj DNSSEC-aj respondoj estas aŭtentigitaj, sed ne ĉifritaj. DNSSEC ne defendas kontraŭ atakoj de rifuzo en priservado (angle: Denial-of-service attack) senpere, kvankam iusence faras tion nerekte. Aliaj normoj (ne DNSSEC) estas uzataj por provizo de granda amplekso de datumo transsendata inter DNS-serviloj.

Specifoj de DNSSEC (DNSSEC-bis) detale priskribas la nunan protokolon DNSSEC. Vidu RFC 4033, RFC 4034 kaj RFC 4035 (angle).

Historio

[redakti | redakti fonton]

Origine la domajna nomsistemo ne havis meĥanismojn por defendo kontraŭ fia anstataŭo de informo en respondo de servilo, ĉar dum la ellaborado (komence de la 1980-aj jaroj) la minacoj al la sekureco de la moderna Interreto ne estis aktualaj. Klientoj konkludadis pri ĝusteco de ricevita informo nur per du-bitoka identigilo de la demando. Do, fiulo bezonis foliumi 65536 signifojn por «veneni kaŝmemoron». Tio signifas, ke la datumo en DNS estas damaĝita (intence aŭ pro eraro) kaj DNS-servilo kaŝmemoras damaĝitan datumon por optimumigi rapidecon (la kaŝmemoro iĝas «venenigita») kaj komencas provizadi tiun neaŭtentan datumon al siaj klientoj. En 1990 Steven M. Bellovin (angle: Steven M. Bellovin) eltrovis seriozajn mankojn en sekureco. Esploroj en ĉi branĉo komenciĝis kaj aktivis ekde la tempoj de publikigo de lia raporto en 1995.

La unua versio de DNSSEC, RFC 2065, estis publikigita de IETF en 1997. Provoj realigi tiun specifon venigis al nova specifo, RFC 2535, en 1999. Estis planite realigi DNSSEC surbaze de RFC 2535.

Bedaŭrinde, la specifo fare de IETF RFC 2535 havis seriozajn problemojn rilate skaladon al la tuta Interreto. Al la 2001-a jaro iĝis klare, ke tiu specifo estas maltaŭga por grandaj retoj. Dum normala funkciado DNS-serviloj ofte malsinkroniĝadis kun siaj patroj (superaj en la hierarkio domajnoj). Ordinare tio ne estis problemo, sed kaze de uzata DNSSEC la malsinkrona datumo povis kaŭzi pretervolan DoS-efikon. Protektita DNS estas ege pli risurckonsuma kaj kun plia, kompare al la «klasika» DNS, facileco povas okupi ĉiujn komputajn risurcojn.

La unua versio de DNSSEC estis postulanta komunikadon el ses mesaĝoj kaj grandan kvanton de datumo por okazigi ŝanĝojn de heredanto (ĉiuj DNS-zonoj de heredanto devas esti komplete transdonitaj al ties patro, la patro faras ŝanĝojn kaj sendas ilin reen al la heredanto). Krome, ŝanĝoj en publika ŝlosilo povis havi katastrofan efikon. Ekzemple, se la zono «.com» ŝanĝus sian ŝlosilon, estus bezonate sendi 22 milionojn da rikordoj (ĉar necesus aktualigi ĉiujn rikordojn en ĉiuj heredantoj). Do, DNSSEC laŭ la skemo de RFC 2535 ne povis esti skalita ĝis la amplekso de Interreto.

Tiuj malfacilaĵoj siavice venigis al apero de novaj specifoj (RFC 4033, RFC 4034, RFC 4035) kun gravaj ŝanĝoj en DNSSEC (DNSSEC-bis), kies nova versio eliminis la precipan problemon de la antaŭa realigo kaj, kvankam laŭ la nova specifo klientoj bezonas fari aldonajn agojn por kontroli ŝlosilojn, ĝi montriĝis tute taŭga por praktika aplikado.

En 2005 aperis la nuna versio de DNSSEC. En 2008 Dan Kaminsky (angle: Dan Kaminsky) montris, ke veneni kaŝmemoron eblas dum dek sekundoj. La ellaborantoj de DNS-programaro respondis per tio, ke aldone al demanda identigilo ekis hazarde elektadi elirpordon por la demando. Samtempe komenciĝis diskutoj pri enkonduko de DNSSEC.

La ŝanĝo de DNSSEC nomata DNSSEC-bis (la titolo estis donita por distingi DNSSEC-bis disde la origina metodo de DNSSEC en RFC 2535) uzas la principon DS (angle delegation signer) por provizi aldonan nivelon de nerekta delegado dum transdono de zonoj disde patro al heredanto. Laŭ la nova metodo, kaze de ŝanĝo de la nefermita ŝlosilo al la administranto de supera domajno estas sendataj nur unu aŭ du mesaĝoj anstataŭ ses: la heredanto sendas diĝeston (fingerprint, hash) de nova nefermita ŝlosilo al la patro. La patro simple deponas identigilon de nefermita ŝlosilo por ĉiu el la heredantoj. Tio signifas, ke al la patro estos sendita tute malgranda kvanto de datumo anstataŭ interŝanĝo de grandega kvanto de datumo inter la heredanto kaj la patro.

Subskribado kaj kontrolado de datumo de DNS kreas aldonajn elspezojn, kio negative influas produktivecon de la reto kaj de serviloj. Ekzemple, DNSSEC-zono (aro de domajnaj nomoj de koncerna nivelo en konkreta domajno) averaĝe 7—10-oble superas amplekse la domajnan nomsistemon mem. Generado kaj kontrolado de subskriboj prenas signifan tempon de centra procesilo. Subskriboj kaj ŝlosiloj okupas dekoble pli da loko sur disko kaj en operacia memoro ol la datumo mem.

Principo de funkciado

[redakti | redakti fonton]
Kontrolado de aŭtenteco de datumo en DNSSEC

La principo de funkciado de DNSSEC estas bazita sur uzo de cifera subskribo (angle: Digital signature). La administranto disponas rikordojn pri konformeco inter domajna nomo kaj IP-adreso. DNSSEC metas al ĉiu el ili en striktan korelacion specialan, strikte difinitan sinsekvon de simboloj, kio estas cifera subskribo. La precipa specialaĵo de cifera subskribo estas, ke ekzistas nefermitaj, publike disponeblaj metodoj kontroli aŭtentecon de subskribo, sed generado de subskribo por arbitra datumo postulas ke la subskribanto disponu la sekretan ŝlosilon. Tial testi subskribon povas ĉiu partoprenanto de la sistemo, sed subskribi novan aŭ ŝanĝitan datumon povas en la praktiko nur tiu, kiu havas sekretan ŝlosilon.

Teorie, nenio malhelpas enrompanton kalkuli la sekretan ŝlosilon kaj elekti subskribon, tamen en la praktiko por sufiĉe komplika kaj longa ŝlosilo ne eblas plenumi tian operacion dum racia tempodaŭro kun uzo de la ekzistantaj ilaro kaj matematikaj algoritmoj.

Kaze de disponeblo de la sekreta ŝlosilo kalkulado de cifera subskribo ne prezentas malfacilaĵon. Tia estas la funkciado de malsimetriaj nefermitŝlosilaj ĉifrosistemoj, situantaj en la bazo de la algoritmoj de cifera subskribo.

Subskribo de la radika zono

[redakti | redakti fonton]

Por plenvalora validigo de la tuta datumo transdonata kun uzo de DNSSEC necesas ĉeno de konfido iranta de la radika domajna zono (.). Enkonduko de la korekte subskribita radika zono al ĉiuj radikaj nomserviloj povus kaŭzi kraŝon de la moderna Interreto, tial IETF kaj ICANN kune ellaboris poioman proceduron de enkonduko de la subskribita radika zono kaj de mekanismo de disvastigo de ŝlosiloj. La proceduro daŭris pli ol ok monatojn kaj inkludis popaŝan enkondukon al nomserviloj komence de la radika zono subskribita per nevalida cifersubskriba ŝlosilo. Tiu paŝo estis necesa por provizi testadon de serviloj sub ŝarĝo, konservi retroiran kongruon kun malnova programaro kaj lasi eblecon por reveno al la antaŭa konfiguro.

Al junio de 2010 ĉiuj radikaj nomserviloj korekte traktadis la zonon subskribitan per nevalida ŝlosilo. En julio ICANN okazigis internacian konferencon pri la proceduro de generado de ŝlosiloj de la cifera subskribo per kiu poste estis subskribita la radika zono.

La 15-an de julio de 2010 okazis subskribado de la radika zono kaj komenciĝis enkonduko de la subskribita zono al nomserviloj. La 28-an de julio ICANN komunikis[1] pri sukcesa fino de tiu proceso. La radika zono estis subskribita per cifera subskribo kaj disvastiĝis en DNS.

La 31-an de marto de 2011 estis subskribita la plej granda zono (90 milionoj da domajnoj) — .com[2].

Infrastrukturo de ŝlosiloj

[redakti | redakti fonton]

ICANN elektis tian modelon, kiam subskribado de la zono estas administrata sub kontrolo de reprezentantoj de la interreta komunumo (Trusted community representative, TCR). La reprezentantoj estis elektataj el personoj ne ligitaj al administrado de la radika zono de DNS. La reprezentantoj estis en la postenoj de kripto-oficiroj (Crypto Officer, CO) kaj kuntenanto de restariga ŝlosilo (Recovery key shareholder, RKSH).

La nuna stato

[redakti | redakti fonton]

En oktobro de 2013 en la radika zono estis 81 naciaj domajnoj kaj 13 ĝeneralaj domajnoj subskribitaj per DNSSEC (sen IDN-domajnoj) kaj provizantaj tiamaniere ĉenon de konfido al domajnoj de dua nivelo.

Problemoj enkondukaj kaj mankoj

[redakti | redakti fonton]

Enkonduko de DNSSEC ege prokrastiĝis pro tiaj kaŭzoj kiel:

  1. Ellaborado de retroire kongrua normo, skalebla ĝis la amplekso de Interreto.
  2. Malkonsento, kiu posedu domajnojn de plej alta nivelo (.com, .net).
  3. DNS-serviloj kaj klientoj devas subteni DNSSEC.
  4. Aktualigitaj DNS-resolviloj, sciantaj trakti DNSSEC, devas uzi TCP.
  5. Ĉiu kliento devas ricevi almenaŭ unu konfidatan nefermitan ŝlosilon antaŭ ol komenci uzi DNSSEC.
  6. Kresko de ŝarĝo al la reto pro serioze (6—7-oble) pliiĝinta trafiko de DNS-demandoj.
  7. Kresko de ŝarĝo al procesilo de servilo pro bezono generi kaj kontroli subskribojn tiel ke povas necesi anstataŭo de nesufiĉe potencaj serviloj.
  8. Pliiĝo de postuloj al deponejoj de informoj pri adresado, ĉar subskribita datumo okupas ege pli da loko.
  9. Necesas kreadi, elprovadi kaj perfektigadi programaron de ambaŭ servila kaj klienta partoj, kio postulas tempon kaj provadon en la skalo de la tuta Interreto.
  10. Stub-resolviloj ne estas defenditaj kontraŭ venenado de kaŝmemoro — validigo okazas flanke de rekursiva servilo, kliento ricevas nur respondon kun metita bito AD.
  11. Ege pliiĝis danĝero de atako DNS Amplification.

Plejparto de tiuj problemoj estas solvita fare de teknika interreta komunumo.

Referencoj

[redakti | redakti fonton]
  1. ↑ DNSSEC Root Signing Announcement (angle)
  2. ↑ Deploying Security Extensions in .com Top Level Domain Arkivigite je 2011-04-06 per la retarkivo Wayback Machine (angle)

Eksteraj ligiloj

[redakti | redakti fonton]

RFC-dokumentoj

[redakti | redakti fonton]

(angle)

  • RFC 2535 Domain Name System Security Extensions
  • RFC 3833 A Threat Analysis of the Domain Name System
  • RFC 4033 DNS Security Introduction and Requirements (DNSSEC-bis)
  • RFC 4034 Resource Records for the DNS Security Extensions (DNSSEC-bis)
  • RFC 4035 Protocol Modifications for the DNS Security Extensions (DNSSEC-bis)
  • RFC 4398 Storing Certificates in the Domain Name System (DNS)
  • RFC 4641 DNSSEC Operational Practices
  • RFC 5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
Elŝutita el "https://eo.wikipedia.org/w/index.php?title=DNSSEC&oldid=8618900"