Tot nu toe kon een do­mein­hou­der worden gevonden met behulp van Whois-diensten, die zijn gebaseerd op het protocol met dezelfde naam. In 2015 hebben de IETF en ICANN echter de eerste RFC van het RDAP-protocol (Re­gi­stra­ti­on Data Access Protocol) vast­ge­steld als de be­lang­rijk­ste opvolger van Whois.

Wat is het Re­gi­stra­ti­on Data Access Protocol (RDAP)?

Het concept van het Re­gi­stra­ti­on Data Access Protocol (RDAP) is afkomstig van een werkgroep van de Internet En­gi­nee­ring Task Force (IETF). Na een pro­ject­fa­se van bijna vier jaar verscheen op 26 juli 2016 de eerste versie van het pro­to­col­pro­fiel (1.0). De kenmerken en toe­pas­sin­gen ervan worden be­schre­ven in de ver­schil­len­de Requests for Comments (RFC 7480-7484 en RFC 8056). RDAP biedt de mo­ge­lijk­heid om toegang te krijgen tot meer in­for­ma­tie over ba­sis­in­ter­net­bron­nen, waaronder

  • Do­mein­na­men
  • IP-adressen of
  • Au­to­no­mous System Numbers (ASN’s)

evenals andere ge­re­la­teer­de artikelen. Om deze reden vormt het Whois-al­ter­na­tief de basis voor het verzenden van query’s naar de ver­schil­len­de do­mein­re­gis­ters. Dit omvat het voorzien van uw database met bij­voor­beeld con­tact­ge­ge­vens van de do­meinei­ge­na­ren, con­tact­ge­ge­vens van eventuele be­heer­ders (Admin C) of zelfs het adres van de gebruikte naam­ser­ver, inclusief dat van de beheerder.

Waarom is RDAP ont­wik­keld?

In 1982 pu­bli­ceer­de de IETF het Whois-protocol met als doel een op­vra­gings­dienst te creëren voor wat toen ARPANET heette. Het feit dat het een kwart eeuw later nog steeds in gebruik is, nu voor online op­vra­gin­gen, is voor veel des­kun­di­gen een doorn in het oog. Te­gen­woor­dig is de be­lang­rijk­ste kritiek op Whois dat het niet meer voldoet aan de tech­ni­sche eisen van het internet.

Een van de grootste problemen is dat het Whois-protocol niet met codering kan werken en daarom geen on­der­steu­ning biedt voor niet-Latijnse teksten. Een ander groot nadeel is dat de toegang tot de do­mein­ge­ge­vens niet via een be­vei­lig­de ver­bin­ding verloopt en niet ge­re­gu­leerd is. Zelfs anonieme ge­brui­kers krijgen volledige toegang en kunnen e-mail­adres­sen en post­adres­sen ach­ter­ha­len.

Projecten zoals de Whois++-extensie of het IRIS (Internet Registry In­for­ma­ti­on Service) Denic Protocol hebben weliswaar enkele ver­be­te­rin­gen op­ge­le­verd, maar zijn er niet in geslaagd zich te pro­fi­le­ren als een solide al­ter­na­tief voor Whois. Na een lange tijd en veel dis­cus­sies binnen de ICANN-ge­meen­schap over de noodzaak van verdereont­wik­ke­ling**, gaf het Security and Stability Advisory Committee (SSAC) met zijn SAC 501-be­vei­li­gings­rap­port de door­slag­ge­ven­de impuls om de RDAP-werkgroep in september 2011 tot leven te brengen.

In januari 2023 heeft ICANN een we­reld­wij­de stemming gehouden om te beslissen of WHOIS officieel vervangen zou worden door RDAP. Het vereiste aantal stemmen werd behaald en er werd besloten om de overstap naar RDAP officieel door te voeren. Vanaf januari 2025 hoeven DNS-registers en re­gi­strars WHOIS niet langer te on­der­steu­nen.

Hoe werkt RDAP?

Om RDAP te im­ple­men­te­ren, is het be­lang­rijk om eerst te begrijpen hoe het protocol werkt, zowel aan de client- als aan de ser­ver­zij­de. Hiervoor is het de moeite waard om RFC’s 7480 tot 7484 te raad­ple­gen, waarin een minimale im­ple­men­ta­tie van het protocol ge­de­tail­leerd wordt be­schre­ven. Daarnaast zijn er nog andere RFC’s waarin RDAP-pro­to­co­lex­ten­sies worden be­schre­ven. In het volgende gedeelte leggen we in grote lijnen uit hoe het protocol via HTTPS werkt, zoals be­schre­ven in RFC 7840.

Tip

Om de im­ple­men­ta­tie van het protocol voor ont­wik­ke­laars te ver­ge­mak­ke­lij­ken, heeft ICANN een RDAP-im­ple­men­ta­tie­gids opgesteld.

De taken van de klant:

Het im­ple­men­te­ren van RDAP aan de client­zij­de is helemaal niet in­ge­wik­keld. RDAP is gebaseerd op HTTP en maakt daarom gebruik van de reeds bestaande HTTP-methoden om gegevens over te dragen. Clients kunnen verzoeken naar de server sturen met behulp van de GET- en HEAD-methoden. Zowel GET- als HEAD-verzoeken moeten een ‘Accept’-header bevatten die aangeeft welke soorten JSON-bestanden door de client worden ge­ac­cep­teerd.

De taken van de server:

De im­ple­men­ta­tie is iets complexer aan de ser­ver­zij­de, omdat de server een aantal speciale gevallen moet af­han­de­len. Als het verzoek succesvol is, moet de server de gevraagde gegevens in het gevraagde formaat re­tour­ne­ren met HTTP-sta­tus­co­de 200 (OK). Bij GET-verzoeken moet de server reageren met de gevraagde ei­ge­naars­ge­ge­vens en bij HEAD-verzoeken moet hij aangeven of hij gegevens be­schik­baar heeft voor dit domein.

Als het weet waar de gevraagde gegevens zich bevinden, maar deze zelf niet heeft, moet het reageren met een van de sta­tus­co­des 301, 302, 303 of 307. De URL waar de gegevens te vinden zijn, wordt dan verzonden onder de HTTP-header ‘Location’.

Als de server het verzoek niet kan verwerken omdat de gevraagde gegevens niet be­schik­baar zijn, moet hij reageren met de sta­tus­co­de 404 (Not Found). Als de gevraagde gegevens wel bestaan, maar de server om een andere reden niet wil reageren, moet hij reageren met een passende sta­tus­co­de uit de reeks 400. Verzoeken die fouten bevatten en daarom niet als RDAP-verzoeken kunnen worden begrepen, moeten worden be­ant­woord met de sta­tus­co­de 400 (Bad Request). In dit geval kan aan­vul­len­de in­for­ma­tie worden verzonden in de HTTP-entity body.

Voor meer ge­de­tail­leer­de in­for­ma­tie over het proces en de be­vei­li­gings- en uit­brei­dings­mo­ge­lijk­he­den van het protocol kunt u de be­tref­fen­de RFC’s raad­ple­gen. Deze zijn hieronder gelinkt.

Wat maakt het Re­gi­stra­ti­on Data Access Protocol anders?

In veel opzichten is het RDAP een ver­be­ter­de versie van Whois gebleken. De IEFT-werkgroep heeft zich ge­con­cen­treerd op de zwakke punten van het oude protocol, wat betekent dat zij zich sterk heeft gericht op zaken als be­vei­li­ging, struc­tu­re­ring en in­ter­na­ti­o­na­li­se­ring voor het nieuwe query­pro­to­col. Als gevolg daarvan zijn er ver­schil­len­de nieuwe functies ontstaan, waaronder:

  • Ge­struc­tu­reer­de verzoek- en ant­woord­seman­tiek (inclusief ge­stan­daar­di­seer­de fout­mel­din­gen)
  • Veilige toegang tot de op­ge­vraag­de con­tact­ge­ge­vens (bij­voor­beeld via HTTPS)
  • Uit­breid­baar­heid (bijv. toe­voe­ging van uit­voe­rele­men­ten)
  • ‘Boot­strap­ping’-me­cha­nis­me (on­der­steund door het zoeken naar een geschikte ge­zag­heb­ben­de DNS-server)
  • Ge­stan­daar­di­seer­de door­stu­ring van query’s
  • Web­ge­ba­seerd (HTTP) en REST-com­pa­ti­bel
  • Een­vou­di­ge vertaling van uit­voer­ge­ge­vens
  • Mo­ge­lijk­heid om ge­dif­fe­ren­ti­eer­de toegang tot con­tact­ge­ge­vens te verlenen

In veel opzichten is het Re­gi­stra­ti­on Data Access Protocol veel flexi­be­ler gebleken dan zijn voor­gan­ger. Terwijl Whois, als tekst­ge­ba­seerd protocol, af­han­ke­lijk is van TCP en de spe­ci­fie­ke TCP-poort (43), maakt RDAP gebruik van de web­stan­daard HTTP, of zelfs HTTPS. Dit betekent dat alle gegevens worden geleverd in een ge­stan­daar­di­seerd, machinaal leesbaar JSON-formaat. Dit betekent enerzijds dat RDAP meer vrijheid biedt bij het opvragen van gegevens, terwijl het an­der­zijds ook ge­mak­ke­lij­ker wordt om query-services te pro­gram­me­ren die kunnen com­mu­ni­ce­ren met de ver­schil­len­de re­gi­stra­tie­au­to­ri­tei­ten en de op­ge­vraag­de gegevens in ver­schil­len­de talen kunnen weergeven.

RDAP Whois
HTTP-gebaseerd tekst­ge­ba­seerd
Ge­stan­daar­di­seerd JSON-formaat Geen co­de­rings­sche­ma’s
Uit­voer­ge­ge­vens zijn machinaal leesbaar en kunnen op een een­vou­di­ge manier worden vertaald Uit­voer­ge­ge­vens zijn in platte tekst en kunnen daarom niet au­to­ma­tisch verder worden verwerkt
Ant­woor­den worden au­to­ma­tisch naar andere registers gestuurd Ant­woor­den bevatten geen aan­vul­len­de re­gis­ter­in­for­ma­tie
Mo­ge­lijk­heid om toe­gangs­rech­ten voor ver­schil­len­de groepen te de­fi­ni­ë­ren Ver­schil­len­de soorten toegang tot gegevens zijn niet mogelijk

Optie voor ver­schil­len­de soorten toegang – nog steeds een onderwerp van discussie

Een van de be­lang­rijk­ste nieuwe functies die in het Re­gi­stra­ti­on Data Access Protocol is ge­ïm­ple­men­teerd, is on­ge­twij­feld de mo­ge­lijk­heid om ver­schil­len­de toe­gangs­rech­ten voor in­di­vi­du­e­le ge­brui­kers­groe­pen in te stellen. Hierdoor kan de registrar ge­de­tail­leerd regelen wie welke in­for­ma­tie te zien krijgt. Anonieme ge­brui­kers krijgen zo slechts beperkte toegang, terwijl ge­au­to­ri­seer­de ge­brui­kers de volledige dataset kunnen bekijken. Dit is een aspect waar volgens veel mensen nog veel on­dui­de­lijk­heid over bestaat.

Een van de vragen die dit oproept, is onder andere wat er moet gebeuren met straf­rech­te­lij­ke aan­kla­gers, die anoniem willen blijven en te­ge­lij­ker­tijd volledige toe­gangs­rech­ten willen hebben. Bovendien zijn er geen richt­lij­nen over de vraag of in een dergelijk geval ook toegang tot de do­mein­ge­ge­vens mag worden verleend aan personen buiten de lands­gren­zen. De pri­o­ri­teit ligt bovenal bij de be­scher­ming van ge­brui­kers­ge­ge­vens en het ver­trou­wen in de web­si­te­be­heer­der die het domein re­gi­streert. Dit ver­trou­wen mag op geen enkele manier in het gedrang komen door de nieuwe RDAP-ver­zoek­tech­no­lo­gie. Eind 2016 hebben een aantal re­gi­s­tries beroep aan­ge­te­kend tegen de door ICANN opgelegde im­ple­men­ta­tie­pe­ri­o­de, waardoor de or­ga­ni­sa­tie heeft besloten om con­trac­ten voor RDAP af te sluiten met re­gi­strars en do­mein­pro­vi­ders.

Ga naar hoofdmenu