Uudised, sündmused ja blogi

ICANN59: poliitika - dnssec ja tech

Esimene päev möödus minu jaoks tehnilistel teemadel - sellele päevale olid kokku toodud nii DNSSECi töötuba kui TechDay ehk üldisemate tehniliste teemade arutelud. Meenutamist väärivatest teemadest märgin ära Internet Society poolt välja antud raporti DNSSECi olukorrast maailmas 2016 aasta lõpus. DNSSECi kontrollimise vaates on parimas olukorras Melaneeisa ja Ida-Aafrika piirkonnad. Põhjuseks laialt kasutatav Google DNS. Siit järeldus - mida vähem kasutatakse oma rekursiivseid nimeservereid seda kõrgem on DNSSECi valideerimise tase.

Tippdomeenidest on üle 90% DNSSECitud, samal ajal domeenidest on kaitstud veidi üle 2%. Nagu ikka jaguneb maailm ka siin kaheks - need kelle arvates peab DNSSEC olema vaikimisi standard iga domeeni jaoks ja need, kes usuvad, et seda tehnilist keerukust lisavat tehnoloogiat peab vaatama vajaduse põhiselt. Ise olen pigem selles teises “parteis”. Usun, et registrina peaksime keskenduma sellele, et Eestis oleks DNSSECi valideerimise tase kõrge ning registreerijatel piisav teadmine DNSSECist, selle eelistest ja ohtudest, et teha teadlik otsus. Samas ei saa unustada ka registreerijat, kes teaks nõuda oma finants-, kindlustus- või näiteks sideettevõttelt DNSSECi.

Üks Taani härra (Andrew McConachie) tutvustas oma kodukootud DANE valideerimise vidinat. Meeldetuletuseks - DANE on DNSSECi täiendus, mis võimaldab näiteks omatehtud TLS sertifikaatide autentsust kontrollida DNSSECi ahela abil. Samas saab seda kasutada ka eposti allkirjastamiseks ja krüpteerimiseks. DANE võiks iseenesest olla põhjus või viis kuidas DNSSEC tegelikult massidesse viia. Andrew küsis endalt, et kas tõesti seisab DANE kasutuselevõtt sirvikutootjate taga, arvestades, et paljud HTTPS seansid ei toimugi täna enam sirviku vahendusel - ja nii vidin sündiski. Äge mõte ja tubli ettevõtmine.

Kanada registri eestvedamisel jätkub töö DNS operaatorite ja registrite vahelise suhtluse standardiseerimiseks. Probleem - kuidas nimeserveri kirjete muudatused, nagu DNSSECi kirjed, jõuaksid tsooni olukorras, kus operaatoriks on kolmas osapool. Täna peab nimeserveri haldur ajama asju registripidaja või registreerija vahendusel, kuid see on aeganõudev, tihti vaevaline ja osutub probleemiks, kui registripidaja DNSSECi ei toeta. Lisaks tekib DNS operaatori ja registri vahelise otsesuhtluse korral ka küsimus, kuidas registripidaja muutustest teada saab. EPP POLL teated on siin loogiline valik. 

Kuid kuidas ikkagi DNS muudatused tsooni jõudma peaksid? EPP siin ei aita, sest see on registrite ja registripidajate spetsiifiline protokoll. Loogiline valik on DNS kirjed. Mooduseks RFC7477 ehk Child-to-Parent Synchronization in DNS. CSYNC kirjega saab DNS operaator anda märku vajalikest uuendustest. Eelduseks siin, et vastav domeen on juba DNSSECiga kaitstud. Aga kuidas toimetada esmasel DNSSECiga allkirjastamisel...

Tšehhi register on samal ajal juurutanud oma alternatiivse lahenduse. Nad skänneerivad iga päev läbi kõik oma tsoonis olevad nimeserverid ja otsivad uusi DNSSECi võtmete kirjeid. Leides, teavitavad koheselt tehnilist kontakti kavast võti .cz tsooni lisada. Kui uus võti on püsinud alamtsoonis muutumatuna 7 päeva genereerib register sellest DS kirje ja lisab automaatselt tsoonifaili, teavitades sellest ka registripidajat poll teate abil.

Tšehhide lähenemine kus kontrollitakse konkreetse aja jooksul, kas andmed püsivad muutumatult võiks olla lahendus ka CSYNC lähenemisel esmakordsele allkirjastamisele. See lahendus tõstab taas päevakorda kahe erineva AS numbriga nimeserveri omamise iga tsoonis oleva domeeni kohta - nii on automatiseeritud protseduuride korral tagatud parem kaitse domeeni kaaperdamise eest, sest kahe erineva nimeserveri üle kontrolli võtmine on palju raksem kui ühe. Seni olin veendunud, et kahe nimeserveri nõue on tänu Anycasti tulekule aegunud.

Üldtehnilistest teemadest juhtis Namiibia (.na) register, viidates oma hiljaaegu toimunud turvaintsidendile, tähelepanu tsoonifaili MNAME kirjele. MNAME viitab primaarsele ehk master nimeserverile. Tasub kontrollida, et seal toodud domeen on ka tegelikult olemas ja tsooni omanikule registreeritud, et välistada andmelekkeid ja vahemehe (MITM) ründeid. Isegi kui ei soovi seda liiklust saada mis MNAME suunas liiguvad, võib kasutada lahendamatut nime, kuid domeen peab olema registri kontrolli all. Oluline on üle vaadata nii SOA kui IN NS kirjeid.

Järgmises postituses ülevaade .est teemast.