Uudised, sündmused ja blogi

DNSSECi automatiseerimine @ Tech37

Esmakordselt oli kohal Küprose tippdomeeniregister (.cy). Tilluke saareriik, kus rahvast polegi palju vähem kui Eestis (1,2 mln), domeeninduse osas on see register aga pilk minevikku. Asutatud 1992 kohaliku ülikooli juurde, tegutseb see pea muutumatuna tänaseni pakkudes vaid otseregistreeringuid kohalikkuse nõudega ning vaid ühe teise taseme domeeni alla 13st. Tulemuseks valdavalt käsitööl toimiv register ja natuke üle 13 000 registreeritud domeeni. Märgata võib teatavaid sarnasusi .ee algusaegadega. Huvitava lahendusena märgin ära registreerimise perioodid, mis on seotud kalendriaastaga - registreeringud lõppevad 31. detsembril. Domeenid registreeritakse või pikendatakse korraga 1 või 2 aastaks ja esmaregistreerimisel sõltub hind kvartalist, millal registreering vormistati - põhimõtteliselt 3-kuused registreeringud. Ette on võetud esimesed sammud tõhususe suunal - välja on kuulutatud hange uue automatiseeritud registrisüsteemi loomiseks, millega loodetakse teenust pakkuma hakata juba 2018 lõpuks. Oma süsteemi arendust põhjendasid nad oma unikaalsusega, kuid arenduseks ette nähtud aeg tundub pehmelt öeldes ambitsioonikas.

Suhteliselt ootamatu üllatusena, vähemalt minu jaoks, tuli sakslaste teade, et nad uurivad võimalusi oma andmekeskuste uuendamiseks ning tugevalt on pildis ka privaatsed ja avalikud pilvelahendused. Üllatav oli see seetõttu, et nad just avasid andmete deponeerimise (data escrow) teenuse, mis on suunatud eelkõige Euroopas tegutsevatele uutele rahvusvahelistele ülddomeenidele (gTLD). Nad on panustanud palju automatiseerimisse ja teatasid just edust oma registrisüsteemi viimase osa, andmebaaside kopeerimise automatiseerimisel (Patroni). Lisaks taolistele andme- ja IT-taristu alast kõrget kompetentsi nõudvatele teenustele on ka nende suurus ja võimekus selline, mis võimaldab minu hinnangul oma IT-taristut piisavalt hästi teha ning luua lisaväärtust. Sellele vaatamata leiavad ka nemad, et saab paremini ja pilvelahendused on siin mõistlik alternatiiv. Alles hiljuti, rääkides registritest ja pilvelahenduste levikust, julgesin öelda, et Saksa register on ilmselt üks vähestest, kes pilve ei lähe, arvestades just nende suurust ja pakutavaid teenuseid...

Uudiste rubriigist mainin ära .eu, kes on võtnud suuna oma EPP lahenduse standardiseerimisele. EPP on protokoll, mille abil registripidajad suhtlevad registritega. Plaan on loobuda nii paljudest ebastandardsetest .eu spetsiifilistest EPP protokolli laiendustest kui vähegi võimalik. Muuseas, sama teema on ka meil hetkel päevakorras ja arutleme oma partnerite, registripidajatega, võimalusi ja lahendusi .ee registreerimise teenuse lihtsustamiseks oluliselt isikutuvastuse ja .ee kvaliteedis järeleandmisi tegemata.

Kui Belgia kaks aastat tagasi oma pilve plaaniga välja tuli ootasin meeletut kära ja pilve juttu "söögi alla ja peale", kuid möll jäi ootamatult väikeseks, belglastele ei antud isegi CENTRi innovatsiooni auhinda, mis läks mingitel segastel põhjustel brittidele domeenide segmenteerimise eest... Ilmselge peakujude küsimus. Nüüd peale Rootsi teadet, et nemad on teised, on mölluks läinud ja juttu on sellest igal võimalikul hetkel - rootslased ise on muidugi märkimisväärselt aktiivsed oma tegemistest rääkima. Plaan jätkuvalt jõus ja 2018 veebruar lülitatakse oma serverid välja. Seekord rääkisime nende lahenduse puhul rohkem sõnumikihist RabbitMQ, mis vahendab kogu suhtlust liideste ja registri vahel. Esimene küsimus tekkis seoses Rest APIga ehk sünkroonsete liidestega, samal ajal kui igasugune sõnumivahetuse kiht toimib asünkroonselt. Selgus, et see ongi nende lahenduse kõige nõrgem koht - vähe sellest, et Rest päringute puhul tuleb seansse elus hoida kuni serverist vastus laekub, ei ole see ka skaleeruv. Igas "serveriruumis" on oma üksik RabbitMQ teenus, mida rohkem instantse, seda suurem viive, mistõttu ongi see osa süsteemist limiteeritud. Parem plaan tundub siin jätta sõnumivahetus asünkroonsete teenuste vahele ja võimaldada sünkroonsetel otsesuhtlust süsteemiga - selliselt on oma süsteemi lahendanud näiteks EURID. Dockeri konteinerite halduseks kasutavad nad Amazoni enda teenust. Põgusalt oli taas juttu ka motivatsioonist ning nii nagu belglased toonitas ka .se, et rahaline võit ei ole eesmärk, pigem ikka ressursi vabastamine mitte tulu toovate tegevuste alt ja kvaliteedi tõus. Sest Amazon suudab taristu teenuseid teha alati kordades paremini kui nemad kunagi suudaks, lisaks suurem paindlikkus, turvalisus ja kindlus rünnetele. Esialgsed hinnangud maksumuse osas on aga samas suurusjärgus oma taristu halduseks tehtavate kulutustega. Lõpuks tuli ära ka torge sakslaste suunas - sügav lugupidamine nende saavutuste ees süsteemi, eriti andmebaaside sünkroonimise automatiseerimisel, aga Amazonis on see üks nupuvajutus ja ei mingit pingutust.

Sakslaste DomainID projekt on vahepeal saanud demotavaks ja seda nad ka tegid. DomainID on DNSi põhine SSO (single-sign-on) lahendus alternatiiviks elektroonilistele IDle ja laialt kasutatavatele Google ja Facebooki põhistele kasutaja tuvastamise lahendustele. See pakub suuremat paindlikkust ja kasutajale paremat kontrolli oma andmete üle. Süsteemis on hulk osapooli - kasutaja ise, interneti teenus (näiteks e-pood), mis võimaldab DomainID-ga kasutaja tuvastamist, identiteediamet (Identity Authority), mis hoiab kasutaja autentimise infot (näiteks kasutajanimi ja parool), identiteediagent (Identity Agent), kelle valduses on kasutaja isiklikud andmed ning DNS, mis suunab teenusepakkuja korrektse identiteediameti ja -agendi juurde. Peamiseks erinevuseks teiste laialt leivinud lahendustega on identiteediameti ja -agendi lahusus (üks täiendav osapool), mis annab kasutajale vabaduse otsustada, kus ta oma isikuandmeid hoiab. Identiteediagendiks võib olla mõni suur spetsialiseerunud ettevõte või saab kasutaja vastava teenuse omale koju püsti panna, kuid siis peab ise tagama, et teenus oleks alati kättesaadav. Domeeniregister on siis vaikimisi identiteediameti rollis ja kasutajanime/parooli asemel saab kasutada DNSSEC/DANE võtit. Lahenduses on kasutatud avatud, laialt levinud ja kasutatavaid tehnoloogiad: OpenID Connect, DNS, DANE, ACME. Idee on iseenesest hea, aga kitsaskohaks on minu arvates identiteediagent - nõuab kasutajalt ekstra pingutust, et valida välja mõni tehnoloogiat toetav partner või siis võtta ette veel suurem tegemine ja ise vajalik teenus püsti panna ja siis loota, et mõni teenus, mida kasutaja kasutab toetab DomainID-d. Parem lahendus oleks kui domeeniregister täidaks nii agendi kui ameti rolli ja domeeni registreerimiseks antud andmed ongi need, mida  teenusepakkujatele edastada on võimalik. Ilmselt on registrikeskne lähenemine selle tehnoloogia abil samuti võimalik - sakslastel lihtsalt on isevärki suhtumine interneti ja isikuandmete privaatsusesse.

Kohtumise peateemaks oli aga CSYNC ja täpsemalt DNSSEC võtmete edastamine domeeniregistrisse DNSi abil kasutades CDS/CDNSKEY kirjeid. Tänaseks on selle teema algataja Kanada ja lisaks ka Tšehhi register juba juurutanud ning terve hulk teisi registreid seda juurutamas. Seega on üldine hoiak tehnoloogia ja lähenemise suhtes positiivne, kuid on ka oponente eesotsas EURIDga. Kõige pikem arutelu keerleski selle ümber, kas ikka on hea mõte registripidajast mööda minna. Meedetuletuseks, Kanada just sellepärast selle teema ette võttiski, et lahendada turutõrget, kus registreerijatel ja nimeserveri teenuse pakkujatel on huvi DNSSECi juurutamise vastu, kuid registripidajate poolne huvi on vähene. Vajadust tõukas tagant Cloudflare - üks maailma suurimaid DNS teenuse pakkujaid, kes rakendab vaikimisi oma kõigile klientidele DNSSECi. Lahendus seisneb selles, et nimeserverite haldaja paneb uue võtme oma tsoonifaili CDS või CDNSKEY kirjena, kust see siis kas saadetakse tippdomeeniregistrisse või korjatakse registri poolt ise üles. EURIDi seisukoht, tuginedes oma registripidaja lepingule, on et registripidaja vastutab otsast lõpuni registreerimise toimingu eest koos andmete kogumise ja õigsuse tagamisega. Et uued andmed DNSSECi kohta aga registripidajat ei läbi, ei saa registripidaja nende eest vastutust võtta ja omab igati alust registris olevad andmed enda andmetega üle kirjutada. Segaduse vältimiseks tuleks EURIDi hinnangul oluliselt muuta registrilepingut ning olukorras, kus mingid andmed on registripidajast sõltumatult uuendatud, peaks koheselt võtma ära registripidajalt ka õiguse neid andmeid edaspidi muuta. Registrid, kes on juba lahenduse juurutanud või kes sellega tegelevad ja on jõudnud registripidajatega teemat arutada, .eu sarnase järelduseni jõudnud pole. Ise jagan taanlaste seisukohta, et registreeritud domeeniga seotud andmed kuuluvad registreerijale ja nii registril kui registripidajal on õigus andmeid muuta vaid registreerija taotlusel või volitusel. Keeldude ja käskudega lahendus ei pruugi olla parim, küll aga on oluline osapooltega aktiivselt suhelda, et kõik oleksid teadlikud, mis ja kuidas toimub. Siis on aga veel küsimus, kuidas peaks domeeni haldav registripidaja saama teada, et andmed registris on muutunud? Appi tõttab veel küll kinnitamata EPP laiendus - Change Poll. Sama küsimus on meil teemaks ka näiteks registreerijatele oma kontaktandmete muutmise võimaluse andmisel meie registreerija portaali vahendusel. Üldiselt peetakse lahendust, kus register ise andmed domeeni teenindavast nimeserverist üles korjab, eelistatumaks. Kuidas aga tagada kaitse ekslike andmete või ründe läbi valede andmete lisamise vastu tippdomeeni tsooni. Probleem puudutab pigem veel DNSSECga kaitsmata domeene. Mäletatavasti on tšehhid siin välja pakkunud päris hea lahenduse jälgides nimeserverit 7 päeva ja kui CDNSKEY kirje selle aja jooksul muutunud pole, lisatakse see tsooni. Lahendus hea, kuid ehk on 7 päeva liiga pikk aeg. Šveitslased kaaluvad 2 ja 3 päeva vahel - see peaks olema piisavalt pikk aeg, et välistada PGP kaaperdamise ründed ja kogemata nimeserverisse sattunud kirjed. Täiendavalt pakkus Kanada välja, et uute registreeringute puhul, kus näiteks ühe tunni jooksul peale selle registreerimist leitakse nimeserverist CDS/CDNSKEY kirje, võib selle koheselt tsooni tõsta - pole nähtavat põhjust oodata. Registripidaja ja registreerija teavitamine taolistest automaattoimingutest on igal juhul vajalik. Samas on lahendamata veel opt-out küsimus - kui näiteks registripidaja ise otsustab, et skaneerib oma klientide nimeservereid CSYNC kirjete leidmiseks ning saadab need ise siis edasi registrisse. Kas ja kuidas peaks saama konkreetse registripidajaga seotud domeene eemaldada registripoolsest jälgimisnimekirjast? EURIDi näitel registripidajate tõsise vastuseisu võimalikuks põhjuseks sellele lahendusele võib olla CSYNC laiemalt. See võimaldab palju enamat kui DNSSEC võtmete uuendamist registris - põhimõtteliselt on võimalik kasvõi registripidaja vahetus läbi viia ja registripidaja vaates on see justkui usse täis topsi avamine.

Päris huvitav kohtumine oli. Järgmine kord on kevadel Moskvas järjekordsel töögruppide ülesel Jamboreel.