Līdz šim domēna īpašnieku varēja atrast, iz­man­to­jot Whois pa­kal­po­ju­mus, kas balstās uz tāda paša nosaukuma protokolu. Tomēr 2015. gadā IETF un ICANN pieņēma pirmo RFC dokumentu par RDAP (Re­gis­tra­tion Data Access Protocol) protokolu, kas kļuva par galveno Whois pēcteci.

Kas ir re­ģis­trā­ci­jas datu piekļuves protokols (RDAP)?

Re­ģis­trā­ci­jas datu piekļuves protokola (RDAP) kon­cep­ci­ja tika iz­strā­dā­ta Interneta in­že­nie­ri­jas darba grupas (IETF) darba grupā. Pēc gandrīz četrus gadus ilga projekta posma 2016. gada 26. jūlijā tika publicēta protokola profila pirmā versija (1.0). Tās īpašības un lietojumi ir ap­rak­stī­ti dažādos komentāru pie­pra­sī­ju­mos (RFC 7480–7484 un RFC 8056). RDAP piedāvā iespēju piekļūt papildu in­for­mā­ci­jai par pamata interneta resursiem, tostarp

  • Domēnu vārdi
  • IP adreses vai
  • Autonomo sistēmu numuri (ASN)

kā arī citus saistītus rakstus. Tāpēc Whois al­ter­na­tī­va nodrošina pamatu pie­pra­sī­ju­mu no­sū­tī­ša­nai dažādiem domēnu re­ģis­triem. Tas ietver, piemēram, jūsu datu bāzes pa­pil­di­nā­ša­nu ar domēnu īpašnieku kon­tak­tin­for­mā­ci­ju, jebkuru ad­mi­nis­tra­to­ru (Admin C) kon­tak­tin­for­mā­ci­ju vai pat izmantotā nosaukuma servera adresi, ieskaitot ad­mi­nis­tra­to­ra adresi.

Kāpēc tika iz­strā­dā­ta RDAP?

Jau 1982. gadā IETF publicēja Whois protokolu, lai izveidotu pie­pra­sī­ju­mu apstrādes pa­kal­po­ju­mu tīklam, ko tolaik sauca par ARPANET. Fakts, ka ce­tur­tdaļ­gad­sim­tu vēlāk tas joprojām tiek izmantots — tagad tiešsais­tes pie­pra­sī­ju­mu apstrādei —, daudziem ek­sper­tiem ir bijis kā dadzis acī. Mūsdienās galvenā kritika, kas vērsta pret Whois, ir tāda, ka tas vairs neatbilst interneta teh­nis­ka­jām prasībām.

Viena no gal­ve­na­jām problēmām ir tā, ka Whois protokols nespēj apstrādāt kodējumus un tādēļ ne­at­bal­sta tekstu, kas nav latīņu alfabētā. Vēl viens būtisks trūkums ir tas, ka piekļuve domēna datiem nenotiek caur drošu sa­vie­no­ju­mu un nav regulēta. Pat anonīmiem lie­to­tā­jiem ir pilnīga piekļuve, un viņi var iegūt e-pasta un pasta adreses.

Tādi projekti kā Whois++ pa­pla­ši­nā­jums vai IRIS (Internet Registry In­for­ma­tion Service) Denic protokols spēja no­dro­ši­nāt dažus uz­la­bo­ju­mus, taču tiem neizdevās no­stip­ri­nā­ties kā stabilai al­ter­na­tī­vai Whois. Pēc ilga laika un daudzām dis­ku­si­jām ICANN kopienā par ne­pie­cie­ša­mī­bu turpinātattīstību**, Drošības un sta­bi­li­tā­tes kon­sul­ta­tī­vā komiteja (SSAC) ar savu drošības ziņojumu SAC 501 deva izšķirošo impulsu, lai 2011. gada septembrī izveidotu RDAP darba grupu.

2023. gada janvārī ICANN uzsāka globālu balsojumu, lai lemtu, vai oficiāli aizstāt WHOIS ar RDAP. Tika sasniegts ne­pie­cie­ša­mais balsu skaits, un tika pieņemts lēmums oficiāli ieviest pāreju uz RDAP. No 2025. gada janvāra DNS re­ģis­triem un re­ģis­tra­to­riem vairs nebūs jā­at­bal­sta WHOIS.

Kā darbojas RDAP?

Lai ieviestu RDAP, ir svarīgi vispirms izprast, kā protokols darbojas gan klienta, gan servera pusē. Šim nolūkam ir vērts ie­pa­zī­ties ar RFC 7480–7484, kur sīki ap­rak­stī­ta protokola minimālā īs­te­no­ša­na. Turklāt ir arī citi RFC, kuros ap­rak­stī­ti RDAP protokola pa­pla­ši­nā­ju­mi. Nākamajā sadaļā mēs aptuveni iz­skaid­ro­sim, kā protokols darbojas, iz­man­to­jot HTTPS, kā ap­rak­stīts RFC 7840.

Tip

Lai at­vieg­lo­tu protokola ieviešanu iz­strā­dā­tā­jiem, ICANN ir izdevusi RDAP ie­vie­ša­nas ro­kas­grā­ma­tu.

Klienta uzdevumi:

RDAP īs­te­no­ša­na klienta pusē nav nemaz tik sarežģīta. RDAP ir balstīts uz HTTP, tāpēc datu pārraidei izmanto jau esošās HTTP metodes. Klienti var nosūtīt pie­pra­sī­ju­mus serverim, iz­man­to­jot GET un HEAD metodes. Gan GET, gan HEAD pie­pra­sī­ju­miem jāiekļauj „Accept“ galvene, kas norāda, kādus JSON failu tipus klients pieņem.

Servera uzdevumi:

Īs­te­no­ša­na servera pusē ir nedaudz sa­rež­ģī­tā­ka, jo serverim jāņem vērā vairāki īpaši gadījumi. Ja pie­pra­sī­jums ir veiksmīgs, serverim jāatgriež pie­pra­sī­tie dati pie­pra­sī­ta­jā formātā ar HTTP statusa kodu 200 (OK). Uz GET pie­pra­sī­ju­miem serverim jāatbild ar pie­pra­sī­ta­jiem īpašnieka datiem, bet uz HEAD pie­pra­sī­ju­miem jānorāda, vai tam ir pieejami dati par šo domēnu.

Ja serveris zina, kur atrodas pie­pra­sī­tie dati, bet pats tos neuzglabā, tam jāatbild ar kādu no statusa kodiem 301, 302, 303 vai 307. URL, kurā dati ir atrodami, tiek nosūtīts HTTP galvenes laukā „Location“.

Ja serveris nevar apstrādāt pie­pra­sī­ju­mu, jo pie­pra­sī­tie dati nav pieejami, tam jāatbild ar statusa kodu 404 (Not Found). Ja pie­pra­sī­tie dati pastāv, bet serveris kāda cita iemesla dēļ nevēlas atbildēt, tam jāatbild ar at­bil­sto­šu statusa kodu no 400 diapazona. Uz pie­pra­sī­ju­miem, kuros ir kļūdas un kurus tādēļ nevar uzskatīt par RDAP pie­pra­sī­ju­miem, jāatbild ar statusa kodu 400 (Bad Request). Šajā gadījumā papildu in­for­mā­ci­ju var nosūtīt HTTP vienības ķermenī.

Sīkāku in­for­mā­ci­ju par šo procesu, kā arī par protokola drošību un pa­pla­ši­nā­ša­nas iespējām varat atrast at­tie­cī­ga­jos RFC do­ku­men­tos. Saites uz tiem ir norādītas zemāk.

Ar ko re­ģis­trā­ci­jas datu piekļuves protokols atšķiras no citiem?

Daudzos aspektos RDAP ir iz­rā­dī­jies uzlabota Whois versija. IETF darba grupa ir pie­vēr­su­sies vecā protokola trūkumiem, kas nozīmē, ka, iz­strā­dā­jot jauno vaicājumu protokolu, tā ir īpaši kon­cen­trē­ju­sies uz tādām jomām kā drošība, struktūra un in­ter­na­cio­na­li­zā­ci­ja. Rezultātā ir radītas vairākas jaunas funkcijas, tostarp:

  • Struk­tu­rē­ta pie­pra­sī­ju­mu un atbilžu semantika (ieskaitot stan­dar­ti­zē­tus kļūdu ziņojumus)
  • Droša piekļuve pie­pra­sī­ta­jai kon­tak­tin­for­mā­ci­jai (piem., iz­man­to­jot HTTPS)
  • Pa­pla­ši­nā­mī­ba (piemēram, izvades elementu pie­vie­no­ša­na)
  • **„Bootstrap­ping”**mehānisms (ko atbalsta piemērota au­to­ri­ta­tī­va DNS servera meklēšana)
  • Stan­dar­ti­zē­ta pie­pra­sī­ju­mu pār­sū­tī­ša­na
  • Tīmekļa (HTTP) un REST saderīgs
  • Vienkārša izvades datu tulkošana
  • Iespēja piešķirt di­fe­ren­cē­tu piekļuvi kon­tak­tin­for­mā­ci­jai

Daudzos aspektos Re­ģis­trā­ci­jas datu piekļuves protokols (RDAP) ir pie­rā­dī­jis, ka ir daudz elas­tī­gāks nekā tā priekš­gā­jējs. Kamēr Whois kā teksta protokols balstās uz TCP un konkrētu TCP portu (43), RDAP izmanto tīmekļa standartu HTTP vai pat HTTPS. Tas nozīmē, ka visi dati tiek nosūtīti stan­dar­ti­zē­tā, datoram lasāmā JSON formātā. Tas nozīmē, ka, no vienas puses, RDAP nodrošina lielāku brīvību datu pie­pra­sī­ju­mu veikšanā, vien­lai­kus at­vieg­lo­jot tādu pie­pra­sī­ju­mu pa­kal­po­ju­mu prog­ram­mē­ša­nu, kas var sa­zi­nā­ties ar dažādām re­ģis­trā­ci­jas iestādēm, vien­lai­kus izvadot pie­pra­sī­tos datus dažādās valodās.

RDAP Whois
HTTP balstīts teksta
Stan­dar­ti­zēts JSON formāts Nav kodēšanas shēmu
Izvades dati ir ma­šīnla­sā­mi un tos var viegli tulkot Izvades dati ir vienkāršā formātā, tāpēc tos nevar turpmāk apstrādāt au­to­mā­tis­ki
Atbildes tiek au­to­mā­tis­ki nosūtītas uz citiem re­ģis­triem Atbildēs nav iekļauta in­for­mā­ci­ja par turpmāko reģistru
Ir iespējams definēt piekļuves tiesības dažādām grupām Nav iespējams dažāda veida piekļuve datiem

Iespējas dažādiem piekļuves veidiem – joprojām diskusiju temats

Ne­ap­šau­bā­mi viena no sva­rī­gā­ka­jām jaunajām funkcijām, kas tika ieviesta re­ģis­trā­ci­jas datu piekļuves protokolā, ir iespēja noteikt at­šķi­rī­gas piekļuves tiesības at­se­viš­ķām lietotāju grupām. Tas ļauj re­ģis­tra­to­ram sīki regulēt, kam ir tiesības apskatīt konkrētu in­for­mā­ci­ju. Tādējādi anonīmiem lie­to­tā­jiem tiek no­dro­ši­nā­ta tikai ie­ro­be­žo­ta piekļuve, savukārt au­to­ri­zē­tiem lie­to­tā­jiem ir pieejams viss datu kopums. Šis ir aspekts, kurā daudzi uzskata, ka ir ne­pie­cie­ša­mi būtiski pre­ci­zē­ju­mi.

Viens no jau­tā­ju­miem, kas šajā sakarā rodas, cita starpā ir tas, kā rīkoties ar kri­mi­nāl­va­jā­ša­nas iestāžu pār­stāv­jiem, kuri vēlas saglabāt ano­ni­mi­tā­ti, vien­lai­kus baudot pilnīgas piekļuves tiesības. Turklāt nav nekādu vadlīniju par to, vai šādā gadījumā piekļuve domēna datiem var tikt piešķirta arī personām, kas atrodas ārpus valsts robežām. Pirmkārt, prio­ri­tā­te ir lietotāju datu aiz­sar­dzī­ba un ar to saistītā uz­ti­cē­ša­nās tīmekļa vietnes ope­ra­to­ram, kurš reģistrē domēnu. Un nekādā gadījumā šī uz­ti­cē­ša­nās nedrīkst tikt ap­drau­dē­ta ar jauno RDAP pie­pra­sī­ju­mu teh­no­lo­ģi­ju. 2016. gada beigās vairāki reģistri pār­sū­dzē­ja ICANN noteikto ie­vie­ša­nas termiņu, un tas nozīmē, ka or­ga­ni­zā­ci­ja ir nolēmusi noslēgt līgumus par RDAP ar re­ģis­tra­to­riem un domēnu pa­kal­po­ju­mu snie­dzē­jiem.

Go to Main Menu