Volwaardige RDAP-dienst straks verplicht voor generieke topleveldomeinen
Verwachting is dat huidige Whois-infrastructuur over een paar jaar vervangen wordt door RDAP
Verwachting is dat huidige Whois-infrastructuur over een paar jaar vervangen wordt door RDAP
Zoals het er nu naar uitziet, wordt ondersteuning voor het Registration Data Access Protocol (RDAP) in de loop van 2025 verplicht voor alle generieke topleveldomeinen (gTLD's) en vervalt de verplichting voor Whois. Deze verandering is onderdeel van de nieuwe Registry Agreement (RA) en Registrar Accreditation Agreement (RAA), waar ICANN nu de laatste hand aan legt.
De verwachting is dat alle domeinnaaminformatiesystemen de komende jaren naar RDAP verschuiven. Omdat het oude Whois-protocol geen meerwaarde biedt ten opzichte van RDAP, betekent dat hoogst waarschijnlijk het einde van de huidige Whois-infrastructuur.
Gegevens over domeinnamen, zoals de nameservers en informatie over de houder, worden gepubliceerd in wat een Registration Data Directory Service heet. Voor het benaderen van die dienst wordt traditioneel het ongestructureerde Whois-protocol gebruikt. Het moderne RDAP-protocol maakt het mogelijk informatie in gestructureerde vorm op te vragen.
De beschikbaarheid van een RDAP-server was voor gTLD's al verplicht sinds 2019. De nieuwe eisen gaan dan ook over een volwaardige dienst die de huidige Whois-dienst moet vervangen. Concreet betekent dat dat nu ook harde eisen aan de servicelevels worden gesteld – denk aan de beschikbaarheid, responsetijd en actualiteit van de dienst. Daarbij vervalt de huidige verplichting tot het aanbieden van een volwaardige Whois-dienst.
De verwachting is dat vooral de grote commerciële registry's als eerste hun oude Whois-systemen uitzetten en opruimen. Met de verplichting tot het aanbieden van een volwaardige RDAP-dienst verwordt Whois immers tot een extra kostenpost. Aangezien RDAP als de vervanger van Whois fungeert, biedt het in de lucht houden van een Whois-dienst naast de RDAP-dienst geen meerwaarde. De verwachting is dan ook dat de Whois-infrastructuur vanaf 2025 zal desintegreren. En daarmee wordt RDAP voor alle zones urgent.
Hoewel de registry's van landendomeinen (ccTLD's) niet onder het regime van ICANN vallen – voor ons zijn vooral de RFC's van de IETF leidend – volgen de ccTLD-registry's het ICANN-beleid in veel dingen wel (zij het vaak op eigen tempo).
Als technisch beheerder van de .amsterdam- en .politie-domeinen – generieke toplevels die dus wel onder ICANN resorteren – hebben wij 3 jaar geleden voor die 2 zones een eerste RDAP-dienst beschikbaar gemaakt. Voor het .nl-domein is RDAP bèta nu beschikbaar op rdap.sidn.nl.
De aankomende verplichting van een volwaardige RDAP-dienst plus de waarschijnlijke afbraak van de Whois-infrastructuur, maken dat registry's, registrars en anderen die toepassingen op Whois hebben gebouwd, die de komende jaren naar RDAP moeten overzetten.
Voor ons is dit alles reden om nu daadwerkelijk onze RDAP-dienst voor de .nl-zone te lanceren. "We hebben zojuist de laatste hand gelegd aan de implementatie," vertelt Pim Pastoors, productmanager bij SIDN. "We zijn deze week live gegaan. Intern gebruiken we RDAP al langer, dus de techniek hadden we al in de vingers."
Voorbeeld van een eigen toepassing die we naar RDAP moeten overzetten, is de Whois-zoekdienst voor de .nl-zone. Het zou zomaar kunnen dat we dezelfde naam blijven gebruiken, waarmee de Whois functioneel beschikbaar blijft. Alleen de techniek erachter wordt dan bediend door RDAP.
Consequenties voor onze Whois-dienst zijn er voorlopig in ieder geval niet. "Op dit moment is de belangstelling voor de bestaande RDAP-dienst voor .amsterdam en .politie nog steeds beperkt," zegt Pastoors. "En registry's en registrars hebben nog een paar jaar om hun applicaties om te bouwen. Pas als RDAP door iedereen gebruikt wordt en Whois duidelijk op zijn retour is, kunnen we gaan nadenken over het op termijn uitfaseren van onze Whois-dienst. Tot die tijd gaan we vooral goed in de gaten houden wat er op die 2 diensten gebeurt."
Voor wie nog niet bekend is met RDAP: dit protocol – gedefinieerd in de RFC's 7480/7481/9082/9083/9224 – is de verbeterde opvolger en vervanger van Whois. Het nieuwe protocol ondervangt de belangrijkste nadelen van Whois:
Het Whois-protocol is heel erg simpel (té simpel): het bevat geen enkele vorm van beveiliging of authenticatie, er is niets vastgelegd over het formaat en de inhoud van de queries en responses, en het ondersteunt geen Internationalized Domain Names (IDN's). De specificatie dateert uit 1982; Whois is dus al veertig jaar oud.
Niemand heeft het complete, actuele overzicht van alle domeinnaaminformatie. Sommige Whois-servers bevatten zelf alle informatie over hun domein ("thick"), andere refereren alleen naar de (autoritatieve) server van de registrar ("thin").
Het nuttigst voor derden is de contact-informatie, maar die is ook gevoelig voor misbruik. Dat is provisorisch opgelost door de 'domain privacy'-diensten (waarbij de contact-informatie wordt vervangen door de gegevens van de registrar) en/of limitering van het verkeer (rate limiting).
De response-data zijn volledig ongestructureerd, wat een wildgroei aan kleine conventies in structuur en (tekst-)formaten opleverde. Zelfs de nameservers zijn verschillend aangegeven. Daarmee kan Whois-output eigenlijk alleen door mensen geïnterpreteerd worden en alleen met veel moeite (scraping) door andere computers.
RDAP is een modern protocol dat probeert zo veel mogelijk van de problemen van Whois op te lossen. Waar Whois een uiterst basaal protocol is gebaseerd op de principes van het oeroude finger, gaat het bij RDAP om een webservice gebaseerd op een RESTful-interface. Dat betekent dat je een RDAP-server kunt benaderen via een (publieke) web-API, daarbij gebruikmakend van dezelfde opdrachten (GET, PUT, DELETE en dergelijke) als bij HTTP.
Ander cruciaal verschil met Whois is dat RDAP gestructureerde data als antwoord terugstuurt, en wel in het moderne, makkelijk leesbare en verwerkbare JSON-formaat (dit in tegenstelling tot XML, dat dusdanig geformaliseerd is dat het alleen nog voor machine-naar-machine-uitwisseling geschikt is).
Om vast te stellen welke datavelden het JSON-formaat voor RDAP zou moeten bevatten, hebben de bedenkers van RDAP alle bestaande informatietypen in de Whois-servers geanalyseerd. Vandaaruit is een dataformaat ontwikkeld dat zowel voor de registry's van domeinnamen als die van internet numbers (de RIR's en LIR's) zou moeten werken. In RFC 7485 kun je lezen hoe men tewerk ging bij die inventarisatie en wat de uitkomsten waren. RFC 9083 geeft een uitgebreide beschrijving van alle objecten en datastructuren voor de RDAP-responses, maar die specificatie is meer geschikt voor programmeurs. Het RDAP-JSON-register bij IANA biedt wat dat betreft een toegankelijker overzicht.
Hieronder zie je de (tekstuele) output van het RDAP-informatieverzoek voor het domein sidn.nl, te bevragen via: https://rdap.sidn.nl/domain/sidn.nl.
{ "rdapConformance": [ "icann_rdap_response_profile_0" ], "objectClassName": "domain", "notices": [ { "title": "Copyright notice", "description": [ "Auteursrechtvoorbehoud: Niets uit deze publicatie mag zonder voorafgaande uitdrukkelijke toestemming van SIDN worden verveelvoudigd, openbaar gemaakt, worden opgeslagen in een gegevensbestand of worden overgezonden, in welke vorm dan ook, elektronisch, mechanisch, door middel van opname of anderszins. Voor registrars geldt dit voorbehoud onverkort, behoudens redelijkerwijs noodzakelijke verveelvoudigingen of openbaarmakingen ten behoeve van de werkzaamheden van registrars, zoals vermeld in de 'Algemene voorwaarden voor registrars'. Elk gebruik van deze informatie voor commerciële of reclamedoeleinden of soortgelijke activiteiten, is expliciet verboden en tegen overtreding van dat verbod zal worden opgetreden. Stichting Internet Domeinregistratie Nederland (SIDN) verzoekt te worden geïnformeerd bij constatering van dergelijke activiteiten of enig vermoeden daarvan. © Stichting Internet Domeinregistratie Nederland (SIDN) Auteurswet, geschriftenbescherming (art. 10 lid 1 sub 1).", "Copyright notice: No part of this publication may be reproduced, published, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, without prior permission of the Foundation for Internet Domain Registration in the Netherlands (SIDN). These restrictions apply equally to registrars, except in that reproductions and publications are permitted insofar as they are reasonable, necessary and solely in the context of the registration activities referred to in the General Terms and Conditions for .nl Registrars. Any use of this material for advertising, targeting commercial offers or similar activities is explicitly forbidden and liable to result in legal action. Anyone who is aware or suspects that such activities are taking place is asked to inform the Foundation for Internet Domain Registration in the Netherlands. © The Foundation for Internet Domain Registration in the Netherlands (SIDN) Dutch Copyright Act, protection of authors' rights (Section 10, subsection 1, clause 1)." ] }, { "description": [ "Administratie door: SIDN", "Record maintained by: SIDN" ] } ], "lang": "nl-NL", "events": [ { "eventAction": "registration", "eventDate": "1999-11-18T12:47:20Z" }, { "eventAction": "last changed", "eventDate": "2021-10-14T09:55:57Z" }, { "eventAction": "last update of RDAP database", "eventDate": "2022-12-22T11:51:17Z" } ], "status": [ "locked" ], "ldhName": "sidn.nl", "secureDNS": { "delegationSigned": true, "dsData": [ { "keyTag": 62949, "algorithm": 13, "digestType": 2, "digest": "FBF66B8D019C1EEC2779B7DBFBFF090CA0F3704DCBD8D76AA80974186F110E91" } ] }, "entities": [ { "objectClassName": "entity", "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "" ], [ "email", {}, "text", "support@sidn.nl" ] ] ], "roles": [ "administrative" ] }, { "objectClassName": "entity", "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "" ], [ "email", {}, "text", "support@sidn.nl" ] ] ], "roles": [ "technical" ] }, { "objectClassName": "entity", "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "Stichting Internet Domeinregistratie Nederland" ], [ "adr", {}, "text", [ "", "", "Meander 501", "ARNHEM", "", "6825MD", "NL" ] ] ] ], "roles": [ "registrant" ] }, { "objectClassName": "entity", "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "Stichting Internet Domeinregistratie Nederland" ], [ "adr", {}, "text", [ "", "", "Meander 501", "Arnhem", "", "6825MD", "NL" ] ] ] ], "entities": [ { "objectClassName": "entity", "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "" ], [ "tel", { "type": "voice" }, "text", "+31.263525555" ], [ "email", {}, "text", "abuse@sidn.nl" ] ] ], "roles": [ "abuse" ] } ], "roles": [ "registrar" ] } ], "nameservers": [ { "ldhName": "ns5.sidn.nl", "unicodeName": "ns5.sidn.nl", "ipAddresses": { "v4": [ "145.40.68.55" ], "v6": [ "2604:1380:4601:6300:0:0:0:1" ] } }, { "ldhName": "ns3.sidn.nl", "unicodeName": "ns3.sidn.nl", "ipAddresses": { "v4": [ "194.0.30.2" ], "v6": [ "2001:678:34:0:194:0:30:2" ] } }, { "ldhName": "ns4.sidn.nl", "unicodeName": "ns4.sidn.nl", "ipAddresses": { "v6": [ "2001:7b8:62b:1:0:d4ff:fe72:786c" ], "v4": [ "212.114.120.108" ] } } ] }
Het laatste grote probleem met de huidige directory services is dat de contact-informatie niet meer vrijgegeven kan worden: dat levert vooral spam en cold-callers op en botst met de huidige privacywetgeving (de GDPR). Tegelijkertijd zijn er verschillende valide use cases waarbij je privacygevoelige gegevens wel beschikbaar zou willen maken voor specifieke belanghebbenden. Denk aan onderzoek, de koop en verkoop van domeinnamen/adresblokken, abuse en juridische aangelegenheden.
RDAP lost dat op door je in te laten loggen. Dat betekent dat beheerders van een RDAP-dienst na authenticatie verschillende soorten informatie voor verschillende rollen kunnen vrijgeven. Denk aan de politie en andere overheidsdiensten die contact-informatie zoeken bij domeinnamen en IP-adressen.
"Aan de implementatie van die authenticatie wordt nog gewerkt," vertelt Pastoors. "Het zou kunnen dat je straks inlogt op een website en dat je RDAP-verzoek vervolgens met je credentials wordt doorgesluisd naar de juiste autoritatieve RDAP-server."
"Maar zo ver zijn we nog niet: We hebben met z'n allen nog een paar jaar om onze bestaande diensten naar RDAP te migreren. Daarna kunnen we op deze nieuwe infrastructuur gaan bouwen."