Jsou to už čtyři roky, co jsem zde na blogu poprvé zmiňoval iniciativu na vytvoření alternativního protokolu pro službu WHOIS. Tento „vousatý“ protokol z roku 1982 přežil několik pokusů o jeho nahrazení (1995 – Whois++, 1997 – RWhois, 2005 – IRIS) a bude zajímavé sledovat, zda-li mu stávající iniciativa zasadí pověstný poslední hřebíček do rakve.

Určitou naději jí dává fakt, že se jedná o první iniciativu, která nepřišla z roztříštěného doménového světa, ale z konsolidovaného světa pěti adresních registrů. Dva z nich, ARIN a RIPE, v letech 2009 a 2010 představily hotové řešení jako alternativu ke stávajícímu WHOIS a toto řešení si hned našlo poměrně velké množství uživatelů. V reakci na tento úspěch se rozjel v roce 2011 proces standardizace tohoto řešení v rámci organizace IETF, konkrétně pracovní skupiny WEIRDS a výsledkem bylo úspěšné publikování standardu nazvaného RDAP (Registration Data Access Protocol) v březnu loňského roku. No a jelikož naší strategií je dávat novým technologiím šanci, rozhodli jsme se implementovat tento nový protokol i do našeho open source registračního systému FRED.

První verzi naší implementace jsme založili ještě na draftu rozpracovaného standardu a tak bylo po jeho finálním publikování nutné znovu se k naší implementaci vrátit a doladit několik drobností. Nyní je ale již hotovo a služba je uživatelům plně k dispozici v souladu se standardem.

Jaké jsou hlavní vlastnosti nového protokolu si ukážeme na srovnání s jeho předchůdcem. Původní WHOIS protokol, aktuálně specifikovaný v RFC3912, je velice primitivní a v zásadě pouze umožňuje otevřít spojení na TCP portu 43, poslat tam libovolný textový dotaz a vyzvednout si textovou odpověď. Problémy tohoto přístupu jsou evidentní. Neexistuje jednoznačná definice jak mají vypadat dotazy ani v jakém formátu má klient očekávat odpověď. V současném mnohojazyčném Internetu není možné signalizovat, v jakém jazyce předávat data. Neexistuje možnost autentizovat uživatele a podle úrovně autorizace poskytnout taková data, na které má tento uživatel nárok. Neexistuje způsob, jak přesměrovat klienta na autoritativní zdroj dat, pokud ho server zná. Neexistuje jednotný způsob, jak vyhledat server, kterého je třeba se ptát. Těch problémů je, jak je vidět, mnoho. Protokol RDAP většinu z nich řeší tím, že staví na vlastnostech protokolu HTTP.

Jak je uvedené hned v prvním RFC7480, umožňuje tato závislost při implementaci služby využít přesměrování, autentizaci, kompresi, kešování, limitování počtu požadavků a další vlastnosti HTTP. Druhé RFC7481 popisuje hlavně bezpečnostní aspekty a zmiňuje zejména nutné zabezpečení s využitím TLS a obecně autentizační možnosti HTTP. Mimo jiné toto RFC také naznačuje možnost využít konceptu jednotného přihlašování pro RDAP. Již nyní se díky zkušenostem z provozování služby mojeID aktivně účastníme projektu využití autentizace přes OpenID Connect v RDAP serveru vedeného výzkumníky ze společnosti Verisign, ale to je na samostatný článek.

Další RFC7482 popisuje, jakým způsobem se mají RDAP serveru klást dotazy. Tyto dotazy mají dvě základní formy. První z nich je klasické nalezení objektu podle nějakého identifikátoru (lookup) a tento způsob by měl vždy vrátit informace o jednom konkrétním objektu, pokud samozřejmě existuje. Standard definuje pět objektů, které je možné prohledávat a ke každému objektu přiřazuje část URL, kterou je  nutné připojit k základní adrese RDAP serveru spolu s identifikátorem objektu. Jedná se o IP adresy (/ip), autonomní systémy (/as), domény (/domain), DNS servery (/nameserver) a entity (/entity). Entitou se myslí např. držitel domény,  ale i administrativní kontakt nebo třeba registrátor. Druhá forma (search) umožňuje vyhledání seznamu objektů na základě zadané podmínky. Tato podmínka se typicky týká hodnoty nějakého atributu objektu a tato hodnota může mít dokonce formu vzoru se zástupným znakem pro libovolný text (*). Vyhledávat je možné v doménách (/domains) podle jména, hostname DNS serveru nebo jeho IP adresy, DNS serverech (/nameservers) podle hostname nebo IP adresy a entitách (/entities) podle jména nebo identifikátoru. Na konec URL se pak přidává podmínka v podobě standardního query řetězce (/domains?name=example*.com). Z pohledu našeho registru přirozeně neimplementujeme IP adresy a autonomní systémy a v aktuální verzi ani ono vyhledávání (search). K existujícím objektům domén, DNS serverů a entit ale přidáváme specifické rozšíření našeho registru v podobě objektů sady DNS serverů (/fred_nsset) a sady DNSSEC klíčů (/fred_keyset). Toto rozšíření jsme si nechali zaregistrovat do centrálního registru RDAP rozšíření spravovaném organizací IANA. Jedná se zároveň o úplně první rozšíření v tomto registru.

Jak ale zjistit základní adresu RDAP serveru zmíněnou v předchozím odstavci? Pro původní WHOIS protokol neexistovalo žádné standardizované řešení a tak každý WHOIS klient obsahoval adresy známých serverů napevno ve svém kódu. Dostat se na takový seznam znamenalo kontaktovat výrobce a snažit se tam svůj WHOIS server protlačit. RDAP naopak v RFC7484 definuje pro jednotlivé objekty několik centrálních registrů spravovaných také organizací IANA a z těchto registrů mohou RDAP klienti zjistit potřebné informace. V registru určeném pro domény je jako první a zatím jediný RDAP server uveden právě RDAP server pro domény v .CZ.

Nyní už tedy víme, kde a jak se zeptat a tak nám další RFC7483 říká, co můžeme očekávat v odpovědi. Obecná vlastnost HTTP protokolu umožňuje klientovi požádat o konkrétní formát odpovědi. S tímto také RDAP počítá, ale v aktuální specifikaci se koncentruje pouze na jeden formát a tím je formát specifikovaný v jazyce JSON. Nepůjdu zde do detailu, pouze zmíním některé zajímavosti. Například pro kontaktní informace o entitách byla zvolena JSON varianta populárního formátu vCard, nazvaná jCard.  Otázka je, zda-li bude existovat podpora pro tento formát i v adresářových aplikacích. Pro zvýšení interoperability byl vytvořen další registr v rámci organizace IANA, tentokrát registr hodnot atributů RDAP objektů. I do tohoto registru jsme zaregistrovali naše specifické atributy. Pokud si chcete prohlédnout jak vypadají výstupy konkrétních objektů stačí kliknout na následující odkazy. Některé prohlížeče (např. Firefox) nemají pro RDAP JSON strukturu asociovaný žádný zobrazovací mechanismus a bude nutné zvolit například textový editor:

• Doména: https://rdap.nic.cz/domain/nic.cz
• Nameserver: https://rdap.nic.cz/nameserver/a.ns.nic.cz
• Entita: https://rdap.nic.cz/entity/CZ-NIC
• Sada DNS serverů: https://rdap.nic.cz/fred_nsset/CZ.NIC
• Sada DNSSEC klíčů: https://rdap.nic.cz/fred_keyset/CZ.NIC

Jak je vidět, pro získání odpovědi je možné použít standardní prohlížeč. Pro komunikaci v příkazovém řádku je pak možné použít běžné HTTP klienty jako ‚wget‘ nebo ‚curl‘ a v případě nutnosti implementovat komunikaci s RDAP serverem do vlastních aplikací, existuje celá řada HTTP knihoven pro různé jazyky. Začínají už ale vznikat i specializované klientské aplikace pro RDAP, které navíc implementují zmiňované vyhledání RDAP serveru nebo řeší uživatelský příjemné formátování výstupu. Aktuálně je možné doporučit dvě takové aplikace. První je z dílny adresního registru ARIN, je pojmenovaná nicinfo a je napsaná v jazyce Ruby. Druhou vyvíjí brazilský doménový registr, nazvali ji rdap_client a je napsaná v jazyce Go. Obě aplikace je možné jednoduše z GitHubu stáhnout a ihned spustit.

Budoucnost nového RDAP protokolu ještě není úplně jednoznačná. Z diskuzí na IETF je cítit obavy, že pokud se ani tato náhrada WHOIS protokolu neprosadí, nebude již mít nikdo chuť zkoušet to znovu. Poměrně velký tlak na rozšíření RDAPu vyvíjí i ICANN a to prostřednictvím svých kontraktů s provozovateli registrů starých i nových generických domén. Pokud využíváte stávající WHOIS na portu 43, můžete rozšíření tohoto protokolu přispět i vy tím, že ho začnete používat, třeba právě v registru domén .CZ.