Tot nu toe kon een domeinhouder 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 (Registration Data Access Protocol) vastgesteld als de belangrijkste opvolger van Whois.

Wat is het Registration Data Access Protocol (RDAP)?

Het concept van het Registration Data Access Protocol (RDAP) is afkomstig van een werkgroep van de Internet Engineering Task Force (IETF). Na een projectfase van bijna vier jaar verscheen op 26 juli 2016 de eerste versie van het protocolprofiel (1.0). De kenmerken en toepassingen ervan worden beschreven in de verschillende Requests for Comments (RFC 7480-7484 en RFC 8056). RDAP biedt de mogelijkheid om toegang te krijgen tot meer informatie over basisinternetbronnen, waaronder

  • Domeinnamen
  • IP-adressen of
  • Autonomous System Numbers (ASN’s)

evenals andere gerelateerde artikelen. Om deze reden vormt het Whois-alternatief de basis voor het verzenden van query’s naar de verschillende domeinregisters. Dit omvat het voorzien van uw database met bijvoorbeeld contactgegevens van de domeineigenaren, contactgegevens van eventuele beheerders (Admin C) of zelfs het adres van de gebruikte naamserver, inclusief dat van de beheerder.

Waarom is RDAP ontwikkeld?

In 1982 publiceerde de IETF het Whois-protocol met als doel een opvragingsdienst te creëren voor wat toen ARPANET heette. Het feit dat het een kwart eeuw later nog steeds in gebruik is, nu voor online opvragingen, is voor veel deskundigen een doorn in het oog. Tegenwoordig is de belangrijkste kritiek op Whois dat het niet meer voldoet aan de technische eisen van het internet.

Een van de grootste problemen is dat het Whois-protocol niet met codering kan werken en daarom geen ondersteuning biedt voor niet-Latijnse teksten. Een ander groot nadeel is dat de toegang tot de domeingegevens niet via een beveiligde verbinding verloopt en niet gereguleerd is. Zelfs anonieme gebruikers krijgen volledige toegang en kunnen e-mailadressen en postadressen achterhalen.

Projecten zoals de Whois++-extensie of het IRIS (Internet Registry Information Service) Denic Protocol hebben weliswaar enkele verbeteringen opgeleverd, maar zijn er niet in geslaagd zich te profileren als een solide alternatief voor Whois. Na een lange tijd en veel discussies binnen de ICANN-gemeenschap over de noodzaak van verdereontwikkeling**, gaf het Security and Stability Advisory Committee (SSAC) met zijn SAC 501-beveiligingsrapport de doorslaggevende impuls om de RDAP-werkgroep in september 2011 tot leven te brengen.

In januari 2023 heeft ICANN een wereldwijde 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 registrars WHOIS niet langer te ondersteunen.

Hoe werkt RDAP?

Om RDAP te implementeren, is het belangrijk om eerst te begrijpen hoe het protocol werkt, zowel aan de client- als aan de serverzijde. Hiervoor is het de moeite waard om RFC’s 7480 tot 7484 te raadplegen, waarin een minimale implementatie van het protocol gedetailleerd wordt beschreven. Daarnaast zijn er nog andere RFC’s waarin RDAP-protocolextensies worden beschreven. In het volgende gedeelte leggen we in grote lijnen uit hoe het protocol via HTTPS werkt, zoals beschreven in RFC 7840.

Tip

Om de implementatie van het protocol voor ontwikkelaars te vergemakkelijken, heeft ICANN een RDAP-implementatiegids opgesteld.

De taken van de klant:

Het implementeren van RDAP aan de clientzijde is helemaal niet ingewikkeld. 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 geaccepteerd.

De taken van de server:

De implementatie is iets complexer aan de serverzijde, omdat de server een aantal speciale gevallen moet afhandelen. Als het verzoek succesvol is, moet de server de gevraagde gegevens in het gevraagde formaat retourneren met HTTP-statuscode 200 (OK). Bij GET-verzoeken moet de server reageren met de gevraagde eigenaarsgegevens en bij HEAD-verzoeken moet hij aangeven of hij gegevens beschikbaar 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 statuscodes 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 beschikbaar zijn, moet hij reageren met de statuscode 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 statuscode uit de reeks 400. Verzoeken die fouten bevatten en daarom niet als RDAP-verzoeken kunnen worden begrepen, moeten worden beantwoord met de statuscode 400 (Bad Request). In dit geval kan aanvullende informatie worden verzonden in de HTTP-entity body.

Voor meer gedetailleerde informatie over het proces en de beveiligings- en uitbreidingsmogelijkheden van het protocol kunt u de betreffende RFC’s raadplegen. Deze zijn hieronder gelinkt.

Wat maakt het Registration Data Access Protocol anders?

In veel opzichten is het RDAP een verbeterde versie van Whois gebleken. De IEFT-werkgroep heeft zich geconcentreerd op de zwakke punten van het oude protocol, wat betekent dat zij zich sterk heeft gericht op zaken als beveiliging, structurering en internationalisering voor het nieuwe queryprotocol. Als gevolg daarvan zijn er verschillende nieuwe functies ontstaan, waaronder:

  • Gestructureerde verzoek- en antwoordsemantiek (inclusief gestandaardiseerde foutmeldingen)
  • Veilige toegang tot de opgevraagde contactgegevens (bijvoorbeeld via HTTPS)
  • Uitbreidbaarheid (bijv. toevoeging van uitvoerelementen)
  • ‘Bootstrapping’-mechanisme (ondersteund door het zoeken naar een geschikte gezaghebbende DNS-server)
  • Gestandaardiseerde doorsturing van query’s
  • Webgebaseerd (HTTP) en REST-compatibel
  • Eenvoudige vertaling van uitvoergegevens
  • Mogelijkheid om gedifferentieerde toegang tot contactgegevens te verlenen

In veel opzichten is het Registration Data Access Protocol veel flexibeler gebleken dan zijn voorganger. Terwijl Whois, als tekstgebaseerd protocol, afhankelijk is van TCP en de specifieke TCP-poort (43), maakt RDAP gebruik van de webstandaard HTTP, of zelfs HTTPS. Dit betekent dat alle gegevens worden geleverd in een gestandaardiseerd, machinaal leesbaar JSON-formaat. Dit betekent enerzijds dat RDAP meer vrijheid biedt bij het opvragen van gegevens, terwijl het anderzijds ook gemakkelijker wordt om query-services te programmeren die kunnen communiceren met de verschillende registratieautoriteiten en de opgevraagde gegevens in verschillende talen kunnen weergeven.

RDAP Whois
HTTP-gebaseerd tekstgebaseerd
Gestandaardiseerd JSON-formaat Geen coderingsschema’s
Uitvoergegevens zijn machinaal leesbaar en kunnen op een eenvoudige manier worden vertaald Uitvoergegevens zijn in platte tekst en kunnen daarom niet automatisch verder worden verwerkt
Antwoorden worden automatisch naar andere registers gestuurd Antwoorden bevatten geen aanvullende registerinformatie
Mogelijkheid om toegangsrechten voor verschillende groepen te definiëren Verschillende soorten toegang tot gegevens zijn niet mogelijk

Optie voor verschillende soorten toegang – nog steeds een onderwerp van discussie

Een van de belangrijkste nieuwe functies die in het Registration Data Access Protocol is geïmplementeerd, is ongetwijfeld de mogelijkheid om verschillende toegangsrechten voor individuele gebruikersgroepen in te stellen. Hierdoor kan de registrar gedetailleerd regelen wie welke informatie te zien krijgt. Anonieme gebruikers krijgen zo slechts beperkte toegang, terwijl geautoriseerde gebruikers de volledige dataset kunnen bekijken. Dit is een aspect waar volgens veel mensen nog veel onduidelijkheid over bestaat.

Een van de vragen die dit oproept, is onder andere wat er moet gebeuren met strafrechtelijke aanklagers, die anoniem willen blijven en tegelijkertijd volledige toegangsrechten willen hebben. Bovendien zijn er geen richtlijnen over de vraag of in een dergelijk geval ook toegang tot de domeingegevens mag worden verleend aan personen buiten de landsgrenzen. De prioriteit ligt bovenal bij de bescherming van gebruikersgegevens en het vertrouwen in de websitebeheerder die het domein registreert. Dit vertrouwen mag op geen enkele manier in het gedrang komen door de nieuwe RDAP-verzoektechnologie. Eind 2016 hebben een aantal registries beroep aangetekend tegen de door ICANN opgelegde implementatieperiode, waardoor de organisatie heeft besloten om contracten voor RDAP af te sluiten met registrars en domeinproviders.

Ga naar hoofdmenu