30. jaanuaril kell 18.20 (Moskva aja järgi) kogesid kasutajad .RU domeenitsoonis ulatuslikku hosti lahendamise tõrget, mille põhjustas DNSSEC-i kaudu .RU tsooni kontrollimiseks kasutatavate võtmete vahetamise tõrge. Selle intsidendi tagajärjel lakkasid kõik ".ru" tsooni domeenid lahendamast DNS-serverites, mis kasutavad andmete kontrollimiseks DNSSEC-i. Probleem mõjutas ainult kasutajaid, kes kasutasid pakkuja DNS-resolvereid või avalikke DNS-teenuseid, näiteks 8.8.8.8, mis kontrollivad päringute kehtivust DNSSEC-i abil. Keelatud DNSSEC-iga DNS-resolverite kasutajaid see ei mõjutanud.
See juhtum meenutab eelmise aasta intsidenti InternetNZ-iga, mis on .NZ domeenitsooni eest vastutav registripidaja ja mis viis lahendamise tõrkeni. domeeninimed Tsoonis ".nz" tekkis intsident tsooni allkirjastamisvõtit (ZSK) sisaldavate DNSKEY kirjete digitaalseks allkirjastamiseks kasutatavate KSK (võtme allkirjastamisvõti) võtmete rotatsiooni vea tõttu. InternetNZ puhul oli viga seotud võtmevormingu muutusega registripidaja uuele infosüsteemile üleminekul. .RU tsooni intsidendi põhjust pole veel üksikasjalikult selgitatud – .RU domeeni koordineerimiskeskus on vaid üldiselt kinnitanud, et probleem on seotud DNSSEC-i ümberkonfigureerimisega.
Väliste ilmingute põhjal otsustades tekkis tõrge .RU tsooni kontrollimiseks kasutatava võtme asendamise katse tagajärjel. See võti on usalduse juurvõti teistele teise taseme domeenides kasutatavatele võtmetele ja omakorda kasutab usalduse kontrollimiseks ülemusena domeenivõtit "." (inglise keeles ".") 26. jaanuaril lisati .RU tsooni DNSEC-seadetesse lisaks primaarvõtmele ID-ga 44301 veel üks võti, 52263.
Eile umbes kell 18:20 kasutati RU-tsoonis kirjete kontrollimiseks uut võtit, kuid pärast uuele võtmele üleminekut ebaõnnestus autentimine vea tõttu.
Vana võtmega allkiri tagastati umbes kell 21.07 (Moskva aja järgi) ja esimene õige vastus registreeriti dnsviz.net poolt kell 22.07 (Moskva aja järgi). Vigased sätted püsisid umbes kaks ja pool tundi, kuid DNS-serveri vahemäludes olevate vigaste kirjete tõttu nõuab täielik taastamine lisaaega, kui rekursiivseid DNS-servereid ei sunnita kustutama. Mõned pakkujad lahendasid probleemi kiiremini ja tõhusamalt, keelates ajutiselt DNSSEC-i kontrollimise oma lahendaja sätetes.
Allikas: opennet.ru
