# Kaj je protokol za dostop do registracijskih podatkov (RDAP)?

Do sedaj je bilo mogoče lastnika domene poiskati s pomočjo [storitev Whois](https://www.ionos.co.uk/tools/whois-domain-lookup "Whois Domain Lookup from IONOS"), ki temeljijo na istoimenskem protokolu. Vendar sta organizaciji IETF in ICANN leta 2015 objavili prvi RFC za protokol **RDAP (Registration Data Access Protocol)**, ki naj bi postal glavni naslednik protokola Whois.

## Kaj je protokol za dostop do registracijskih podatkov (RDAP)?

Koncept protokola za dostop do registracijskih podatkov (RDAP) je zasnovala delovna skupina v okviru Internet Engineering Task Force (IETF). Po skoraj štiriletni projektni fazi je 26. julija 2016 izšla prva različica profila protokola (1.0). Njegove značilnosti in uporabe so opisane v različnih **zahtevah za komentarje (RFC 7480–7484 in RFC 8056)**. RDAP omogoča dostop do dodatnih informacij o osnovnih internetnih virih, vključno z

- **Domenska imena**
- **IP-naslovi** ali
- **številke avtonomnih sistemov** (ASN)

kot tudi druge sorodne članke. Zato alternativa Whois predstavlja osnovo za pošiljanje poizvedb različnim **registrom domen**. To vključuje zagotavljanje podatkov v vaši **bazi**, na primer kontaktnih podatkov lastnikov domen, kontaktnih podatkov morebitnih skrbnikov (Admin C) ali celo naslova uporabljenega 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 vzpostavitve 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 strokovnjake prava trn v peti. Danes je glavna kritika, usmerjena proti Whoisu, da ne izpolnjuje več **tehničnih zahtev** interneta.

Ena od glavnih težav je, da protokol Whois ne podpira kodiranja in zato **ne omogoča prikazovanja nelatinskih znakov**. Druga pomembna pomanjkljivost je, da dostop do podatkov o domenah ne poteka prek varne povezave in ni **reguliran**. Tudi anonimni uporabniki imajo neomejen dostop in lahko pridobijo e-poštne in poštne naslove.

Projekti, kot sta razširitev Whois++ ali protokol IRIS (Internet Registry Information Service) Denic, so sicer prinesli nekaj izboljšav, vendar se niso uspeli uveljaviti kot trdna alternativa sistemu Whois. Po dolgem času in številnih razpravah znotraj **skupnosti ICANN o nujnosti nadaljnjega**razvoja\*\* je Svetovalni odbor za varnost in stabilnost (SSAC) s svojim [varnostnim poročilom SAC 501](https://www.icann.org/en/system/files/files/sac-051-en.pdf "ICANN Report on Domain Name Whois Terminology and Structure") dal odločilni zagon za ustanovitev delovne skupine RDAP septembra 2011.

Januarja 2023 je ICANN začel svetovno glasovanje, 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 registratorji ne bodo več dolžni podpirati WHOIS.

## Kako deluje RDAP?

Za implementacijo 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 implementacija protokola. Poleg tega obstajajo še drugi RFC-ji, v katerih so opisane razširitve protokola RDAP. V naslednjem poglavju na kratko pojasnjujemo, kako protokol deluje prek HTTPS, kot je opisano v [RFC 7840](https://datatracker.ietf.org/doc/html/rfc7480 "RFC 7840: HTTP Usage in the Registration Data Access Protocol (RDAP)").

Tip Da bi razvijalcem olajšala izvajanje protokola, je organizacija ICANN pripravila [Priročnik za izvajanje protokola RDAP](https://www.icann.org/en/system/files/files/rdap-technical-implementation-guide-15feb19-en.pdf "ICANN RDAP Technical Implementation Guide").

**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števati 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 odgovoriti z zahtevanimi 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 odgovoriti 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 odgovoriti s statusno kodo 404 (Not Found). Če zahtevani podatki sicer obstajajo, vendar strežnik iz kakšnega drugega razloga ne želi odgovoriti, mora odgovoriti 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 odgovoriti s statusno kodo 400 (Bad Request). V tem primeru se lahko dodatne informacije pošljejo v telesu entitete HTTP.

Za podrobnejše informacije o postopku ter varnosti in možnostih razširitve protokola si oglejte ustrezne RFC-je. Povezave do njih so navedene spodaj.

- [RFC 7840: Uporaba protokola HTTP](https://datatracker.ietf.org/doc/html/rfc7480 "RFC 7840 of the IETF")
- [RFC 7841: Varnostne storitve](https://datatracker.ietf.org/doc/html/rfc7481 "RFC 7841 of the IETF")
- [RFC 7842: Oblika poizvedbe](https://datatracker.ietf.org/doc/html/rfc7482 "RFC 7842 of the IETF")
- [RFC 7843: Odgovori JSON](https://datatracker.ietf.org/doc/html/rfc7483 "RFC 7843 of the IETF")
- [RFC 7844: Iskanje verodostojnih podatkov o registraciji](https://datatracker.ietf.org/doc/html/rfc7484 "RFC 7844 of the IETF")

## V čem se protokol za dostop do registracijskih podatkov razlikuje od drugih?

RDAP se je v mnogih pogledih izkazal za izboljšano različico Whoisa. Delovna skupina IETF se je osredotočila na pomanjkljivosti starega protokola, kar pomeni, da je pri razvoju novega protokola za poizvedbe veliko pozornosti posvetila **varnosti**, **strukturi** in **internacionalizaciji**. Posledično je nastalo več novih funkcij, med drugim:

- **Strukturirana** semantika zahtevkov in odgovorov (vključno s standardiziranimi sporočili o napakah)
- **Varen dostop** do zahtevanih kontaktnih podatkov (npr. prek HTTPS)
- Razširljivost (npr. dodajanje izhodnih elementov)
- Mehanizem\*\*„bootstrapping“\*\*(podprt z iskanjem ustreznega avtoritativnega strežnika DNS)
- Standardizirano **posredovanje** poizvedb
- Spletno (HTTP) in skladno **z REST**
- Enostavno prevajanje izhodnih podatkov
- Možnost dodeljevanja **diferenciranega dostopa** do kontaktnih podatkov

V mnogih pogledih se je protokol za dostop do registracijskih podatkov (RDAP) izkazal za precej bolj prilagodljivega od svojega predhodnika. 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 posredujejo v **standardizirani, strojno berljivi obliki JSON**. To pomeni, da RDAP na eni strani omogoča večjo svobodo pri poizvedovanju podatkov, hkrati pa olajšuje programiranje storitev za poizvedovanje, ki lahko komunicirajo z različnimi registrskimi organi, pri čemer zahtevane podatke izpisujejo v različnih jezikih.

<table>
  <thead>
    <tr>
      <th><strong>RDAP</strong></th>
      <th><strong>Whois</strong></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>na podlagi HTTP</td>
      <td>na osnovi besedila</td>
    </tr>
    <tr>
      <td>Standardizirana oblika JSON</td>
      <td>Brez kodirnih shem</td>
    </tr>
    <tr>
      <td>Izhodni podatki so berljivi za računalnik in jih je mogoče enostavno prevajati</td>
      <td>Izhodni podatki so v obliki navadnih podatkov in jih zato ni mogoče avtomatsko nadalje obdelati</td>
    </tr>
    <tr>
      <td>Odgovori se samodejno pošiljajo drugim registrom</td>
      <td>Odgovori ne vsebujejo nadaljnjih informacij o registru</td>
    </tr>
    <tr>
      <td>Možnost opredelitve dostopnih pravic za različne skupine</td>
      <td>Različne vrste dostopa do podatkov niso mogoče</td>
    </tr>
  </tbody>
</table>

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

Ena od nedvomno najpomembnejših novih funkcij, ki je bila vključena v protokol za dostop do registracijskih podatkov, je možnost določanja različnih **dostopnih pravic** za posamezne skupine uporabnikov. To registratorju omogoča, da **natančno določi**, kdo ima dostop do katerih podatkov. Tako imajo anonimni uporabniki le omejen dostop, medtem ko lahko pooblaščeni uporabniki pregledujejo 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 prednostna naloga zaščita uporabniških podatkov in s tem povezano zaupanje v upravljavca spletne strani, ki registrira domeno. To zaupanje nova tehnologija zahtevkov RDAP v nobenem primeru ne sme ogroziti. Konec leta 2016 je več registrov vložilo pritožbo proti **izvedbenemu roku, ki ga je določila ICANN**, zaradi česar se je organizacija odločila skleniti **pogodbe** za RDAP z registratorji in ponudniki domen.


This is a markdown version of: [https://www.ionos.com/sl-si/digitalguide/domene/upravljanje-domene/kaj-je-protokol-za-dostop-do-registracijskih-podatkov-rdap/](https://www.ionos.com/sl-si/digitalguide/domene/upravljanje-domene/kaj-je-protokol-za-dostop-do-registracijskih-podatkov-rdap/) for AI/LLM consumption.