Kas yra re­gist­ra­ci­jos duomenų prieigos pro­to­ko­las (RDAP)?

Iki šiol domeno savininką buvo galima rasti nau­do­jan­tis „Whois“ pa­slau­go­mis, kurios veikia pagal to paties pa­va­di­ni­mo protokolą. Tačiau 2015 m. IETF ir ICANN priėmė pirmąjį RDAP (Re­gist­ra­tion Data Access Protocol) protokolo RFC dokumentą, kuris tapo pag­rin­di­niu „Whois“ pakaitalu.

Kas yra re­gist­ra­ci­jos duomenų prieigos pro­to­ko­las (RDAP)?

Re­gist­ra­ci­jos duomenų prieigos protokolo (RDAP) kon­cep­ci­ja buvo sukurta Interneto in­ži­ne­ri­jos darbo grupės (IETF) darbo grupės. Po beveik ketverių metų trukusio projekto etapo, 2016 m. liepos 26 d. pasirodė pirmoji protokolo profilio versija (1.0). Jos cha­rak­te­ris­ti­kos ir taikymo sritys aprašytos įvai­riuo­se pra­šy­muo­se pateikti ko­men­ta­rus (RFC 7480–7484 ir RFC 8056). RDAP suteikia galimybę gauti daugiau in­for­ma­ci­jos apie pag­rin­di­nius interneto išteklius, įskaitant

• Domenų vardai
• IP adresai arba
• Au­to­no­mi­nių sistemų numeriai (ASN)

taip pat ir kitus su­si­ju­sius straips­nius. Dėl šios prie­žas­ties „Whois“ al­ter­na­ty­va sudaro pagrindą užklausų siuntimui į įvairius domenų registrus. Tai apima, pa­vyz­džiui, jūsų duomenų bazės papildymą domenų savininkų kon­tak­ti­niais duo­me­ni­mis, bet kokių ad­mi­nist­ra­to­rių (Admin C) kon­tak­ti­niais duo­me­ni­mis ar net naudojamo vardų serverio adresu, įskaitant ir ad­mi­nist­ra­to­riaus adresą.

Kodėl buvo sukurta RDAP?

Dar 1982 m. IETF paskelbė „Whois“ protokolą, siekdama sukurti užklausų ap­tar­na­vi­mo paslaugą tuo metu vadintam „ARPANET“. Tai, kad praėjus ket­vir­čiui amžiaus jis vis dar nau­do­ja­mas – dabar in­ter­ne­ti­nėms už­klau­soms – daugeliui ekspertų yra tikras galvos skausmas. Šiandien pag­rin­di­nė „Whois“ adresuota kritika yra ta, kad jis ne­be­ati­tin­ka interneto techninių rei­ka­la­vi­mų.

Viena iš pag­rin­di­nių problemų yra ta, kad „Whois“ pro­to­ko­las nepalaiko kodavimo, todėl nepalaiko ne lotynų raš­me­ni­mis parašyto teksto. Kitas didelis trūkumas yra tai, kad prieiga prie domeno duomenų vyksta ne per saugų ryšį ir nėra re­gu­liuo­ja­ma. Net ano­ni­mi­niai var­to­to­jai gauna visišką prieigą ir gali gauti elekt­ro­ni­nio pašto bei pašto adresus.

Tokie projektai kaip „Whois++“ plėtinys ar „IRIS“ (Internet Registry In­for­ma­tion Service) „Denic“ pro­to­ko­las leido įgy­ven­din­ti tam tikrus pa­to­bu­li­ni­mus, tačiau jiems nepavyko įsi­tvir­tin­ti kaip rimtai „Whois“ al­ter­na­ty­vai. Po ilgos per­trau­kos ir daugybės diskusijų ICANN bend­ruo­me­nė­je dėl tolesnioplėtojimo būtinybės**, Saugumo ir stabilumo pa­ta­ria­mo­ji komitetas (SSAC) savo saugumo ataskaita SAC 501 suteikė lemiamą postūmį RDAP darbo grupės įkūrimui 2011 m. rugsėjo mėn.

2023 m. sausio mėn. ICANN pradėjo visuotinį balsavimą, kurio tikslas – nuspręsti, ar ofi­cia­liai pakeisti WHOIS į RDAP. Buvo surinkta rei­ka­lin­ga balsų skaičius, todėl buvo nuspręsta ofi­cia­liai įgy­ven­din­ti perėjimą prie RDAP. Nuo 2025 m. sausio mėn. DNS registrai ir re­gist­ra­to­riai nebeturės pareigos palaikyti WHOIS.

Kaip veikia RDAP?

Norint įgy­ven­din­ti RDAP, svarbu pir­miau­sia suprasti, kaip šis pro­to­ko­las veikia tiek kliento, tiek serverio pusėje. Tam verta su­si­pa­žin­ti su RFC 7480–7484, kuriuose išsamiai aprašyta minimali protokolo įgy­ven­di­ni­mo versija. Be to, yra ir kitų RFC, kuriuose aprašyti RDAP protokolo iš­plė­ti­mai. Toliau pa­teik­ta­me skyriuje trumpai pa­aiš­ki­na­me, kaip pro­to­ko­las veikia per HTTPS, kaip aprašyta RFC 7840.

Kliento užduotys:

RDAP įdiegimas kliento pusėje visai nėra su­dė­tin­gas. RDAP yra sukurtas HTTP pagrindu, todėl duomenims perduoti naudoja jau esamus HTTP metodus. Klientai gali siųsti užklausas serveriui naudodami GET ir HEAD metodus. Tiek GET, tiek HEAD už­klau­so­se turėtų būti įtrauktas „Accept“ antraštė, nurodanti, kokių tipų JSON failus klientas priima.

Serverio užduotys:

Įgy­ven­di­ni­mas serverio pusėje yra šiek tiek su­dė­tin­ges­nis, nes serveris turi numatyti nemažai specialių atvejų. Jei užklausa įvykdoma sėkmingai, serveris turėtų grąžinti prašomus duomenis prašomu formatu su HTTP būsenos kodu 200 (OK). At­sa­ky­da­mas į GET užklausas, serveris turėtų pateikti prašomus savininko duomenis, o at­sa­ky­da­mas į HEAD užklausas – nurodyti, ar turi duomenų apie šį domeną.

Jei serveris žino, kur yra prašomi duomenys, bet pats jų neturi, jis turėtų atsakyti vienu iš būsenos kodų: 301, 302, 303 arba 307. Tuomet URL adresas, kuriuo galima rasti duomenis, per­duo­da­mas HTTP ant­raš­tė­je „Location“.

Jei serveris negali apdoroti užklausos, nes prašomų duomenų nėra, jis turėtų atsakyti statuso kodu 404 (Not Found). Jei prašomi duomenys eg­zis­tuo­ja, bet serveris dėl kokios nors kitos prie­žas­ties nenori atsakyti, jis turėtų atsakyti ati­tin­ka­mu statuso kodu iš 400 serijos. Į užklausas, kuriose yra klaidų ir kurios dėl to negali būti trak­tuo­ja­mos kaip RDAP užklausos, turėtų būti atsakoma statuso kodu 400 (Bad Request). Šiuo atveju papildoma in­for­ma­ci­ja gali būti siunčiama HTTP objekto tekste.

Iš­sa­mes­nės in­for­ma­ci­jos apie šį procesą, taip pat apie protokolo saugumą ir išplėtimo galimybes rasite ati­tin­ka­muo­se RFC do­ku­men­tuo­se. Nuorodos į juos pateiktos žemiau.

• RFC 7840: HTTP nau­do­ji­mas
• RFC 7841: Saugumo paslaugos
• RFC 7842: Užklausos formatas
• RFC 7843: JSON atsakymai
• RFC 7844: Patikimų re­gist­ra­ci­jos duomenų paieška

Kuom skiriasi Re­gist­ra­ci­jos duomenų prieigos pro­to­ko­las?

Daugeliu atžvilgių RDAP pasirodė esąs pa­to­bu­lin­ta „Whois“ versija. IETF darbo grupė sutelkė dėmesį į senojo protokolo trūkumus, o tai reiškia, kad kuriant naują užklausų protokolą didelis dėmesys buvo skiriamas saugumui, struk­tū­rai ir in­ter­na­cio­na­li­za­vi­mui. Dėl to atsirado keletas naujų funkcijų, tarp kurių:

• Struk­tū­ri­zuo­ta užklausų ir atsakymų semantika (įskaitant stan­dar­ti­zuo­tus klaidų pra­ne­ši­mus)
• Saugi prieiga prie prašomų kon­tak­ti­nių duomenų (pvz., per HTTPS)
• Išplėtimo galimybės (pvz., išvesties elementų pri­dė­ji­mas)
• **„Bo­ot­st­rap­ping“**me­cha­niz­mas (remiamas tinkamo au­to­ri­ta­ty­vaus DNS serverio paieška)
• Stan­dar­ti­zuo­tas užklausų per­siun­ti­mas
• Veikia ži­nia­tinkly­je (HTTP) ir atitinka REST standartą
• Paprastas išvesties duomenų vertimas
• Galimybė suteikti di­fe­ren­ci­juo­tą prieigą prie kon­tak­ti­nių duomenų

Daugeliu atžvilgių Re­gist­ra­vi­mo duomenų prieigos pro­to­ko­las pasirodė esąs kur kas lanks­tes­nis nei jo pirmtakas. Nors „Whois“, kaip tekstinis pro­to­ko­las, remiasi TCP ir konkrečiu TCP prievadu (43), RDAP naudoja in­ter­ne­ti­nį standartą HTTP arba net HTTPS. Tai reiškia, kad visi duomenys pa­tei­kia­mi stan­dar­ti­zuo­tu, kom­piu­te­riui su­pran­ta­mu JSON formatu. Tai reiškia, kad, viena vertus, RDAP suteikia daugiau laisvės duomenų užklausų atžvilgiu, o kita vertus, pa­leng­vi­na užklausų paslaugų, galinčių bendrauti su įvai­rio­mis re­gist­ra­ci­jos ins­ti­tu­ci­jo­mis, prog­ra­ma­vi­mą, tuo pačiu pa­tei­kiant prašomus duomenis įvai­rio­mis kalbomis.

Galimybė rinktis iš įvairių prieigos būdų – vis dar diskusijų tema

Be abejonės, viena iš svar­biau­sių naujų funkcijų, įdiegtų Re­gist­ra­vi­mo duomenų prieigos protokole, yra galimybė nustatyti skir­tin­gas prieigos teises atskiroms vartotojų grupėms. Tai leidžia re­gist­ra­to­riui tiksliai re­gu­liuo­ti, kas gali matyti kokią in­for­ma­ci­ją. Dėl to ano­ni­mi­niai var­to­to­jai turi tik ribotą prieigą, o įgalioti var­to­to­jai gali per­žiū­rė­ti visą duomenų rinkinį. Tai aspektas, dėl kurio daugelis mano, kad būtina nustatyti aiškius rei­ka­la­vi­mus.

Vienas iš kylančių klausimų, be kitų, yra tai, kaip elgtis su bau­džia­mų­jų bylų pro­ku­ro­rais, kurie nori išlikti ano­ni­mi­niai, tačiau tuo pačiu metu naudotis visomis prieigos teisėmis. Be to, nėra jokių gairių, ar tokiu atveju prieiga prie domeno duomenų gali būti suteikta ir asmenims, esantiems už šalies ribų. Svar­biau­sia yra vartotojų duomenų apsauga ir pa­si­ti­kė­ji­mas svetainės ope­ra­to­riu­mi, kuris re­gist­ruo­ja domeną. Ir jokiu būdu šis pa­si­ti­kė­ji­mas neturėtų būti pažeistas dėl naujos RDAP užklausų tech­no­lo­gi­jos. 2016 m. pabaigoje keletas registrų pateikė ape­lia­ci­ją dėl ICANN nustatyto įgy­ven­di­ni­mo lai­ko­tar­pio, o tai reiškia, kad or­ga­ni­za­ci­ja nusprendė sudaryti RDAP sutartis su re­gist­ra­to­riais ir domenų teikėjais.