# Kas yra registracijos duomenų prieigos protokolas (RDAP)? Iki šiol domeno savininką buvo galima rasti naudojantis [„Whois“ paslaugomis](https://www.ionos.co.uk/tools/whois-domain-lookup "Whois Domain Lookup from IONOS"), kurios veikia pagal to paties pavadinimo protokolą. Tačiau 2015 m. IETF ir ICANN priėmė pirmąjį **RDAP (Registration Data Access Protocol)** protokolo RFC dokumentą, kuris tapo pagrindiniu „Whois“ pakaitalu. ## Kas yra registracijos duomenų prieigos protokolas (RDAP)? Registracijos duomenų prieigos protokolo (RDAP) koncepcija buvo sukurta Interneto inžinerijos 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 charakteristikos ir taikymo sritys aprašytos įvairiuose **prašymuose pateikti komentarus (RFC 7480–7484 ir RFC 8056)**. RDAP suteikia galimybę gauti daugiau informacijos apie pagrindinius interneto išteklius, įskaitant - **Domenų vardai** - **IP adresai** arba - **Autonominių sistemų numeriai** (ASN) taip pat ir kitus susijusius straipsnius. Dėl šios priežasties „Whois“ alternatyva sudaro pagrindą užklausų siuntimui į įvairius **domenų registrus**. Tai apima, pavyzdžiui, jūsų **duomenų bazės** papildymą domenų savininkų kontaktiniais duomenimis, bet kokių administratorių (Admin C) kontaktiniais duomenimis ar net naudojamo vardų serverio adresu, įskaitant ir administratoriaus adresą. ## Kodėl buvo sukurta RDAP? Dar 1982 m. IETF paskelbė „Whois“ protokolą, siekdama sukurti užklausų aptarnavimo paslaugą tuo metu vadintam „ARPANET“. Tai, kad praėjus ketvirčiui amžiaus jis vis dar naudojamas – dabar internetinėms užklausoms – daugeliui ekspertų yra tikras galvos skausmas. Šiandien pagrindinė „Whois“ adresuota kritika yra ta, kad jis nebeatitinka interneto **techninių reikalavimų**. Viena iš pagrindinių problemų yra ta, kad „Whois“ protokolas nepalaiko kodavimo, todėl **nepalaiko ne lotynų rašmenimis parašyto teksto**. Kitas didelis trūkumas yra tai, kad prieiga prie domeno duomenų vyksta ne per saugų ryšį ir nėra **reguliuojama**. Net anoniminiai vartotojai gauna visišką prieigą ir gali gauti elektroninio pašto bei pašto adresus. Tokie projektai kaip „Whois++“ plėtinys ar „IRIS“ (Internet Registry Information Service) „Denic“ protokolas leido įgyvendinti tam tikrus patobulinimus, tačiau jiems nepavyko įsitvirtinti kaip rimtai „Whois“ alternatyvai. Po ilgos pertraukos ir daugybės diskusijų **ICANN bendruomenėje dėl tolesnio**plėtojimo **būtinybės\*\***, Saugumo ir stabilumo patariamoji komitetas (SSAC) savo [saugumo ataskaita SAC 501](https://www.icann.org/en/system/files/files/sac-051-en.pdf "ICANN Report on Domain Name Whois Terminology and Structure") 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 oficialiai pakeisti WHOIS į RDAP. Buvo surinkta reikalinga balsų skaičius, todėl buvo nuspręsta oficialiai įgyvendinti perėjimą prie RDAP. Nuo 2025 m. sausio mėn. DNS registrai ir registratoriai nebeturės pareigos palaikyti WHOIS. ## Kaip veikia RDAP? Norint įgyvendinti RDAP, svarbu pirmiausia suprasti, kaip šis protokolas veikia tiek kliento, tiek serverio pusėje. Tam verta susipažinti su RFC 7480–7484, kuriuose išsamiai aprašyta minimali protokolo įgyvendinimo versija. Be to, yra ir kitų RFC, kuriuose aprašyti RDAP protokolo išplėtimai. Toliau pateiktame skyriuje trumpai paaiškiname, kaip protokolas veikia per HTTPS, kaip aprašyta [RFC 7840](https://datatracker.ietf.org/doc/html/rfc7480 "RFC 7840: HTTP Usage in the Registration Data Access Protocol (RDAP)"). Tip Siekiant palengvinti protokolo diegimą kūrėjams, ICANN parengė [RDAP diegimo vadovą](https://www.icann.org/en/system/files/files/rdap-technical-implementation-guide-15feb19-en.pdf "ICANN RDAP Technical Implementation Guide"). **Kliento užduotys:** RDAP įdiegimas kliento pusėje visai nėra sudėtingas. 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žklausose turėtų būti įtrauktas „Accept“ antraštė, nurodanti, kokių tipų JSON failus klientas priima. **Serverio užduotys:** Įgyvendinimas serverio pusėje yra šiek tiek sudėtingesnis, 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). Atsakydamas į GET užklausas, serveris turėtų pateikti prašomus savininko duomenis, o atsakydamas į 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, perduodamas HTTP antraš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 egzistuoja, bet serveris dėl kokios nors kitos priežasties nenori atsakyti, jis turėtų atsakyti atitinkamu statuso kodu iš 400 serijos. Į užklausas, kuriose yra klaidų ir kurios dėl to negali būti traktuojamos kaip RDAP užklausos, turėtų būti atsakoma statuso kodu 400 (Bad Request). Šiuo atveju papildoma informacija gali būti siunčiama HTTP objekto tekste. Išsamesnės informacijos apie šį procesą, taip pat apie protokolo saugumą ir išplėtimo galimybes rasite atitinkamuose RFC dokumentuose. Nuorodos į juos pateiktos žemiau. - [RFC 7840: HTTP naudojimas](https://datatracker.ietf.org/doc/html/rfc7480 "RFC 7840 of the IETF") - [RFC 7841: Saugumo paslaugos](https://datatracker.ietf.org/doc/html/rfc7481 "RFC 7841 of the IETF") - [RFC 7842: Užklausos formatas](https://datatracker.ietf.org/doc/html/rfc7482 "RFC 7842 of the IETF") - [RFC 7843: JSON atsakymai](https://datatracker.ietf.org/doc/html/rfc7483 "RFC 7843 of the IETF") - [RFC 7844: Patikimų registracijos duomenų paieška](https://datatracker.ietf.org/doc/html/rfc7484 "RFC 7844 of the IETF") ## Kuom skiriasi Registracijos duomenų prieigos protokolas? Daugeliu atžvilgių RDAP pasirodė esąs patobulinta „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**, **struktūrai** ir **internacionalizavimui**. Dėl to atsirado keletas naujų funkcijų, tarp kurių: - **Struktūrizuota** užklausų ir atsakymų semantika (įskaitant standartizuotus klaidų pranešimus) - **Saugi prieiga** prie prašomų kontaktinių duomenų (pvz., per HTTPS) - Išplėtimo galimybės (pvz., išvesties elementų pridėjimas) - \*\*„Bootstrapping“\*\*mechanizmas (remiamas tinkamo autoritatyvaus DNS serverio paieška) - Standartizuotas užklausų **persiuntimas** - Veikia žiniatinklyje (HTTP) ir atitinka **REST** standartą - Paprastas išvesties duomenų vertimas - Galimybė suteikti **diferencijuotą prieigą** prie kontaktinių duomenų Daugeliu atžvilgių Registravimo duomenų prieigos protokolas pasirodė esąs kur kas lankstesnis nei jo pirmtakas. Nors **„Whois“, kaip tekstinis protokolas**, remiasi TCP ir konkrečiu TCP prievadu (43), RDAP naudoja internetinį standartą HTTP arba net HTTPS. Tai reiškia, kad visi duomenys pateikiami **standartizuotu, kompiuteriui suprantamu JSON formatu**. Tai reiškia, kad, viena vertus, RDAP suteikia daugiau laisvės duomenų užklausų atžvilgiu, o kita vertus, palengvina užklausų paslaugų, galinčių bendrauti su įvairiomis registracijos institucijomis, programavimą, tuo pačiu pateikiant prašomus duomenis įvairiomis kalbomis.
RDAP Whois
HTTP pagrįstas teksto pagrindu
Standartizuotas JSON formatas Nėra kodavimo schemų
Išvesties duomenys yra kompiuteriui suprantami ir gali būti lengvai išversti Išvesties duomenys yra paprastų duomenų formatu, todėl negali būti toliau apdorojami automatiškai
Atsakymai automatiškai siunčiami į kitus registrus Atsakymai neapima tolesnės registrų informacijos
Galima nustatyti prieigos teises skirtingoms grupėms Įvairių tipų prieiga prie duomenų neįmanoma
## Galimybė rinktis iš įvairių prieigos būdų – vis dar diskusijų tema Be abejonės, viena iš svarbiausių naujų funkcijų, įdiegtų Registravimo duomenų prieigos protokole, yra galimybė nustatyti skirtingas **prieigos teises** atskiroms vartotojų grupėms. Tai leidžia registratoriui **tiksliai reguliuoti**, kas gali matyti kokią informaciją. Dėl to anoniminiai vartotojai turi tik ribotą prieigą, o įgalioti vartotojai gali peržiūrėti visą duomenų rinkinį. Tai aspektas, dėl kurio daugelis mano, kad būtina nustatyti aiškius reikalavimus. Vienas iš kylančių klausimų, be kitų, yra tai, kaip elgtis su baudžiamųjų bylų prokurorais, kurie nori išlikti anoniminiai, 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ų**. Svarbiausia yra vartotojų duomenų apsauga ir pasitikėjimas svetainės operatoriumi, kuris registruoja domeną. Ir jokiu būdu šis pasitikėjimas neturėtų būti pažeistas dėl naujos RDAP užklausų technologijos. 2016 m. pabaigoje keletas registrų pateikė apeliaciją dėl **ICANN nustatyto įgyvendinimo laikotarpio**, o **tai** reiškia, kad **organizacija** nusprendė sudaryti RDAP **sutartis** su registratoriais ir domenų teikėjais. This is a markdown version of: [https://www.ionos.com/lt-lt/digitalguide/domenai/domeno-administravimas/kas-yra-registracijos-duomenu-prieigos-protokolas-rdap/](https://www.ionos.com/lt-lt/digitalguide/domenai/domeno-administravimas/kas-yra-registracijos-duomenu-prieigos-protokolas-rdap/) for AI/LLM consumption.