Siiani oli domeeni omanikku võimalik leida Whois-teenuste abil, mis põhinevad sa­ma­ni­me­li­sel pro­to­kol­lil. 2015. aastal keh­tes­ta­sid IETF ja ICANN esimese RDAP-pro­to­kolli (Re­gist­ra­tion Data Access Protocol) RFC-dokumendi, mis sai Whois-pro­to­kolli peamiseks jä­rel­tu­li­jaks.

Mis on re­gist­ree­ri­mis­and­mete juur­de­pää­supro­to­koll (RDAP)?

Re­gist­ree­ri­mis­and­me­tele juur­de­pääsu pro­to­kolli (RDAP) kont­sept­sioon pärineb Internet En­gi­nee­ring Task Force’i (IETF) töö­rüh­malt. Pärast ligi nelja-aastast pro­jek­ti­fa­asi ilmus pro­to­kolli profiili esimene versioon (1.0) 26. juulil 2016. Selle omadused ja ra­ken­dused on kir­jel­da­tud mitmes kom­men­taa­ride taotluses (RFC 7480–7484 ja RFC 8056). RDAP pakub võimalust pääseda juurde täien­da­vale teabele põhiliste in­ter­ne­ti­res­surs­side kohta, seal­hul­gas

  • Do­mee­nini­med
  • IP-aadressid või
  • au­to­noom­sete süs­teemide numbrid (ASN-id)

ning muud seotud artiklid. Seetõttu moodustab Whois-al­ter­na­tiiv aluse päringute saat­miseks eri­ne­va­tele do­mee­ni­re­gist­ri­tele. See hõlmab näiteks do­mee­ni­oma­nike kon­tak­tand­mete, haldajate (Admin C) kon­tak­tand­mete või isegi ka­su­ta­tava ni­miser­veri aadressi, seal­hul­gas haldaja aadressi, edas­ta­mist teie and­me­ba­asi.

Miks RDAP välja töötati?

Juba 1982. aastal avaldas IETF Whois-pro­to­kolli, mille eesmärk oli luua pä­rin­gu­tee­nus tollal ARPANET-iks nimetatud võr­gus­ti­kule. Asjaolu, et seda ka­su­ta­takse veerand sajandit hiljem endiselt, nüüd juba vee­bi­põ­histe päringute jaoks, on paljude eks­per­tide jaoks olnud tülikas probleem. Tä­na­päe­val on peamine Whois-i suhtes esitatav kriitika see, et see ei vasta enam interneti teh­ni­lis­tele nõuetele.

Üks peamisi probleeme on see, et Whois-protokoll ei toeta koode ja seetõttu ei paku see tuge mitte-ladina tä­hes­ti­kus tekstile. Teine oluline puudus on see, et do­mee­ni­and­me­tele juur­de­pääs ei toimu turvalise ühenduse kaudu ja on re­gu­lee­ri­mata. Isegi ano­nüüm­sed kasutajad saavad täieliku juur­de­pääsu ning võivad kätte saada nii e-posti- kui ka pos­tiaad­resse.

Sellised projektid nagu Whois++ laiendus või IRIS (Internet Registry In­for­ma­tion Service) Denic Protocol suutsid küll mõningaid parandusi pakkuda, kuid neil ei õn­nes­tu­nud end siiski Whoisile kindla al­ter­na­tiivina keh­tes­tada. Pärast pikka aega ja paljusid aru­telusid ICANN-i ko­gu­kon­nas edasisearen­da­mise vajaduse üleandis tur­va­li­suse ja sta­biil­suse nõu­an­de­ko­mi­tee (SSAC) oma SAC 501 tur­va­li­sus­aru­an­dega otsustava tõuke RDAP-töörühma loomiseks 2011. aasta sep­temb­ris.

2023. aasta jaanuaris algatas ICANN üle­maa­ilmse hääletuse, et otsustada, kas asendada WHOIS amet­li­kult RDAP-iga. Vajalik häälte arv saavutati ja võeti vastu otsus RDAP-ile ülemineku amet­likuks jõus­ta­miseks. Alates 2025. aasta jaa­nua­rist ei pea DNS-registrid ja re­gist­ri­pi­da­jad enam WHOIS-i toetama.

Kuidas RDAP toimib?

RDAP-i ra­ken­da­miseks on oluline esmalt mõista, kuidas protokoll toimib nii kliendi kui ka serveri poolel. Selleks tasub tutvuda RFC-do­ku­men­ti­dega 7480–7484, kus on ük­sik­as­ja­li­kult kir­jel­da­tud pro­to­kolli mi­ni­maalne rakendus. Lisaks on olemas veel RFC-do­ku­men­did, kus kir­jel­da­takse RDAP-pro­to­kolli laiendusi. Järgmises jaotises selgitame üld­joon­tes, kuidas protokoll töötab HTTPS-i kaudu, nagu on kir­jel­da­tud RFC 7840-s.

Tip

Et hõl­bus­tada aren­da­ja­tel pro­to­kolli ra­ken­da­mist, on ICANN avaldanud RDAP-i ra­ken­da­mis­ju­hendi.

Kliendi ülesanded:

RDAPi ra­ken­da­mine kliendi poolel ei ole üldse keeruline. RDAP põhineb HTTP-pro­to­kol­lil ja kasutab seetõttu andmete edas­ta­miseks juba ole­mas­ole­vaid HTTP-meetodeid. Kliendid saavad serverile päringuid saata meetodite GET ja HEAD abil. Nii GET- kui ka HEAD-päringud peaksid sisaldama pealkirja „Accept”, mis määrab kindlaks, milliseid JSON-fai­li­tüüpe klient akt­sep­tee­rib.

Serveri ülesanded:

Ra­ken­da­mine on serveri poolel veidi kee­ru­li­sem, kuna server peab arvestama mitmete eri­juh­tu­dega. Kui päring on edukas, peaks server tagastama taotletud andmed soovitud vormingus koos HTTP-staa­tus­koo­diga 200 (OK). GET-päringute korral peaks server vastama taotletud oma­ni­ku­and­me­tega ning HEAD-päringute korral peaks ta näitama, kas tal on selle domeeni jaoks andmeid olemas.

Kui server teab, kus asuvad taotletud andmed, kuid tal endal neid pole, peaks ta vastama ühega staa­tus­koo­di­dest 301, 302, 303 või 307. Seejärel saa­de­takse URL, millelt andmed leida, HTTP-pealkirja „Location“ all.

Kui server ei saa päringut töödelda, kuna taotletud andmed pole kät­te­saa­da­vad, peaks ta vastama staa­tus­koo­diga 404 (Not Found). Kui taotletud andmed on olemas, kuid server ei soovi mingil muul põhjusel vastata, peaks ta vastama sobiva staa­tus­koo­diga va­he­mi­kust 400. Pä­rin­gu­tele, mis si­sal­da­vad vigu ja mida seetõttu ei saa käsitada RDAP-pä­rin­gu­tena, tuleks vastata staa­tus­koo­diga 400 (Bad Request). Sel juhul võib täien­da­vat teavet saata HTTP-entiteedi kehas.

Täpsemat teavet protsessi, pro­to­kolli tur­va­li­suse ja laien­da­mis­või­ma­luste kohta leiate vas­ta­va­test RFC-do­ku­men­ti­dest. Nende lingid on toodud allpool.

Milles seisneb re­gist­ree­ri­mis­and­me­tele juur­de­pääsu pro­to­kolli eripära?

Mitmes mõttes on RDAP osutunud Whoisi täius­ta­tud ver­sioo­niks. IETF-i töörühm on kes­ken­du­nud vana pro­to­kolli puu­dus­tele, mis tähendab, et uue pä­rin­gu­pro­to­kolli puhul on pööratud suurt tä­he­le­panu sel­lis­tele as­pek­ti­dele nagu tur­va­li­sus, struktuur ja rah­vus­va­he­lis­ta­mine. Selle tu­le­mu­sena on tekkinud mitu uut funkt­siooni, seal­hul­gas:

  • Struk­tu­ree­ri­tud päringu- ja vastuse semantika (sh stan­dar­di­tud veateated)
  • Turvaline juur­de­pääs taotletud kon­tak­tand­me­tele (nt HTTPS-i kaudu)
  • Laien­da­ta­vus (nt väl­jun­d­e­le­men­tide lisamine)
  • „Bootst­rapping”-mehhanism (toetatud sobiva au­to­ri­teetse DNS-serveri ot­si­mi­sega)
  • Stan­dar­di­see­ri­tud päringute edas­ta­mine
  • Vee­bi­põ­hine (HTTP) ja REST-iga ühilduv
  • Väl­jundand­mete lihtne tõlkimine
  • Võimalus anda di­fe­rent­see­ri­tud juur­de­pääs kon­tak­tand­me­tele

Mitmes mõttes on re­gist­ree­ri­mis­and­mete juur­de­pää­supro­to­koll (RDAP) osutunud oma eel­käi­jast palju paind­li­ku­maks. Kui teks­ti­põ­hine Whois-protokoll tugineb TCP-le ja kindlale TCP-pordile (43) , siis RDAP kasutab vee­b­i­stan­dar­dit HTTP või isegi HTTPS-i. See tähendab, et kõik andmed edas­ta­takse stan­dar­di­see­ri­tud, ma­sin­loe­ta­vas JSON-vormingus. See tähendab, et ühelt poolt võimaldab RDAP suuremat vabadust and­me­pä­rin­gute tegemisel, samas liht­sus­ta­des ka selliste pä­rin­gu­tee­nuste prog­ram­mee­ri­mist, mis suudavad suhelda erinevate re­gist­ree­ri­mis­asu­tus­tega ning väl­jas­tada taotletud andmeid eri­ne­va­tes keeltes.

RDAP Whois
HTTP-põhine teks­ti­põ­hine
Stan­dar­di­see­ri­tud JSON-vorming Ilma ko­dee­ri­misskeemi­deta
Väl­jundand­med on ma­sin­loe­ta­vad ja neid saab lihtsalt tõlkida Väl­jundand­med on lihtand­metena ja seetõttu ei saa neid au­to­maat­selt edasi töödelda
Vastused saa­de­takse au­to­maat­selt teistesse re­gist­ri­tesse Vastused ei sisalda teavet järg­ne­vate re­gist­rite kohta
Võimalik määrata juur­de­pää­su­õi­gusi eri­ne­va­tele rühmadele Erinevat tüüpi juur­de­pääs andmetele ei ole võimalik

Erinevate juur­de­pää­su­või­ma­luste valik – endiselt arutlusel olev teema

Kaht­le­mata on üks olu­li­se­maid uusi funkt­sioone, mis re­gist­ree­ri­mis­and­mete juur­de­pää­supro­to­kolli lisati, võimalus määrata erinevad juur­de­pää­su­õi­gu­sed konk­reet­se­tele ka­su­ta­ja­rüh­ma­dele. See võimaldab re­gist­ri­pi­da­jal täpselt re­gu­lee­rida, kes millist teavet näha saab. Nii on ano­nüüm­se­tel ka­su­ta­ja­tel vaid piiratud juur­de­pääs, samas kui volitatud kasutajad saavad vaadata kogu and­me­ko­gu­mit. See on aspekt, mille puhul paljud inimesed peavad va­ja­likuks olulisi selgitusi.

Üks küsimusi, mis sellega seoses tõstatub, on muu hulgas see, kuidas toimida kri­mi­naal­pro­ku­rö­ride puhul, kes soovivad jääda ano­nüüm­seks, kuid samal ajal omada täielikke juur­de­pää­su­õi­gusi. Lisaks puuduvad suunised selle kohta, kas sellisel juhul võib do­mee­ni­and­me­tele juur­de­pääsu anda ka isikutele, kes asuvad väl­jas­pool riigi piire. Eelkõige on priori­tee­diks ka­su­ta­jate andmete kaitse ja sellega kaasnev usaldus domeeni re­gist­ree­riva vee­bi­saidi ope­raa­tori vastu. Uus RDAP-pä­rin­gu­teh­no­loo­gia ei tohi mingil juhul seda usaldust kah­jus­tada. 2016. aasta lõpus esitasid mitmed registrid kaebuse ICANNi keh­tes­ta­tud ra­ken­da­mis­pe­rioodi vastu, mistõttu on or­ga­ni­sat­sioon ot­sus­ta­nud sõlmida RDAP-lepinguid re­gist­ri­pi­da­jate ja do­mee­ni­pak­ku­ja­tega.

Go to Main Menu