Uudised, sündmused ja blogi

ICANN 57: osa 1 - Nomulus ja DNSSEC

India on huvitav maa - seal on 22 ametlikku riigikeelt, mis annab IDN domeenidele täiesti uue mõõtme ja seetõttu need seal ka väga populaarsed. Indias elab umbes 1,3 miljardit inimest, kellest vaid 30% omab ligipääsu Internetile. See tähendab 70% kasvuruumi ehk märkimisväärseid võimalusi ettevõtluseks. Ligipääsu tagamine internetile ja veevarustusele on India valitsuse strateegilisteks eesmärkideks. Üllatuslikult on Hyderabad nii mõnegi maailma tehnoloogiahiiu suurima välisesinduse asukoht - Microsoft, Google, Facebook, Apple, Amazon. Põgus külastus jättis veidi arusaamatuks miks see nii on, aga juu siis peitub keskkonna asemel võti ligipääsul suhteliselt hästi haritud odavale tööjõule.

Jätkuks RIPE postituses esitatud mõttele kasutada ära IPv4 defitsiiti maailmas, minnes jõuliselt üle IPv6 aadressruumile ja müües vabad IPv4 aadressid hädalistele, rääkis ka India oma raskustest ja pingutustest IPv6 kasutusele võtuga. On ka esimesed tulemused - aastaga on suurenenud IPv6 kasutus riigis ühelt protsendilt kümnele. Seega tasub kiirustada, kui on soov seda võimalust ära kasutada. IPv6 tuleb, sest paljudel on juba väga valus.

Oktoobris kuulutas Google, et teeb oma domeeniregistrisüsteemi tarkvara lähtekoodi kõigile kättesaadavaks. See lõi domeenimaailma kihama ja nii oli ka minu üks oodatumaid esitlusi Google oma. Nomulus on mõeldud eelkõige Google enda tippdomeenide haldamiseks, kuid disainitud algusest peale avatud lähtekoodiga projektina. Lahendus toetub Google Apps pilve taristule ja see teeb sellest esimese pilvelahendustele mõeldud registritarkvara. Aluseks on NoSQL andmebaas ning olemas kõik valdkonna olulised liidesed - EPP, WHOIS, RDAP jne. Miks arendada ise? Googlet ei rahuldanud olemasolevad vabavaralised lahendused - neil oli tarkvara arhitektuuri osas oma nägemus. Lisaks said määravaks soov kasutada NoSQL ning turul puuduv pilvelahendustele optimeeritud lahendus - Google domeeniregistri inimesed soovisid keskenduda olulisele, jättes riistvara küsimuse teistele. Lähtekoodi avaldamisega viivitati, sest algselt oli kasutuses komponente, mida ei tohtinud avaldada - tänaseks on kõik sellised sõltuvused avatud projektist kõrvaldatud. Muidugi on omal kohal ka üllad eesmärgid nagu kogukonnale tagasi andmine ja võimalus kõigil vaadata, kuidas Google konkreetseid probleeme oma süsteemis lahendas. Registrite hulgast tuli muidugi kohe esimesena küsimus, et kas on võimalik lahendust ka oma taristu peale tööle panna. Vastuseks öeldi, et testkeskkonnas on proovitud, kuid toodangus seda selliselt kasutada ei soovitata. Küll aga on kõigil võimalus asi ise ette võtta ja optimeerida lahendus sellise kekkonna jaoks nagu vaja - Googlel endal sellist plaani ega soovi pole. Süsteem on arendatud Javas. Saame sealt kindlasti ka oma lahendusele ideid.

Hollandlased tutvustasid oma lahendust, mis toob DNSSECi valideerimise igale soovijale koju kätte. .NLl on 5,6 mln domeeni, millest 45% on DNSSECiga signeeritud. Heas seisus ses osas on ka näiteks Norra ja Tšehhi. Holland on aga näide tippdomeenist, kus suure DNSSECi leviku kõrval on valideerimise võimekus väga madal. Et ISPd on olnud tõrksad valideerimist lisama, hakkasid hollandlased otsima alternatiivseid lahendusi. Nii sündis Valibox - väike ruuter, mida on lihte koduvõrku lisada. See tekitab eraldi alamvõrgu, mille kliendid on automaatselt kaitstud. Tegemist on siiski tarkvara lahendusega (avatud), mis sobib suvalise Openwrt seadmega. Eestis on DNSSECi valideerimisega olukord hea - kõik suured interneti teenuse pakkujad teevad seda, erandiks on kahjuks kaabelside operaatorid eesotsas Starmaniga, kes seni tõrguvad oma klientidele DNSSECi kaitset võimaldamast.

Oktoobri alguses avaldati Interneti draft TLSA ehk DANEl baseeruv TLS lahendus potentsiaalse nõrkuse kohta tundmatu võtme ründele (UKS - Unknown Key Share attack). Ohtu nähakse olukorras, kus ametliku CA asemel hakatakse TLSA puhul kasutama ise signeeritud sertifikaate. Ametlike CA sertifikaatide häda on seni olnud nende hind, aga lahkuv StartSSL ja saabunud Let’s Encrypt on ka ses osas palju muutunud ja põhjust oma allkirjastatud sertifikaatide kasutusele võtuks selle võrra vähem.

DNSSECil on endiselt palju arenguruumi. DNSSECi “nohikud” on pikalt tegelenud nn killer rakenduse otsimisega, mis aitaks DNSSECi massidesse viia. DANE on just üks sellistest lahendustest. Sarnaselt sellele saaks ehk lahendada ka e-posti krüpteerimise - lavale astub S/MIME. Selle toimimiseks on vajalik sertifikaatide eelnev vahetus. Rahvale demonsteeriti MS Outlooki pistikprogrammi, mis kasutab ära LDAPi ja võimaldab Outlookil teostada sertifikaadi valideeriimist üle DNSi. Et Outlook kontrollib sertifikaati ka juursertifikaadi hoidlast, siis oma allkirjastatud sertifikaadid siin ilma lisa trikkideta ei tööta.

Tšehhid otsivad head lahendust DNSSEC halduse täielikuks automatiseerimiseks oma registrilahenduses FRED. Mure on siin KSK võtmete vahetusega, mis on täna veel suuresti käsitöö. RFC7433 tegeleb selle küsimusega. Esimese lahendusega tuli oktoobri alguses välja ISC oma BIND 9.11 versioonis. Nõrk koht selles ahelas on registripidaja, kelle motivatsioon DNSSECiga tegeleda on piiratud. Seepärast otsivad registrid alternatiivseid lahendusi. Koostöös Cloudflarega on Kanada register välja töötanud lahenduse, mis võimaldab nimeserveri teenuse pakkujal, olemata ise registripidaja, suhelda registriga tehnilise kontakti rollis üle EPP otse. Sellel lahendusel on ka DNSSECi automatiseerimise kontekstis oma roll.

Teen siia väikese mõttepausi ja jätkan ICANN 57 asjadega järgmises postituses.