Hittills har man kunnat hitta do­mä­nin­ne­ha­va­re med hjälp av Whois-tjänster, som baseras på pro­to­kol­let med samma namn. Men 2015 fast­ställ­de IETF och ICANN det första RFC-pro­to­kol­let för RDAP (Re­gi­stra­tion Data Access Protocol) som den hu­vud­sak­li­ga ef­ter­föl­ja­ren till Whois.

Vad är RDAP (Re­gi­stra­tion Data Access Protocol)?

Konceptet för RDAP (Re­gi­stra­tion Data Access Protocol) kom från en ar­bets­grupp inom IETF (Internet Engi­ne­e­ring Task Force). Efter en pro­jekt­fas på nästan fyra år pub­li­ce­ra­des den första versionen av pro­to­koll­pro­fi­len (1.0) den 26 juli 2016. Dess egen­ska­per och tillämp­ning­ar beskrivs i olika Requests for Comments (RFC 7480-7484 och RFC 8056). RDAP erbjuder möjlighet att få tillgång till yt­ter­li­ga­re in­for­ma­tion om grund­läg­gan­de in­ter­ne­tre­sur­ser, inklusive

  • Domännamn
  • IP-adresser eller
  • Autonoma system­num­mer (ASN)

samt andra re­la­te­ra­de artiklar. Av denna anledning utgör Whois-al­ter­na­ti­vet grunden för att skicka för­fråg­ning­ar till de olika do­män­re­gist­ren. Detta in­ne­fat­tar att förse din databas med ex­em­pel­vis kon­takt­upp­gif­ter till do­mänä­gar­na, kon­takt­upp­gif­ter till even­tu­el­la ad­mi­nist­ra­tö­rer (Admin C) eller till och med adressen till den namn­serv­rar som används, inklusive ad­mi­nist­ra­tö­rens.

Varför ut­veck­la­des RDAP?

1982 pub­li­ce­ra­de IETF Whois-pro­to­kol­let med målet att skapa en för­fråg­nings­tjänst för det som då kallades ARPANET. Det faktum att det fort­fa­ran­de används ett kvarts sekel senare, nu för on­li­ne­för­fråg­ning­ar, är något som har varit en nagel i ögat för många experter. Numera är den hu­vud­sak­li­ga kritiken mot Whois att det inte längre uppfyller de tekniska kraven för internet.

Ett av de största problemen är att Whois-pro­to­kol­let 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 an­slut­ning och är oreglerad. Även anonyma användare får full åtkomst och kan komma åt e-post­a­dres­ser och post­a­dres­ser.

Projekt som Whois++-tillägget eller IRIS (Internet Registry In­for­ma­tion Service) Denic Protocol lyckades åstad­kom­ma vissa för­bätt­ring­ar, men de miss­lyc­ka­des dock med att etablera sig som ett stabilt al­ter­na­tiv till Whois. Efter lång tid och många dis­kus­sio­ner inom ICANN-ge­men­ska­pen om behovet av vidareut­veck­ling** gav säkerhets- och sta­bi­li­tets­råd­gi­van­de kommittén (SSAC) med sin sä­ker­hets­rap­port SAC 501 den avgörande knuffen som ledde till att RDAP-ar­bets­grup­pen bildades i september 2011.

I januari 2023 inledde ICANN en global om­röst­ning för att besluta om WHOIS of­fi­ci­ellt skulle ersättas med RDAP. Det er­for­der­li­ga antalet röster uppnåddes och beslutet fattades att of­fi­ci­ellt genomföra över­gång­en till RDAP. Från och med januari 2025 kommer DNS-register och re­gi­stra­to­rer inte längre att vara skyldiga att stödja WHOIS.

Hur fungerar RDAP?

För att im­ple­men­te­ra RDAP är det viktigt att först förstå hur pro­to­kol­let fungerar, både på klient- och ser­ver­si­dan. För detta är det värt att ta en titt på RFC 7480 till 7484, där en minimal im­ple­men­te­ring av pro­to­kol­let beskrivs i detalj. Dessutom finns det yt­ter­li­ga­re RFC-dokument där RDAP-pro­to­kol­lets tillägg beskrivs. I följande avsnitt förklarar vi grovt hur pro­to­kol­let fungerar via HTTPS enligt be­skriv­ning­en i RFC 7840.

Tips

För att un­der­lät­ta pro­to­kol­limple­men­te­ring­en för ut­veck­la­re har ICANN tagit fram en RDAP-im­ple­men­te­rings­gui­de.

Kundens uppgifter:

Det är inte alls kom­pli­ce­rat att im­ple­men­te­ra RDAP på kli­ent­si­dan. RDAP bygger på HTTP och använder därför redan be­fint­li­ga HTTP-metoder för att överföra data. Klienter kan skicka för­fråg­ning­ar till servern med hjälp av metoderna GET och HEAD. Både GET- och HEAD-för­fråg­ning­ar bör innehålla en ”Accept”-rubrik som anger vilka typer av JSON-filer som ac­cep­te­ras av klienten.

Serverns uppgifter:

Im­ple­men­te­ring­en är lite mer komplex på ser­ver­si­dan, eftersom servern måste hantera ett antal spe­ci­al­fall. Om begäran är fram­gångs­rik ska servern returnera den begärda in­for­ma­tio­nen i det begärda formatet med HTTP-statuskod 200 (OK). Vid GET-be­gä­ran­den ska servern svara med den begärda äga­rin­for­ma­tio­nen, och vid HEAD-be­gä­ran­den ska den ange om den har in­for­ma­tion till­gäng­lig för denna domän.

Om den vet var den begärda in­for­ma­tio­nen finns, men inte har den själv, ska den svara med någon av sta­tus­ko­der­na 301, 302, 303 eller 307. Den URL där in­for­ma­tio­nen finns skickas då under HTTP-rubriken ”Location”.

Om servern inte kan behandla begäran eftersom den begärda in­for­ma­tio­nen inte är till­gäng­lig, ska den svara med sta­tus­ko­den 404 (Not Found). Om den begärda in­for­ma­tio­nen finns, men servern av någon annan anledning inte vill svara, ska den svara med en lämplig statuskod från in­ter­val­let 400. Be­gä­ran­den som in­ne­hål­ler fel och därför inte kan förstås som RDAP-be­gä­ran­den ska besvaras med sta­tus­ko­den 400 (Bad Request). I detta fall kan yt­ter­li­ga­re in­for­ma­tion skickas i HTTP-en­ti­te­tens kropp.

För mer de­tal­je­rad in­for­ma­tion om processen samt säkerhet och ut­vidg­nings­möj­lig­he­ter för pro­to­kol­let kan du hänvisa till mot­sva­ran­de RFC:er. Dessa finns länkade nedan.

Vad gör pro­to­kol­let för åtkomst till re­gi­stre­rings­da­ta an­norlun­da?

På många sätt har RDAP visat sig vara en för­bätt­rad version av Whois. IEFT-ar­bets­grup­pen har kon­cen­tre­rat sig på det gamla pro­to­kol­lets svagheter, vilket innebär att den har lagt stort fokus på säkerhet, struk­tu­re­ring och in­ter­na­tio­na­li­se­ring för det nya frå­ge­pro­to­kol­let. Som ett resultat har flera nya funk­tio­ner till­kom­mit, bland annat:

  • Struk­tu­re­rad begäran och svars­se­man­tik (inklusive stan­dar­di­se­ra­de fel­med­de­lan­den)
  • Säker åtkomst till de begärda kon­takt­upp­gif­ter­na (t.ex. via HTTPS)
  • Ut­bygg­bar­het (t.ex. tillägg av ut­da­tae­le­ment)
  • Bootstrap­ping-mekanism (med stöd av sökning efter en lämplig auk­to­ri­ta­tiv DNS-server)
  • Stan­dar­di­se­rad vi­da­re­be­ford­ran av för­fråg­ning­ar
  • Web­ba­se­rad (HTTP) och REST -kom­pa­ti­bel
  • Okom­pli­ce­rad över­sätt­ning av utdata
  • Möjlighet att bevilja dif­fe­ren­ti­e­rad åtkomst till kon­takt­upp­gif­ter

I många avseenden har Re­gi­stra­tion Data Access Protocol visat sig vara mycket mer flexibelt än sin fö­re­gång­a­re. Medan Whois, som ett text­ba­se­rat protokoll, är beroende av TCP och den specifika TCP-porten (43), använder RDAP webb­stan­dar­den HTTP, eller till och med HTTPS. Detta innebär att all data levereras i ett stan­dar­di­se­rat, ma­skin­läs­bart JSON-format. Detta innebär å ena sidan att RDAP ger större frihet när det gäller da­ta­kon­sul­ta­tio­ner, samtidigt som det blir enklare att pro­gram­me­ra kon­sul­ta­tions­tjäns­ter som kan kom­mu­ni­ce­ra med olika re­gi­stre­rings­myn­dig­he­ter och samtidigt mata ut den begärda datan på olika språk.

RDAP Whois
HTTP-baserad Text­ba­se­rad
Stan­dar­di­se­rat JSON-format Inga kod­nings­sche­man
Utdata är ma­skin­läs­bar och kan över­sät­tas på ett okom­pli­ce­rat sätt Utdata är i ren data och kan därför inte bearbetas au­to­ma­tiskt vidare
Svaren skickas au­to­ma­tiskt till andra register Svaren in­ne­hål­ler ingen yt­ter­li­ga­re re­gis­terin­for­ma­tion
Möjligt att definiera åt­komsträt­tig­he­ter för olika grupper Olika typer av åtkomst till data är inte möjliga

Al­ter­na­tiv för olika typer av åtkomst – fort­fa­ran­de ett dis­kus­sions­äm­ne

En av de vik­ti­gas­te nya funk­tio­ner­na som im­ple­men­te­rats i pro­to­kol­let för åtkomst till re­gi­stre­rings­da­ta är utan tvekan möj­lig­he­ten att skapa olika åt­komsträt­tig­he­ter för enskilda an­vän­dar­grup­per. Detta gör det möjligt för re­gi­stra­torn att i detalj reglera vem som får se vilken in­for­ma­tion. Anonyma användare kan därmed endast få begränsad åtkomst, medan auk­to­ri­se­ra­de användare kan se hela da­ta­mäng­den. Detta är en aspekt där många ser ett behov av viktiga för­tyd­li­gan­den.

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 full­stän­dig åtkomst. Dessutom finns det inga rikt­lin­jer för om åtkomst till domändata i sådana fall också kan beviljas personer utanför landets gränser. Framför allt är pri­o­ri­te­ring­en att skydda an­vän­dar­da­ta och det för­tro­en­de för webb­platso­pe­ra­tö­ren som re­gi­stre­rar domänen som följer med detta. Och detta för­tro­en­de får under inga om­stän­dig­he­ter äventyras av den nya RDAP-för­fråg­nings­tek­ni­ken. I slutet av 2016 över­kla­ga­de ett antal register den im­ple­men­te­rings­pe­ri­od som ICANN hade fast­ställt, vilket har lett till att or­ga­ni­sa­tio­nen har beslutat att upprätta avtal för RDAP med re­gi­stra­to­rer och do­män­le­ve­ran­tö­rer.

Gå till huvudmeny