Hittills har man kunnat hitta domäninnehavare med hjälp av Whois-tjänster, som baseras på protokollet med samma namn. Men 2015 fastställde IETF och ICANN det första RFC-protokollet för RDAP (Registration Data Access Protocol) som den huvudsakliga efterföljaren till Whois.

Vad är RDAP (Registration Data Access Protocol)?

Konceptet för RDAP (Registration Data Access Protocol) kom från en arbetsgrupp inom IETF (Internet Engineering Task Force). Efter en projektfas på nästan fyra år publicerades den första versionen av protokollprofilen (1.0) den 26 juli 2016. Dess egenskaper och tillämpningar beskrivs i olika Requests for Comments (RFC 7480-7484 och RFC 8056). RDAP erbjuder möjlighet att få tillgång till ytterligare information om grundläggande internetresurser, inklusive

  • Domännamn
  • IP-adresser eller
  • Autonoma systemnummer (ASN)

samt andra relaterade artiklar. Av denna anledning utgör Whois-alternativet grunden för att skicka förfrågningar till de olika domänregistren. Detta innefattar att förse din databas med exempelvis kontaktuppgifter till domänägarna, kontaktuppgifter till eventuella administratörer (Admin C) eller till och med adressen till den namnservrar som används, inklusive administratörens.

Varför utvecklades RDAP?

1982 publicerade IETF Whois-protokollet med målet att skapa en förfrågningstjänst för det som då kallades ARPANET. Det faktum att det fortfarande används ett kvarts sekel senare, nu för onlineförfrågningar, är något som har varit en nagel i ögat för många experter. Numera är den huvudsakliga kritiken mot Whois att det inte längre uppfyller de tekniska kraven för internet.

Ett av de största problemen är att Whois-protokollet inte kan hantera kodning och därför inte stöder icke-latinsk text. En annan stor nackdel är att åtkomsten till domändata inte sker via en säker anslutning och är oreglerad. Även anonyma användare får full åtkomst och kan komma åt e-postadresser och postadresser.

Projekt som Whois++-tillägget eller IRIS (Internet Registry Information Service) Denic Protocol lyckades åstadkomma vissa förbättringar, men de misslyckades dock med att etablera sig som ett stabilt alternativ till Whois. Efter lång tid och många diskussioner inom ICANN-gemenskapen om behovet av vidareutveckling** gav säkerhets- och stabilitetsrådgivande kommittén (SSAC) med sin säkerhetsrapport SAC 501 den avgörande knuffen som ledde till att RDAP-arbetsgruppen bildades i september 2011.

I januari 2023 inledde ICANN en global omröstning för att besluta om WHOIS officiellt skulle ersättas med RDAP. Det erforderliga antalet röster uppnåddes och beslutet fattades att officiellt genomföra övergången till RDAP. Från och med januari 2025 kommer DNS-register och registratorer inte längre att vara skyldiga att stödja WHOIS.

Hur fungerar RDAP?

För att implementera RDAP är det viktigt att först förstå hur protokollet fungerar, både på klient- och serversidan. För detta är det värt att ta en titt på RFC 7480 till 7484, där en minimal implementering av protokollet beskrivs i detalj. Dessutom finns det ytterligare RFC-dokument där RDAP-protokollets tillägg beskrivs. I följande avsnitt förklarar vi grovt hur protokollet fungerar via HTTPS enligt beskrivningen i RFC 7840.

Tips

För att underlätta protokollimplementeringen för utvecklare har ICANN tagit fram en RDAP-implementeringsguide.

Kundens uppgifter:

Det är inte alls komplicerat att implementera RDAP på klientsidan. RDAP bygger på HTTP och använder därför redan befintliga HTTP-metoder för att överföra data. Klienter kan skicka förfrågningar till servern med hjälp av metoderna GET och HEAD. Både GET- och HEAD-förfrågningar bör innehålla en ”Accept”-rubrik som anger vilka typer av JSON-filer som accepteras av klienten.

Serverns uppgifter:

Implementeringen är lite mer komplex på serversidan, eftersom servern måste hantera ett antal specialfall. Om begäran är framgångsrik ska servern returnera den begärda informationen i det begärda formatet med HTTP-statuskod 200 (OK). Vid GET-begäranden ska servern svara med den begärda ägarinformationen, och vid HEAD-begäranden ska den ange om den har information tillgänglig för denna domän.

Om den vet var den begärda informationen finns, men inte har den själv, ska den svara med någon av statuskoderna 301, 302, 303 eller 307. Den URL där informationen finns skickas då under HTTP-rubriken ”Location”.

Om servern inte kan behandla begäran eftersom den begärda informationen inte är tillgänglig, ska den svara med statuskoden 404 (Not Found). Om den begärda informationen finns, men servern av någon annan anledning inte vill svara, ska den svara med en lämplig statuskod från intervallet 400. Begäranden som innehåller fel och därför inte kan förstås som RDAP-begäranden ska besvaras med statuskoden 400 (Bad Request). I detta fall kan ytterligare information skickas i HTTP-entitetens kropp.

För mer detaljerad information om processen samt säkerhet och utvidgningsmöjligheter för protokollet kan du hänvisa till motsvarande RFC:er. Dessa finns länkade nedan.

Vad gör protokollet för åtkomst till registreringsdata annorlunda?

På många sätt har RDAP visat sig vara en förbättrad version av Whois. IEFT-arbetsgruppen har koncentrerat sig på det gamla protokollets svagheter, vilket innebär att den har lagt stort fokus på säkerhet, strukturering och internationalisering för det nya frågeprotokollet. Som ett resultat har flera nya funktioner tillkommit, bland annat:

  • Strukturerad begäran och svarssemantik (inklusive standardiserade felmeddelanden)
  • Säker åtkomst till de begärda kontaktuppgifterna (t.ex. via HTTPS)
  • Utbyggbarhet (t.ex. tillägg av utdataelement)
  • Bootstrapping-mekanism (med stöd av sökning efter en lämplig auktoritativ DNS-server)
  • Standardiserad vidarebefordran av förfrågningar
  • Webbaserad (HTTP) och REST -kompatibel
  • Okomplicerad översättning av utdata
  • Möjlighet att bevilja differentierad åtkomst till kontaktuppgifter

I många avseenden har Registration Data Access Protocol visat sig vara mycket mer flexibelt än sin föregångare. Medan Whois, som ett textbaserat protokoll, är beroende av TCP och den specifika TCP-porten (43), använder RDAP webbstandarden HTTP, eller till och med HTTPS. Detta innebär att all data levereras i ett standardiserat, maskinläsbart JSON-format. Detta innebär å ena sidan att RDAP ger större frihet när det gäller datakonsultationer, samtidigt som det blir enklare att programmera konsultationstjänster som kan kommunicera med olika registreringsmyndigheter och samtidigt mata ut den begärda datan på olika språk.

RDAP Whois
HTTP-baserad Textbaserad
Standardiserat JSON-format Inga kodningsscheman
Utdata är maskinläsbar och kan översättas på ett okomplicerat sätt Utdata är i ren data och kan därför inte bearbetas automatiskt vidare
Svaren skickas automatiskt till andra register Svaren innehåller ingen ytterligare registerinformation
Möjligt att definiera åtkomsträttigheter för olika grupper Olika typer av åtkomst till data är inte möjliga

Alternativ för olika typer av åtkomst – fortfarande ett diskussionsämne

En av de viktigaste nya funktionerna som implementerats i protokollet för åtkomst till registreringsdata är utan tvekan möjligheten att skapa olika åtkomsträttigheter för enskilda användargrupper. Detta gör det möjligt för registratorn att i detalj reglera vem som får se vilken information. Anonyma användare kan därmed endast få begränsad åtkomst, medan auktoriserade användare kan se hela datamängden. Detta är en aspekt där många ser ett behov av viktiga förtydliganden.

En av de frågor som detta väcker är bland annat vad man ska göra med åklagare som vill vara anonyma men samtidigt ha fullständig åtkomst. Dessutom finns det inga riktlinjer för om åtkomst till domändata i sådana fall också kan beviljas personer utanför landets gränser. Framför allt är prioriteringen att skydda användardata och det förtroende för webbplatsoperatören som registrerar domänen som följer med detta. Och detta förtroende får under inga omständigheter äventyras av den nya RDAP-förfrågningstekniken. I slutet av 2016 överklagade ett antal register den implementeringsperiod som ICANN hade fastställt, vilket har lett till att organisationen har beslutat att upprätta avtal för RDAP med registratorer och domänleverantörer.

Gå till huvudmeny