Uudised, sündmused ja blogi

Töötavat süsteemi ei torgita - bull... ehk Teh31 osa 1

Loodetavasti keegi ei solvunud selle arendajate nalja peale. Seekordsel kohtumisel põhjendati vajadust CENTRi liikmemaksu tõstmiseks, Tšehhid müüsid oma registrisüsteemi, prantslased ja rootslased promosid oma koos arendatavat DNS tsooni testimise lahendust, räägiti IANA tulevikust, puudutati DNS-OARCi olemust, heideti valgust septembris Prantsusmaa registris kogetud DoS rünnakule ja nagu juba reklaamitud tutvustati seda, kuidas peaks Sakslaste arvates tarkvara uuendamist haldama.

Hiljuti teatatud CENTRi liikmemaksu tõusmise taustal oli päeva esimene ettekanneCENTRi töögruppide arendamisest veidi kentsakas. Kui muidu võiks vaadata ettekannet sellest, kuidas töögruppide kohtumiste arv, pikkus ja osavõtt on kasvanud samal ajal kui CENTRi meeskond on vähenenud suurepärase näitena efektiivsuse kasvust, siis nüüd kõlas see otsitud põhjendusena. Samal ajal tekkis vaadates planeeritavaid muudatusi hirm, et bürokraatiat tuleb juurde ning ise organiseeruv, dünaamiline ja vaba õhkkond, mis on valitsenud vähemalt tehnilises töögrupis, on ohus - märksõnad nagu SLA. CENTRi vastus kommentaarile oli, et SLA on suunatud sekretariaadile mitte vabatahtlikele töögrupi vedajatele, märkides näiteks kui kiiresti peale üritusi märkmed/kokkuvõtted peaksid avalikuks saama. Registrid igatahes jälgivad nüüd pingsalt kuidas seda kõike ellu viima hakatakse.

.ee registrisüsteemina kasutame täna Tšehhi registri arendatud vabavaralist süsteemi FRED (Free Registry for ENUM and Domains). Samas alustasime sel aastal oma enda registrisüsteemi arendust, mis vastaks paremini meie ootustele ja nägemusele hästi toimivast lahendusest. Täna on maailmas tuntud kaks vabavaralist domeeniregistritele ja registripidajatele mõeldud süsteemi  - FRED ja CoCCa. Varsti lisandub sellesse nimustesse loodetavasti ka meie lahendus. Seni on aga põnev jälgida, kuhu olemas olevad liiguvad. FREDi puhul on uudisteks registrilukk koos selle haldamiseks mõeldud veebiliidesega, kontaktandmete valideerimine nii süntaktilise kui registritepõhise kontrolli näol, täiendavad võimalused domeenide administratiivseks blokeerimiseks näiteks politsei või kohtu korraldusel. Suurim uuendus on aga RDAP ehk uue põlvkonna WHOIS teenus, millel on muuhulgas masinloetav väljund, kasutajaõiguste haldus ja rahvusvaheliste tähemärkide tugi.

Taas oli jutuks suvel Pariisis esitletud Prantsuse ja Rootsi registrite koostööna arendatav domeeni tsooni testimise vabavaraline tööriist Zonemaster (vt postitust CENTR Jamboree 14: tehniline töörühm). Positiivse uudisena minu jaoks võimaldab Zonemaster kontrollida ka veel avalikustamata ehk kohalikku tsoonifaili - selle lisame ilmselt ka oma registrisüsteemi. Algne eesmärk oktoobris juba esimese stabiilse versiooniga välja tulla ei täitunud oodatust suurema töömahu tõttu, alfa versiooni võib siiski novembris oodata. Üheks ajakulu allikaks on osutunud puuduvad nõuded DNSi testidele, mille kirjeldamisega Zonemasteri meeskond nüüd tegelema hakata soovib. Ellu kutsutakse töögrupp eesmärgiga koostada IETFi BCP (Best Current Practice) tüüpi suuniste dokument, mille järgi kõik teised, kes soovivad sarnaseid testimise lahendusi arendada, saaksid joonduda või millest lähtuda. Eelnevalt on pöördutud ka IETFi ja ICANNi vastavate kanalite poole, kuid need on osutunud liiga aeglaseks ja ilmselt ei saada seal ka hästi aru selle vajadusest. Üks asi on standardtestide ja -tulemuste defineerimine, mis soovitavad asju lahendada ühel konkreetsel viisil, kuid puudu on ka selgitustest - miks soovitatakse just sellist lahendust kui asi võib töötada ka teisiti; mis on tagajärg kui ei tehta asja nii nagu standard soovitab.

ICANNi tehniliste teenuste juhi Kim Davise esitlusest aktuaalsetest teemadest IANAstooks välja ehk vaid juurtsooni tippdomeenide kontaktide mudeli muudatuse mõtte. Täna on tippdomeenidel sarnaselt madalama astme domeenidega nõutud lisaks domeeni haldavale organisatsioonile ka haldus ja tehniline kontakt, kusjuures riigitunnusega tippdomeenide puhul on nõutud, et halduskontakt peab olema kohalik ehk riigist kuhu domeen on suunatud. Iga muudatuse, mida soovitakse domeeni andmetes teha, peavad kinnitama nii haldus- kui tehniline kontakt. Selle eesmärk on ristkontroll vigade ja soovimatute muutuste vältimiseks. Nüüd on aga IANA meeskond leidnud, et tulemus võiks olla parem kui lisada domeenidele täiendav kontaktitüüp, mis vabastaks teised kaks muudatuste autoriseerimisest. Miks on aga seal juures vajalik säilitada mõlemad olemas olevad kontakti tüübid jäi mulle arusaamatuks - minu arvates oleks lihtsam ja elegantsem jätkata kahe kontaktiga, millest üks on muudatusi teostav halduskontakt ning teine neid kinnitav autoriseeriv kontakt. Loodetavasti sain selles küsimuses anda omapoolse panuse IANA arengusse ja tulevikus näeme siiski jätkuvalt kaht kontaktitüüpi tippdomeeni kohta.

Septembri alguses tabas Prantsuse domeeniregistrit rünne, mida tähistatakse koodnimega dafa888.wf domeeni järgi, mida selleks kasutati. Senini on selgusetu nii ründaja, ründe eesmärk kui ka meetod. Registri jaoks oli see selgelt DoS ehk teenusetõkestamise rünne, kuid sama hästi võis see olla Kaminsky ründe moodi üritus, mis lihtsalt väljendus võib-olla ka ootamatult sellisena. .wf on Prantsuse domeeni registri (Afnic) poolt hallatav Wallise ja Futuna saarte tippdomeen. Rünne avaldus lahendavate nimeserverite poolt tuleva suure koormusega Afnici nimeserveritele - umbes 60 tuhat päringut sekundis. Päringute joaks genereeriti juhuslikke kolmanda taseme domeene. Et teise taseme domeeni omaniku andmed registris olid selgelt valed, otsustati esimese sammuna domeen tsoonist eemaldada, et nii leevendada koormust serveritele. Kuid ootamatult koormus hoopis tõusis 100 tuhande päringuni. Olgu öeldud, et nagu EISis nii on ka Prantusmaa registris tsoonifaili uuendamise intervall 10 minutit, mis võimaldab selliseid samme suhteliselt kiiresti teostada. Koormuse kasv ongi selle ründe puhul tegelik mõistatus, sest lahendavad nimeserverid peaksid mitteeksisteeriva domeeni vastuse salvestama vahemällu ja järgmisele päringule andma vastuse sealt. Et valdav koormus tuli Google lahendavatest nimeserveritest, siis võib arvata, et seadistuse veaga tegemist ei olnud, seega sunniti lahendav nimeserver valesti käituma. Google enda kommentaar seni veel puudub, kuid ehk kasutati ära mõnda viga nimeserveri tarkvaras. Tagantjärele tarkusena tõid prantslased välja aga, et domeenide blokeerimine sellises olukorras ei tohiks olla esimene samm, sest lõikab ära võimaluse rünnet analüüsida. Siin saadi rünne seisma kui paluti Googlel oma nimeserverites konkreetne domeen musta nimekirja lisada. Lahtiseid küsimusi on palju ja tuleb tõdeda et DoS tüüpi rünnete vastu pole tänaseni lahendust, ning oma kogemuste jagamine on siin kõigile abiks.

Tõmban siin joone vahele ja jätkan ülevaadet seekordsel CENTRi tehnilisel töögrupil kuuldust, mõeldust ja räägitust järgmises postituses.