Tähän asti verk­ko­tun­nuk­sen haltija on voitu selvittää Whois-pal­ve­lui­den avulla, jotka pe­rus­tu­vat sa­man­ni­mi­seen pro­to­kol­laan. Vuonna 2015 IETF ja ICANN jul­kai­si­vat kuitenkin en­sim­mäi­sen RDAP-pro­to­kol­lan (Re­gi­stra­tion Data Access Protocol) RFC-mää­rit­te­lyn, joka on Whoisin tärkein seuraaja.

Mikä on re­kis­te­ri­tie­to­jen käyt­töpro­to­kol­la (RDAP)?

Re­kis­te­ri­tie­to­jen käyt­töpro­to­kol­lan (RDAP) konsepti syntyi Internet En­gi­nee­ring Task Force (IETF) -työ­ryh­mäs­sä. Lähes neljän vuoden pro­jek­ti­vai­heen jälkeen pro­to­kol­lapro­fii­lin en­sim­mäi­nen versio (1.0) jul­kais­tiin 26. hei­nä­kuu­ta 2016. Sen omi­nai­suu­det ja so­vel­luk­set on kuvattu useissa Requests for Comments-asia­kir­jois­sa (RFC 7480–7484 ja RFC 8056). RDAP tarjoaa mah­dol­li­suu­den saada li­sä­tie­to­ja In­ter­ne­tin pe­rus­re­surs­seis­ta, mukaan lukien

  • Verk­ko­tun­nuk­set
  • IP-osoitteet tai
  • au­to­no­mis­ten jär­jes­tel­mien numerot (ASN)

sekä muita aiheeseen liittyviä ar­tik­ke­lei­ta. Tästä syystä Whois-vaih­toeh­to toimii perustana kyselyjen lä­het­tä­mi­sel­le eri verk­ko­tun­nus­re­kis­te­reil­le. Tähän sisältyy esi­mer­kik­si verk­ko­tun­nus­ten omis­ta­jien yh­teys­tie­to­jen, mah­dol­lis­ten jär­jes­tel­män­val­vo­jien (Admin C) yh­teys­tie­to­jen tai jopa käy­tet­tä­vän ni­mi­pal­ve­li­men osoitteen, mukaan lukien jär­jes­tel­män­val­vo­jan osoitteen, toi­mit­ta­mi­nen tie­to­kan­taa­si.

Miksi RDAP ke­hi­tet­tiin?

Vuonna 1982 IETF julkaisi Whois-pro­to­kol­lan tar­koi­tuk­se­naan tarjota ha­ku­pal­ve­lu sille, mitä tuolloin kut­sut­tiin AR­PA­NE­Tik­si. Se, että pro­to­kol­la on edelleen käytössä nel­jän­nes­vuo­si­sa­ta myöhemmin, nykyään verk­ko­ha­ku­jen yh­tey­des­sä, on ollut monille asian­tun­ti­joil­le piikki lihassa. Nykyään Whoisia kohtaan esitetty pää­asial­li­nen kritiikki koskee sitä, että se ei enää täytä in­ter­ne­tin teknisiä vaa­ti­muk­sia.

Yksi suu­rim­mis­ta on­gel­mis­ta on se, että Whois-pro­to­kol­la ei tue mer­kis­tö­jä, eikä se siten tue muita kuin la­ti­na­lai­sia mer­kis­tö­jä. Toinen mer­kit­tä­vä hait­ta­puo­li on se, että verk­ko­tun­nus­tie­toi­hin pääsee käsiksi suo­jaa­mat­to­man yhteyden kautta eikä tietojen käyttöä ole säännelty. Jopa ni­met­tö­mät käyttäjät saavat täyden pääsyn tietoihin ja pääsevät käsiksi säh­kö­pos­ti- ja pos­tio­soit­tei­siin.

Hankkeet kuten Whois++-laajennus tai IRIS (Internet Registry In­for­ma­tion Service) Denic -pro­to­kol­la on­nis­tui­vat tuomaan joitakin pa­ran­nuk­sia, mutta ne eivät kui­ten­kaan on­nis­tu­neet va­kiin­nut­ta­maan asemaansa vankkana vaih­toeh­to­na Whoisille. Pitkän ajan ja monien ICANN-yhteisönsisäisten kes­kus­te­lu­jen jälkeen **jat­ko­ke­hi­tyk­sen tar­peel­li­suu­des­ta****tur­val­li­suus- ja va­kaus­neu­vot­te­lu­kun­ta (SSAC) antoi SAC 501 -tur­val­li­suus­ra­por­til­laan rat­kai­se­van sysäyksen RDAP-työryhmän pe­rus­ta­mi­sel­le syys­kuus­sa 2011.

Tam­mi­kuus­sa 2023 ICANN käynnisti maa­il­man­laa­jui­sen ää­nes­tyk­sen, jossa pää­tet­tiin, kor­va­taan­ko WHOIS vi­ral­li­ses­ti RDAP:lla. Vaadittu äänimäärä saa­vu­tet­tiin, ja pää­tet­tiin panna RDAP:iin siir­ty­mi­nen vi­ral­li­ses­ti täy­tän­töön. Tam­mi­kuus­ta 2025 lähtien DNS-re­kis­te­rien ja re­kis­te­rin­pi­tä­jien ei enää tarvitse tukea WHOIS-palvelua.

Miten RDAP toimii?

RDAP-pro­to­kol­lan käyt­töön­ot­toa varten on tärkeää ymmärtää ensin, miten pro­to­kol­la toimii sekä asia­kas­puo­lel­la että pal­ve­lin­puo­lel­la. Tätä varten kannattaa tutustua RFC-stan­dar­dei­hin 7480–7484, joissa pro­to­kol­lan vä­him­mäis­to­teu­tus on kuvattu yk­si­tyis­koh­tai­ses­ti. Lisäksi on olemassa muita RFC-stan­dar­de­ja, joissa kuvataan RDAP-pro­to­kol­lan laa­jen­nuk­sia. Seu­raa­vas­sa osassa selitämme pää­piir­teit­täin, miten pro­to­kol­la toimii HTTPS:n kautta, kuten RFC 7840:ssä kuvataan.

Vinkki

Jotta ke­hit­tä­jien olisi helpompi ottaa pro­to­kol­la käyttöön, ICANN on jul­kais­sut RDAP-to­teu­tusop­paan.

Asiakkaan tehtävät:

RDAP:n to­teut­ta­mi­nen asia­kas­puo­lel­la ei ole lainkaan mo­ni­mut­kais­ta. RDAP perustuu HTTP-pro­to­kol­laan, joten se käyttää tietojen siirtoon jo olemassa olevia HTTP-me­ne­tel­miä. Asiakkaat voivat lähettää pal­ve­li­mel­le pyyntöjä GET- ja HEAD-me­ne­tel­mil­lä. Sekä GET- että HEAD-pyyn­nöis­sä tulisi olla ”Accept”-otsikko, joka määrittää, minkä tyyppisiä JSON-tie­dos­to­ja asiakas hyväksyy.

Pal­ve­li­men tehtävät:

Toteutus on pal­ve­lin­puo­lel­la hieman mo­ni­mut­kai­sem­paa, sillä pal­ve­li­men on otettava huomioon useita eri­tyis­ta­pauk­sia. Jos pyyntö onnistuu, pal­ve­li­men tulisi palauttaa pyydetyt tiedot pyy­de­tys­sä muodossa HTTP-ti­la­koo­dil­la 200 (OK). GET-pyyn­nöis­sä pal­ve­li­men tulisi vastata pyy­de­tyil­lä omis­ta­ja­tie­doil­la, ja HEAD-pyyn­nöis­sä sen tulisi ilmoittaa, onko sillä tietoja saa­ta­vil­la ky­sei­sel­le verk­ko­tun­nuk­sel­le.

Jos palvelin tietää, missä pyydetyt tiedot si­jait­se­vat, mutta ei itse hallitse niitä, sen tulisi vastata jollakin seu­raa­vis­ta ti­la­koo­deis­ta: 301, 302, 303 tai 307. Tällöin URL-osoite, josta tiedot löytyvät, lä­he­te­tään HTTP-otsikossa ”Location”.

Jos palvelin ei voi käsitellä pyyntöä, koska pyy­det­ty­jä tietoja ei ole saa­ta­vil­la, sen tulisi vastata ti­la­koo­dil­la 404 (Not Found). Jos pyydetyt tiedot ovat olemassa, mutta palvelin ei jostain muusta syystä halua vastata, sen tulisi vastata sopivalla ti­la­koo­dil­la 400-sarjasta. Pyyn­töi­hin, jotka si­säl­tä­vät virheitä eikä niitä siksi voida tulkita RDAP-pyyn­nöik­si, tulisi vastata ti­la­koo­dil­la 400 (Bad Request). Tällöin li­sä­tie­to­ja voidaan lähettää HTTP-en­ti­tee­tin rungossa.

Li­sä­tie­to­ja pro­ses­sis­ta sekä pro­to­kol­lan tur­val­li­suu­des­ta ja laa­jen­nus­mah­dol­li­suuk­sis­ta löytyy asiaa kos­ke­vis­ta RFC-asia­kir­jois­ta. Niihin on linkit alla.

Mikä tekee re­kis­te­ri­tie­to­jen käyt­töpro­to­kol­las­ta erilaisen?

Monessa mielessä RDAP on osoit­tau­tu­nut pa­ran­nel­luk­si versioksi Whois-jär­jes­tel­mäs­tä. IETF:n työryhmä on kes­kit­ty­nyt vanhan pro­to­kol­lan heik­kouk­siin, mikä tar­koit­taa, että se on kiin­nit­tä­nyt erityistä huomiota uuden ky­se­lypro­to­kol­lan tur­val­li­suu­teen, ra­ken­tee­seen ja kan­sain­vä­lis­tä­mi­seen. Tämän seu­rauk­se­na on syntynyt useita uusia omi­nai­suuk­sia, kuten:

  • Jär­jes­tel­mäl­li­nen pyyntö- ja vas­taus­se­man­tiik­ka (mukaan lukien stan­dar­doi­dut vir­heil­moi­tuk­set)
  • Tur­val­li­nen pääsy pyy­det­tyi­hin yh­teys­tie­toi­hin (esim. HTTPS:n kautta)
  • Laa­jen­net­ta­vuus (esim. tu­los­tuse­le­ment­tien li­sää­mi­nen)
  • **”**Boot­strap­ping”-mekanismi (jota tukee sopivan auk­to­ri­teet­ti­sen DNS-pal­ve­li­men haku)
  • Stan­dar­doi­tu kyselyjen välitys
  • Verk­ko­poh­jai­nen (HTTP) ja REST -yh­teen­so­pi­va
  • Tu­los­tie­to­jen yk­sin­ker­tai­nen kään­tä­mi­nen
  • Mah­dol­li­suus myöntää eriy­tet­tyä pääsyä yh­teys­tie­toi­hin

Monessa suhteessa re­kis­te­ri­tie­to­jen ha­kupro­to­kol­la (RDAP) on osoit­tau­tu­nut huo­mat­ta­vas­ti jous­ta­vam­mak­si kuin edel­tä­jän­sä. Kun teks­ti­poh­jai­nen Whois-pro­to­kol­la perustuu TCP-pro­to­kol­laan ja tiettyyn TCP-porttiin (43), RDAP käyttää web-stan­dar­dia HTTP:tä tai jopa HTTPS:ää. Tämä tar­koit­taa, että kaikki tiedot toi­mi­te­taan stan­dar­doi­dus­sa, ko­neel­li­ses­ti luet­ta­vas­sa JSON-muodossa. Tämä tar­koit­taa, että toisaalta RDAP tarjoaa enemmän vapautta tie­to­ky­se­lyis­sä ja toisaalta helpottaa sel­lais­ten ky­se­ly­pal­ve­lui­den oh­jel­moin­tia, jotka voivat kom­mu­ni­koi­da eri re­kis­te­ri­vi­ran­omais­ten kanssa ja tuottaa pyydetyt tiedot eri kielillä.

RDAP Whois
HTTP-pohjainen teks­ti­poh­jai­nen
Stan­dar­di­soi­tu JSON-muoto Ei koo­daus­kaa­vioi­ta
Tu­los­tie­dot ovat ko­neel­li­ses­ti luet­ta­vis­sa ja ne voidaan kääntää helposti Tu­los­te­tut tiedot ovat pelkkää dataa, joten niitä ei voida käsitellä au­to­maat­ti­ses­ti edelleen
Vas­tauk­set lä­he­te­tään au­to­maat­ti­ses­ti muihin re­kis­te­rei­hin Vas­tauk­set eivät sisällä jat­ko­re­kis­te­ri­tie­to­ja
Eri­lai­sil­le ryhmille voidaan määrittää käyt­tö­oi­keu­det Erilaiset pää­sy­oi­keu­det tietoihin eivät ole mah­dol­li­sia

Erilaiset käyt­tö­oi­keus­tyy­pit – edelleen kes­kus­te­lu­nai­he

Epäi­le­mät­tä yksi tär­keim­mis­tä uusista toi­min­nois­ta, jotka on otettu käyttöön re­kis­te­ri­tie­to­jen käyt­töpro­to­kol­las­sa, on mah­dol­li­suus määrittää erilaisia käyt­tö­oi­keuk­sia yk­sit­täi­sil­le käyt­tä­jä­ryh­mil­le. Tämän ansiosta re­kis­te­rin­pi­tä­jä voi määrittää tarkasti, kuka saa nähdä mitäkin tietoja. Näin ni­met­tö­mil­lä käyt­tä­jil­lä on vain ra­joi­tet­tu käyt­tö­oi­keus, kun taas val­tuu­te­tut käyttäjät voivat tar­kas­tel­la koko tie­to­kan­taa. Tämä on seikka, jonka osalta monet pitävät sel­keyt­tä­mis­tä eh­dot­to­man vält­tä­mät­tö­mä­nä.

Yksi esiin nouse­vis­ta ky­sy­myk­sis­tä on muun muassa se, miten toimitaan ri­kos­syyt­tä­jien osalta, jotka haluavat pysyä ni­met­tö­mi­nä mutta nauttia samalla täy­si­mää­räi­sis­tä käyt­tö­oi­keuk­sis­ta. Lisäksi ei ole olemassa ohjeita siitä, voidaanko täl­lai­ses­sa ta­pauk­ses­sa myöntää pääsy verk­ko­tun­nus­tie­toi­hin myös maan rajojen ul­ko­puo­lel­la oleville tahoille. Ennen kaikkea etusi­jal­la on käyt­tä­jä­tie­to­jen suojelu ja siihen liittyvä luottamus verk­ko­tun­nuk­sen re­kis­te­röi­vään verk­ko­si­vus­ton yl­lä­pi­tä­jään. Uusi RDAP-pyyn­tö­tek­niik­ka ei missään nimessä saa vaarantaa tätä luot­ta­mus­ta. Vuoden 2016 lopussa useat re­kis­te­rit va­lit­ti­vat ICANNin aset­ta­mas­ta täy­tän­töön­pa­no­kau­des­ta, minkä seu­rauk­se­na or­ga­ni­saa­tio on päättänyt solmia RDAP-so­pi­muk­sia re­kis­te­rin­pi­tä­jien ja verk­ko­tun­nus­pal­ve­lun­tar­joa­jien kanssa.

Siirry pää­va­lik­koon