Kiel registrite je 02:33, 13 jun. 2014 redakti Gamliel Fishkin (diskuto \| kontribuoj) Patrolantoj, Administrantoj 5 269 redaktoj e →‎Priskribo: stilo ← Iru al antaŭa ŝanĝo		Kiel registrite je 02:45, 13 jun. 2014 redakti malfari Gamliel Fishkin (diskuto \| kontribuoj) Patrolantoj, Administrantoj 5 269 redaktoj e →‎Historio: vikiigo, korekto de tajperaroj, stilo Iru al sekvanta ŝanĝo →
Linio 17: 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 <nowiki>RFC 2535</nowiki>. Bedaŭrinde, la specifo fare de IETF <nowiki>RFC 2535</nowiki> 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 [[Atakoj de rifuzo en priservado\|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. Linio 23: 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 {{alilingve\|en\|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 ~~komanciĝis~~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 ({{lang-en\|delegation signer}}) por provizi aldonan nivelon de nerekta [[Delegado de domajno\|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, ~~averaĝe~~ 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 ~~signifas~~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 ==

DNSSEC: Malsamoj inter versioj