Hvad er Re­gi­stra­tion Data Access Protocol (RDAP)?

Indtil nu har man kunnet finde en do­mæ­ne­ha­ver ved hjælp af Whois-tjenester, som er baseret på pro­tokol­len af samme navn. I 2015 fastlagde IETF og ICANN imid­ler­tid den første RFC for RDAP-pro­tokol­len (Re­gi­stra­tion Data Access Protocol) som den primære ef­ter­føl­ger til Whois.

Hvad er Re­gi­stra­tion Data Access Protocol (RDAP)?

Konceptet bag Re­gi­stra­tion Data Access Protocol (RDAP) stammer fra en ar­bejds­grup­pe under Internet En­gi­ne­e­ring Task Force (IETF). Efter en pro­jekt­fa­se på næsten fire år udkom den første version af pro­tokol­pro­fi­len (1.0) den 26. juli 2016. Dens egen­ska­ber og an­ven­del­ses­mu­lig­he­der er beskrevet i de for­skel­li­ge Requests for Comments (RFC 7480-7484 og RFC 8056). RDAP giver mulighed for at få adgang til yder­li­ge­re op­lys­nin­ger om grund­læg­gen­de in­ter­netres­sour­cer, herunder

• Do­mæ­ne­nav­ne
• IP-adresser eller
• Autonome sy­stem­num­re (ASN’er)

samt andre re­la­te­re­de artikler. Derfor danner Whois-al­ter­na­ti­vet grund­la­get for at sende fo­re­spørgs­ler til de for­skel­li­ge do­mæ­ne­re­gi­stre. Dette omfatter blandt andet at forsyne din database med kon­tak­top­lys­nin­ger på do­mæ­ne­e­jer­ne, kon­tak­top­lys­nin­ger på even­tu­el­le ad­mi­ni­stra­to­rer (Admin C) eller endda adressen på den anvendte nav­ne­ser­ver, herunder ad­mi­ni­stra­to­rens adresse.

Hvorfor blev RDAP udviklet?

Allerede i 1982 of­fent­lig­gjor­de IETF Whois-pro­tokol­len med det formål at skabe en fo­re­spørgsels­ser­vi­ce til det, der dengang hed ARPANET. Det faktum, at den stadig er i brug et kvart år­hund­re­de senere – nu til on­li­ne­fo­re­spørgs­ler – har været en torn i øjet på mange eksperter. I dag går den største kritik af Whois på, at den ikke længere opfylder in­ter­net­tets tekniske krav.

Et af de største problemer er, at Whois-pro­tokol­len ikke un­der­støt­ter tegnsæt, og derfor ikke un­der­støt­ter ikke-latinsk tekst. En anden væsentlig ulempe er, at adgangen til do­mæ­neda­ta­e­ne ikke foregår via en sikker for­bin­del­se og er ur­e­gu­le­ret. Selv anonyme brugere får fuld adgang og kan få fat i e-mail- og po­stadres­ser.

Projekter som Whois++-ud­vi­del­sen eller IRIS (Internet Registry In­for­ma­tion Service) Denic-pro­tokol­len formåede at indføre visse for­bed­rin­ger, men det lykkedes dem dog ikke at etablere sig som et solidt al­ter­na­tiv til Whois. Efter lang tid og mange dis­kus­sio­ner inden for ICANN-samfundet om nød­ven­dig­he­den af yder­li­ge­reudvikling** gav Security and Stability Advisory Committee (SSAC) med sin SAC 501-sik­ker­heds­rap­port det afgørende skub til at oprette RDAP-ar­bejds­grup­pen i september 2011.

I januar 2023 iværk­sat­te ICANN en global af­stem­ning for at afgøre, om WHOIS officielt skulle erstattes af RDAP. Det nød­ven­di­ge antal stemmer blev opnået, og det blev besluttet officielt at gen­nem­fø­re over­gan­gen til RDAP. Fra januar 2025 vil DNS-registre og -re­gi­stra­to­rer ikke længere være for­plig­tet til at un­der­støt­te WHOIS.

Hvordan fungerer RDAP?

For at kunne im­ple­men­te­re RDAP er det vigtigt først at forstå, hvordan pro­tokol­len fungerer, både på klient- og ser­ver­si­den. I den for­bin­del­se er det en god idé at se nærmere på RFC 7480 til 7484, hvor en minimal im­ple­men­te­ring af pro­tokol­len beskrives i detaljer. Derudover findes der yder­li­ge­re RFC’er, hvor ud­vi­del­ser af RDAP-pro­tokol­len beskrives. I det følgende afsnit forklarer vi kort, hvordan pro­tokol­len fungerer via HTTPS som beskrevet i RFC 7840.

Kundens opgaver:

Det er slet ikke kom­pli­ce­ret at im­ple­men­te­re RDAP på kli­ent­si­den. RDAP er baseret på HTTP og bruger derfor de ek­si­ste­ren­de HTTP-metoder til at overføre data. Klienter kan sende an­mod­nin­ger til serveren ved hjælp af GET- og HEAD-metoderne. Både GET- og HEAD-an­mod­nin­ger skal indeholde en »Accept«-header, der angiver, hvilke typer JSON-filer klienten ac­cep­te­rer.

Serverens opgaver:

Im­ple­men­te­rin­gen er lidt mere kompleks på ser­ver­si­den, da serveren skal håndtere en del særlige tilfælde. Hvis an­mod­nin­gen lykkes, skal serveren returnere de ønskede data i det ønskede format med HTTP-sta­tus­ko­de 200 (OK). Ved GET-an­mod­nin­ger skal serveren svare med de ønskede ejerdata, og ved HEAD-an­mod­nin­ger skal den angive, om der findes data til­gæn­ge­li­ge for dette domæne.

Hvis den ved, hvor de ønskede data befinder sig, men ikke selv har dem, skal den svare med en af sta­tus­ko­der­ne 301, 302, 303 eller 307. Den URL, hvor dataene kan findes, sendes derefter under HTTP-headeren »Location«.

Hvis serveren ikke kan behandle an­mod­nin­gen, fordi de ønskede data ikke er til­gæn­ge­li­ge, skal den svare med sta­tus­ko­de 404 (Not Found). Hvis de ønskede data findes, men serveren af en eller anden grund ikke ønsker at svare, skal den svare med en passende sta­tus­ko­de fra 400-serien. An­mod­nin­ger, der in­de­hol­der fejl og derfor ikke kan fortolkes som RDAP-an­mod­nin­ger, skal besvares med sta­tus­ko­de 400 (Bad Request). I dette tilfælde kan yder­li­ge­re op­lys­nin­ger sendes i HTTP-en­ti­te­tens brødtekst.

For mere de­tal­je­re­de op­lys­nin­ger om processen samt pro­tokol­lens sikkerhed og ud­vi­del­ses­mu­lig­he­der henvises til de relevante RFC’er. Der er links til disse nedenfor.

• RFC 7840: Brug af HTTP
• RFC 7841: Sik­ker­hed­s­tje­ne­ster
• RFC 7842: Fo­re­spørgsels­for­mat
• RFC 7843: JSON-svar
• RFC 7844: Find de au­to­ri­ta­ti­ve re­gi­stre­rings­da­ta

Hvad adskiller pro­tokol­len for adgang til re­gi­stre­rings­da­ta fra andre?

På mange måder har RDAP vist sig at være en forbedret version af Whois. IETF-ar­bejds­grup­pen har sat fokus på det gamle protokols svagheder, hvilket betyder, at den i høj grad har kon­cen­tre­ret sig om aspekter som sikkerhed, struk­tu­re­ring og in­ter­na­tio­na­li­se­ring i for­bin­del­se med den nye fo­re­spørgselspro­tokol. Dette har re­sul­te­ret i en række nye funk­tio­ner, herunder:

• Struk­tu­re­ret semantik for fo­re­spørgs­ler og svar (herunder stan­dar­di­se­re­de fejl­med­del­el­ser)
• Sikker adgang til de anmodede kon­tak­top­lys­nin­ger (f.eks. via HTTPS)
• Ud­vi­del­ses­mu­lig­he­der (f.eks. til­fø­jel­se af out­pu­t­e­le­men­ter)
• »Boot­strap­ping«-mekanisme (un­der­støt­tet af søgningen efter en passende au­to­ri­ta­tiv DNS-server)
• Stan­dar­di­se­ret vi­de­re­sen­del­se af fo­re­spørgs­ler
• Web­ba­se­ret (HTTP) og REST -kom­pa­ti­bel
• Ukom­pli­ce­ret over­sæt­tel­se af out­put­da­ta
• Mulighed for at give dif­fe­ren­ti­e­ret adgang til kon­tak­top­lys­nin­ger

På mange måder har Re­gi­stra­tion Data Access Protocol vist sig at være langt mere flek­si­belt end sin forgænger. Mens Whois, som er en tekst­ba­se­ret protokol, er afhængig af TCP og den spe­ci­fik­ke TCP-port (43), anvender RDAP web­s­tan­dar­den HTTP eller endda HTTPS. Det betyder, at alle data leveres i et stan­dar­di­se­ret, ma­skin­læs­bart JSON-format. Dette betyder, at RDAP på den ene side giver større frihed, når det gælder da­ta­fo­re­spørgs­ler, samtidig med at det gør det lettere at pro­gram­me­re fo­re­spørgsels-tjenester, der kan kom­mu­ni­ke­re med de for­skel­li­ge re­gi­stre­ringsmyn­dig­he­der, mens de anmodede data udlæses på for­skel­li­ge sprog.

Mulighed for for­skel­li­ge former for adgang – stadig et emne til dis­kus­sion

En af de uden tvivl vigtigste nye funk­tio­ner, der er blevet im­ple­men­te­ret i pro­tokol­len for adgang til re­gi­stre­rings­da­ta, er mu­lig­he­den for at fastlægge for­skel­li­ge ad­gangs­ret­tig­he­der for de enkelte bru­ger­grup­per. Dette giver re­gi­stra­to­ren mulighed for nøje at regulere, hvem der får adgang til hvilke op­lys­nin­ger. Dermed kan anonyme brugere kun få begrænset adgang, mens au­to­ri­se­re­de brugere kan se hele da­ta­sæt­tet. Dette er et område, hvor mange mener, at der er behov for afgørende præ­ci­se­rin­ger.

Et af de spørgsmål, det blandt andet rejser, er, hvordan man skal forholde sig til straf­fe­ret­li­ge anklagere, der ønsker at forblive anonyme, samtidig med at de har fuld adgang. Der findes desuden ingen ret­nings­linjer for, om adgang til do­mæ­neda­ta i et sådant tilfælde også kan gives til personer uden for landets grænser. Frem for alt er pri­o­ri­te­ten be­skyt­tel­sen af bru­ger­da­ta og den tillid til web­s­teds­o­pe­ra­tø­ren, der re­gi­stre­rer domænet, som følger med dette. Og denne tillid må på ingen måde kom­pro­mit­te­res af den nye RDAP-an­mod­nings­tek­no­lo­gi. I slut­nin­gen af 2016 ap­pel­le­re­de en række registre mod den im­ple­men­te­rings­pe­ri­o­de, som ICANN havde pålagt, og dette har betydet, at or­ga­ni­sa­tio­nen har besluttet at indgå kon­trak­ter om RDAP med re­gi­stra­to­rer og do­mæ­neud­by­de­re.