Do sedaj je bilo mogoče lastnika domene poiskati s pomočjo storitev Whois, ki temeljijo na is­to­i­men­skem protokolu. Vendar sta or­ga­ni­za­ci­ji IETF in ICANN leta 2015 objavili prvi RFC za protokol RDAP (Re­gi­stra­ti­on Data Access Protocol), ki naj bi postal glavni naslednik protokola Whois.

Kaj je protokol za dostop do re­gi­stra­cij­skih podatkov (RDAP)?

Koncept protokola za dostop do re­gi­stra­cij­skih podatkov (RDAP) je zasnovala delovna skupina v okviru Internet En­gi­ne­e­ring Task Force (IETF). Po skoraj šti­ri­le­tni projektni fazi je 26. julija 2016 izšla prva različica profila protokola (1.0). Njegove zna­čil­no­sti in uporabe so opisane v različnih zahtevah za ko­men­tar­je (RFC 7480–7484 in RFC 8056). RDAP omogoča dostop do dodatnih in­for­ma­cij o osnovnih in­ter­ne­tnih virih, vključno z

  • Domenska imena
  • IP-naslovi ali
  • številke av­to­no­mnih sistemov (ASN)

kot tudi druge sorodne članke. Zato al­ter­na­ti­va Whois pred­sta­vlja osnovo za po­ši­lja­nje poizvedb različnim registrom domen. To vključuje za­go­ta­vlja­nje podatkov v vaši bazi, na primer kon­tak­tnih podatkov lastnikov domen, kon­tak­tnih podatkov mo­re­bi­tnih skrbnikov (Admin C) ali celo naslova upo­ra­blje­ne­ga imenskega strežnika, vključno z naslovom njegovega skrbnika.

Zakaj je bil razvit program RDAP?

Že leta 1982 je IETF objavil protokol Whois z namenom vzpo­sta­vi­tve storitve za poizvedbe v omrežju, ki se je takrat imenovalo ARPANET. Dejstvo, da se ta protokol četrt stoletja kasneje še vedno uporablja, tokrat za spletne poizvedbe, je za mnoge stro­kov­nja­ke prava trn v peti. Danes je glavna kritika, usmerjena proti Whoisu, da ne iz­pol­nju­je več tehničnih zahtev interneta.

Ena od glavnih težav je, da protokol Whois ne podpira kodiranja in zato ne omogoča pri­ka­zo­va­nja ne­la­tin­skih znakov. Druga pomembna po­manj­klji­vost je, da dostop do podatkov o domenah ne poteka prek varne povezave in ni reguliran. Tudi anonimni upo­rab­ni­ki imajo neomejen dostop in lahko pridobijo e-poštne in poštne naslove.

Projekti, kot sta raz­ši­ri­tev Whois++ ali protokol IRIS (Internet Registry In­for­ma­ti­on Service) Denic, so sicer prinesli nekaj izboljšav, vendar se niso uspeli uve­lja­vi­ti kot trdna al­ter­na­ti­va sistemu Whois. Po dolgem času in številnih razpravah znotraj skupnosti ICANN o nujnosti na­dalj­nje­garazvoja** je Sve­to­val­ni odbor za varnost in sta­bil­nost (SSAC) s svojim var­no­stnim poročilom SAC 501 dal odločilni zagon za usta­no­vi­tev delovne skupine RDAP septembra 2011.

Januarja 2023 je ICANN začel svetovno gla­so­va­nje, da bi se odločilo, ali naj se WHOIS uradno nadomesti z RDAP. Potrebno število glasov je bilo doseženo in sprejeta je bila odločitev, da se prehod na RDAP uradno uveljavi. Od januarja 2025 naprej registri DNS in re­gi­stra­tor­ji ne bodo več dolžni podpirati WHOIS.

Kako deluje RDAP?

Za im­ple­men­ta­ci­jo protokola RDAP je pomembno, da najprej razumemo, kako protokol deluje tako na strani odjemalca kot na strani strežnika. V ta namen je vredno prebrati RFC-je 7480 do 7484, kjer je podrobno opisana minimalna im­ple­men­ta­ci­ja protokola. Poleg tega obstajajo še drugi RFC-ji, v katerih so opisane raz­ši­ri­tve protokola RDAP. V na­sle­dnjem poglavju na kratko po­ja­snju­je­mo, kako protokol deluje prek HTTPS, kot je opisano v RFC 7840.

Tip

Da bi raz­vi­jal­cem olajšala izvajanje protokola, je or­ga­ni­za­ci­ja ICANN pri­pra­vi­la Priročnik za izvajanje protokola RDAP.

Naloge naročnika:

Izvajanje protokola RDAP na strani odjemalca sploh ni zapleteno. Protokol RDAP temelji na protokolu HTTP, zato za prenos podatkov uporablja že obstoječe metode HTTP. Odjemalci lahko strežniku pošiljajo zahteve z metodama GET in HEAD. Zahteve GET in HEAD morajo vsebovati glavo »Accept«, ki določa, katere vrste datotek JSON odjemalec sprejema.

Naloge strežnika:

Izvajanje je na stre­žni­ški strani nekoliko bolj zapleteno, saj mora strežnik upo­šte­va­ti kar nekaj posebnih primerov. Če je zahteva uspešna, mora strežnik vrniti zahtevane podatke v zahtevani obliki s statusno kodo HTTP 200 (OK). Na zahteve GET mora strežnik od­go­vo­ri­ti z zah­te­va­ni­mi podatki o lastniku, na zahteve HEAD pa mora navesti, ali ima na voljo podatke za to domeno.

Če ve, kje se nahajajo zahtevani podatki, vendar jih sam nima, mora od­go­vo­ri­ti z eno od statusnih kod 301, 302, 303 ali 307. URL, na katerem se podatki nahajajo, se nato pošlje v HTTP-glavi »Location«.

Če strežnik zahtevka ne more obdelati, ker zahtevani podatki niso na voljo, mora od­go­vo­ri­ti s statusno kodo 404 (Not Found). Če zahtevani podatki sicer obstajajo, vendar strežnik iz kakšnega drugega razloga ne želi od­go­vo­ri­ti, mora od­go­vo­ri­ti z ustrezno statusno kodo iz območja 400. Na zahtevke, ki vsebujejo napake in jih zato ni mogoče razumeti kot zahtevke RDAP, je treba od­go­vo­ri­ti s statusno kodo 400 (Bad Request). V tem primeru se lahko dodatne in­for­ma­ci­je pošljejo v telesu entitete HTTP.

Za po­drob­nej­še in­for­ma­ci­je o postopku ter varnosti in možnostih raz­ši­ri­tve protokola si oglejte ustrezne RFC-je. Povezave do njih so navedene spodaj.

V čem se protokol za dostop do re­gi­stra­cij­skih podatkov razlikuje od drugih?

RDAP se je v mnogih pogledih izkazal za iz­bolj­ša­no različico Whoisa. Delovna skupina IETF se je osre­do­to­či­la na po­manj­klji­vo­sti starega protokola, kar pomeni, da je pri razvoju novega protokola za poizvedbe veliko po­zor­no­sti posvetila varnosti, strukturi in in­ter­na­ci­o­na­li­za­ci­ji. Po­sle­dič­no je nastalo več novih funkcij, med drugim:

  • Struk­tu­ri­ra­na semantika zahtevkov in odgovorov (vključno s stan­dar­di­zi­ra­ni­mi sporočili o napakah)
  • Varen dostop do zah­te­va­nih kon­tak­tnih podatkov (npr. prek HTTPS)
  • Raz­šir­lji­vost (npr. dodajanje izhodnih elementov)
  • Mehanizem**„bo­ot­stra­pping“**(podprt z iskanjem ustre­zne­ga av­to­ri­ta­tiv­ne­ga strežnika DNS)
  • Stan­dar­di­zi­ra­no po­sre­do­va­nje poizvedb
  • Spletno (HTTP) in skladno z REST
  • Enostavno pre­va­ja­nje izhodnih podatkov
  • Možnost do­de­lje­va­nja di­fe­ren­ci­ra­ne­ga dostopa do kon­tak­tnih podatkov

V mnogih pogledih se je protokol za dostop do re­gi­stra­cij­skih podatkov (RDAP) izkazal za precej bolj pri­la­go­dlji­ve­ga od svojega pred­ho­dni­ka. Medtem ko Whois kot besedilni protokol temelji na protokolu TCP in določenem TCP-vratih (43), RDAP uporablja spletni standard HTTP ali celo HTTPS. To pomeni, da se vsi podatki po­sre­du­je­jo v stan­dar­di­zi­ra­ni, strojno berljivi obliki JSON. To pomeni, da RDAP na eni strani omogoča večjo svobodo pri po­i­zve­do­va­nju podatkov, hkrati pa olajšuje pro­gra­mi­ra­nje storitev za po­i­zve­do­va­nje, ki lahko ko­mu­ni­ci­ra­jo z raz­lič­ni­mi re­gi­str­ski­mi organi, pri čemer zahtevane podatke iz­pi­su­je­jo v različnih jezikih.

RDAP Whois
na podlagi HTTP na osnovi besedila
Stan­dar­di­zi­ra­na oblika JSON Brez kodirnih shem
Izhodni podatki so berljivi za ra­ču­nal­nik in jih je mogoče enostavno prevajati Izhodni podatki so v obliki navadnih podatkov in jih zato ni mogoče av­to­mat­sko nadalje obdelati
Odgovori se samodejno pošiljajo drugim registrom Odgovori ne vsebujejo na­dalj­njih in­for­ma­cij o registru
Možnost opre­de­li­tve dostopnih pravic za različne skupine Različne vrste dostopa do podatkov niso mogoče

Možnost različnih vrst dostopa – še vedno tema za razpravo

Ena od nedvomno naj­po­memb­nej­ših novih funkcij, ki je bila vključena v protokol za dostop do re­gi­stra­cij­skih podatkov, je možnost določanja različnih dostopnih pravic za posamezne skupine upo­rab­ni­kov. To re­gi­stra­tor­ju omogoča, da natančno določi, kdo ima dostop do katerih podatkov. Tako imajo anonimni upo­rab­ni­ki le omejen dostop, medtem ko lahko po­o­bla­šče­ni upo­rab­ni­ki pre­gle­du­je­jo celoten nabor podatkov. To je področje, na katerem mnogi menijo, da so potrebna nujna pojasnila.

Eno od vprašanj, ki se med drugim poraja, je, kako ravnati v primeru kazenskih tožilcev, ki želijo ostati anonimni, hkrati pa imeti polne pravice dostopa. Poleg tega ni smernic glede tega, ali se v takem primeru dostop do podatkov o domeni lahko dodeli tudi osebam zunaj državnih meja. Predvsem pa je pred­no­stna naloga zaščita upo­rab­ni­ških podatkov in s tem povezano zaupanje v upra­vljav­ca spletne strani, ki re­gi­stri­ra domeno. To zaupanje nova teh­no­lo­gi­ja zahtevkov RDAP v nobenem primeru ne sme ogroziti. Konec leta 2016 je več registrov vložilo pritožbo proti iz­ved­be­ne­mu roku, ki ga je določila ICANN, zaradi česar se je or­ga­ni­za­ci­ja odločila skleniti pogodbe za RDAP z re­gi­stra­tor­ji in ponudniki domen.

Go to Main Menu