RDAP vs WHOIS: verificarea domeniului în 2026

Pentru domeniile generice precum .com, .net și .org, RDAP a devenit sursa definitivă pentru datele de înregistrare la 28 ianuarie 2025. Folosește ICANN Lookup sau un client RDAP pentru a verifica registrarul, ID-ul IANA, datele de creare și expirare, statusurile EPP, nameserverele și starea DNSSEC. Nu considera răspunsul public drept dovadă completă a proprietății juridice. Datele titularului pot fi redactate, iar verificarea reală necesită frecvent acces la contul de registrar, documente de înregistrare sau un token DNS TXT.

Scris de echipa tehnică ServerSpan.

RDAP a înlocuit serviciul contractual WHOIS pentru domeniile generice

ICANN a desemnat Registration Data Access Protocol drept sursa definitivă pentru datele de înregistrare ale domeniilor generice începând cu 28 ianuarie 2025. Registrarii acreditați și operatorii registrelor gTLD ofereau deja RDAP din 2019, dar data din 2025 a încheiat obligația contractuală de a menține serviciile WHOIS tradiționale.

Limita de aplicare contează. Tranziția privește extensiile generice administrate prin contractele ICANN. Registrele naționale își stabilesc propriile politici. O extensie ccTLD poate oferi RDAP, poate păstra WHOIS, poate opera ambele servicii sau poate folosi o interfață de căutare proprie.

Unele instrumente WHOIS continuă să returneze rezultate în 2026. Pentru un gTLD, asta nu transformă WHOIS în sursa preferată. Începe cu răspunsul RDAP sau cu serviciul ICANN Lookup.

Pentru înregistrarea unui domeniu nou sau mutarea unuia existent, ServerSpan oferă înregistrare și transfer de domenii. Contul de la registrar rămâne locul în care sunt administrate reînnoirea, contactele, blocarea transferului și codul de autorizare.

RDAP furnizează date structurate în locul textului neuniform

WHOIS este un protocol de interogare bazat în mod obișnuit pe portul TCP 43 și returnează text destinat citirii de către oameni. Serverele diferite au folosit etichete, ordini, encodări și mecanisme de trimitere diferite. Un script trebuia adesea adaptat separat pentru fiecare registry sau registrar.

RDAP folosește HTTP și returnează JSON structurat. Un client poate identifica elementele după membrii JSON definiți de standard, fără să ghicească sensul unor linii precum Registrar:, Updated Date: sau Name Server:.

Protocolul permite transport HTTPS, internaționalizare, descoperirea serviciului autoritativ și mecanisme pentru autentificare sau acces diferențiat. Politica concretă de acces rămâne stabilită de operatorul serviciului și de regulile aplicabile datelor respective.

Caracteristică	WHOIS	RDAP
Transport	TCP, de obicei portul 43	HTTP sau HTTPS
Formatul răspunsului	Text liber	JSON structurat
Descoperirea serviciului autoritativ	Servere configurate manual sau referral-uri	Registre bootstrap IANA
Internaționalizare	Fără mecanism uniform pentru setul de caractere	Conceput pentru date internaționalizate
Controlul accesului	Fără mecanism standard în protocol	Poate folosi autentificare și acces diferențiat
Automatizare	Necesită parsarea textului	Câmpurile JSON pot fi procesate direct
Rol pentru gTLD în 2026	Serviciu vechi și opțional după retragere	Sursa definitivă pentru datele de înregistrare

ICANN Lookup este cea mai simplă metodă pentru o verificare manuală

Pentru o investigație manuală, începe cu ICANN Lookup. Introdu numele complet al domeniului, fără protocol, cale sau adresă de email. Folosește example.com, nu https://example.com/contact.

Un răspuns public normal pentru un gTLD poate conține:

• Numele normalizat al domeniului și identificatorul din registry.
• Registrarul sponsor și ID-ul său IANA.
• Adresa de email și numărul de telefon pentru raportarea abuzurilor.
• Datele de creare, expirare, actualizare și interogare RDAP.
• Statusurile EPP actuale.
• Nameserverele autoritative.
• Informații despre delegarea DNSSEC.
• Linkuri către serviciile RDAP ale registry-ului și registrarului.
• Notificări privind datele redactate și metodele de contact intermediar.

Registrarul sponsor este compania care administrează înregistrarea domeniului. Poate fi diferită de furnizorul DNS, compania de hosting, furnizorul de email sau resellerul prin care a fost plasată comanda.

Nameserverele arată cine găzduiește zona DNS autoritativă. Nu identifică automat registrarul. Un domeniu poate fi înregistrat la o companie, poate folosi DNS de la alta și poate găzdui site-ul la un al treilea furnizor.

Clientul ICANN pentru linia de comandă permite verificări repetabile

ICANN menține un client RDAP open-source pentru linia de comandă. După instalarea sa conform instrucțiunilor proiectului, o interogare simplă pentru un domeniu este:

rdap example.com

Un răspuns reușit trebuie să afișeze obiectul domeniului, registrarul, evenimentele, statusurile, nameserverele, notificările și linkurile relevante. O eroare privind lipsa unui serviciu bootstrap poate indica o extensie fără endpoint RDAP publicat, un cache local depășit sau o interogare formatată greșit.

Pentru afișarea exclusivă a registrarului:

rdap -p registrar example.com

Comanda este utilă atunci când ai nevoie doar de numele registrarului, ID-ul IANA și datele entității respective.

Pentru output JSON formatat:

rdap -O pretty-json example.com

Pentru afișarea URL-urilor RDAP folosite:

rdap -O url example.com

Nu dezactiva validarea certificatelor pentru a forța funcționarea unei interogări. Un certificat TLS invalid, un hostname nepotrivit sau un endpoint HTTP neașteptat trebuie investigat, nu ignorat.

Bootstrapul IANA identifică serviciul RDAP autoritativ

Un client RDAP nu trebuie să păstreze manual o listă cu serverele tuturor registrelor. Clientul consultă registrul bootstrap IANA, găsește extensia domeniului și obține URL-ul de bază al serviciului autoritativ.

Endpointurile publicate pentru extensia .com pot fi inspectate cu:

curl -fsS https://data.iana.org/rdap/dns.json | \
  jq -r '.services[] | select(any(.[0][]; . == "com")) | .[1][]'

Rezultatul trebuie să conțină unul sau mai multe URL-uri HTTPS. Lipsa outputului poate indica o extensie care nu apare în filtrul folosit, o problemă de rețea sau o structură modificată a datelor procesate local.

Interogările pentru domenii adaugă segmentul domain/<nume-complet> la URL-ul de bază:

https://rdap.example/rdap/domain/example.com

Pentru automatizări de producție, folosește un client cu bootstrap. Un endpoint introdus manual pentru toate extensiile va eșua deoarece TLD-urile sunt administrate de servicii RDAP diferite.

Registrarul și statusurile arată starea operațională a domeniului

Entitatea registrar identifică locul în care este administrată înregistrarea. Compară numele afișat cu ID-ul IANA. Brandurile achiziționate, resellerii și denumirile comerciale similare pot face numele singur ambiguu.

Statusurile domeniului descriu restricții și etape ale ciclului de viață. Folosește documentația ICANN pentru codurile EPP în loc să deduci sensul numai din numele statusului.

Status RDAP	Semnificație practică	Acțiune recomandată
clientTransferProhibited	Registrarul a cerut registry-ului să respingă transferurile	Păstrează blocarea pentru protecție sau elimin-o din cont înaintea unui transfer autorizat
clientUpdateProhibited	Actualizarea datelor domeniului este restricționată	Verifică setările și motivul blocării în contul registrarului
serverTransferProhibited	Registry-ul blochează transferul	Contactează registrarul, deoarece poate fi necesară intervenția operatorului registry
clientHold sau serverHold	Domeniul nu este activ în DNS	Verifică plata, validarea, reclamațiile de abuz, delegarea și eventualele restricții juridice
redemptionPeriod	Registrarul a solicitat ștergerea, iar domeniul se află în perioada de recuperare	Contactează imediat registrarul și solicită restaurarea
pendingDelete	Domeniul se apropie de eliminarea din registry	Contactează imediat registrarul; recuperarea poate să nu mai fie disponibilă

Data de expirare nu arată singură dacă domeniul poate fi înregistrat de altcineva. Perioadele de grație, redemption, politicile registry-ului și procesarea registrarului pot păstra domeniul indisponibil după data afișată.

Articolul ServerSpan Nu deții domeniul tău. Îl închiriezi de la un ceas care nu se oprește niciodată explică mai detaliat reînnoirea și procesul de ștergere.

Răspunsul RDAP nu dovedește singur proprietatea juridică

RDAP verifică înregistrarea publică. Nu dovedește automat că persoana care îți prezintă rezultatul deține domeniul, controlează contul de registrar sau are autoritatea juridică de a-l vinde.

Datele titularului pot fi redactate pentru protejarea informațiilor personale sau pentru respectarea cerințelor legale. Un serviciu de privacy sau proxy poate apărea în locul clientului real. Chiar și atunci când este publicat numele unei companii, răspunsul nu dovedește că persoana cu care discuți este autorizată să o reprezinte.

Ce trebuie verificat	Dovadă utilă	Rolul RDAP
Registrarul actual	Entitatea registrar și ID-ul IANA din răspunsul autoritativ	Dovadă publică puternică
Controlul DNS actual	Publicarea unui token DNS TXT unic	Nameserverele arată unde este găzduit DNS-ul
Controlul contului de registrar	Acțiune controlată sau demonstrație în cont	Identifică registrarul la care trebuie verificat accesul
Istoricul cumpărării și reînnoirii	Facturi, confirmări de comandă și chitanțe de reînnoire	Oferă date care pot fi comparate cu documentele
Dreptul juridic de proprietate sau vânzare	Contracte, documente ale companiei și acte de cesiune	Poate arăta organizația titularului dacă informația este publicată
Posibilitatea transferului	Eligibilitatea din cont, deblocarea și codul de autorizare păstrat în siguranță	Arată statusurile EPP care blochează transferul

Un token DNS TXT este o metodă simplă pentru verificarea controlului tehnic actual. Generează o valoare aleatorie și cere publicarea ei sub un hostname dedicat:

_ownership-check.example.com. 300 IN TXT "verify-2026-token-aleatoriu"

Verifică valoarea printr-un resolver independent:

dig TXT _ownership-check.example.com +short

Outputul trebuie să conțină exact tokenul solicitat. Testul dovedește controlul DNS actual. Nu dovedește proprietatea juridică și nici accesul la contul registrarului. Un administrator DNS, o agenție sau un fost angajat poate modifica zona fără să dețină înregistrarea.

Pentru un transfer, verifică separat controlul contului de registrar. Păstrează codul de autorizare privat și introdu-l numai în procesul securizat al noului registrar. Ghidul ServerSpan despre transferul unui domeniu fără downtime acoperă blocarea, continuitatea DNS și protejarea emailului.

Datele redactate necesită procesul de divulgare al registrarului

Lipsa numelui sau adresei de email a titularului nu înseamnă că domeniul nu are proprietar. Politica ICANN permite sau impune redactarea anumitor date personale în răspunsurile publice.

Registrarul poate publica o adresă anonimizată sau un formular care transmite mesajul fără să dezvăluie contactul real. Folosește acest mecanism pentru solicitările obișnuite.

Atunci când ai nevoie de date nepublice pentru un scop juridic, de securitate, protecția consumatorului sau proprietate intelectuală, verifică mai întâi ICANN Lookup. Dacă informația nu este publică, folosește Registration Data Request Service pentru registrarii participanți sau urmează procedura publicată de registrar.

O solicitare de divulgare nu garantează furnizarea datelor. Registrarul evaluează identitatea solicitantului, scopul declarat, dovezile prezentate, legislația aplicabilă și drepturile persoanei vizate.

Înregistrarea, DNS-ul, hostingul și website-ul sunt sisteme separate

O investigație corectă separă patru roluri:

• Registrarul: administrează înregistrarea, reînnoirea, datele titularului, blocările și autorizarea transferului.
• Operatorul registry: menține baza autoritativă pentru extensia domeniului.
• Furnizorul DNS: găzduiește zona DNS autoritativă și înregistrările acesteia.
• Furnizorul de hosting: rulează website-ul, aplicația sau serviciul de email indicat prin DNS.

Controlul unuia dintre sisteme nu dovedește controlul celorlalte. Un dezvoltator poate administra serverul, în timp ce clientul controlează registrarul. Un furnizor DNS poate modifica înregistrările fără acces la setările de transfer.

Folosește dig pentru verificarea DNS-ului, nu pentru identificarea registrarului:

dig NS example.com +short
dig A example.com +short
dig MX example.com +short
dig DS example.com +short

Comenzile arată delegarea nameserverelor, adresele website-ului, rutarea emailului și delegarea DNSSEC. Nu arată unde este înregistrat domeniul. Articolul ServerSpan Ce este o înregistrare DNS? explică rolul acestor înregistrări.

Verificările vechi bazate pe WHOIS duc frecvent la concluzii incomplete

O greșeală frecventă este consultarea unui website WHOIS vechi, observarea unui câmp gol pentru titular și concluzia că înregistrarea este defectă. Datele pot fi redactate, iar site-ul poate afișa informații din cache sau numai răspunsul registry-ului.

• Nu identifica registrarul după nameservere.
• Nu trata numele public al titularului drept singura dovadă de proprietate.
• Nu presupune că un domeniu este disponibil numai pentru că data de expirare a trecut.
• Nu accepta o captură de ecran drept dovadă a controlului actual.
• Nu cere expunerea codului de autorizare în etapa de verificare preliminară.
• Nu configura un singur endpoint RDAP pentru toate extensiile.
• Nu dezactiva verificarea TLS pentru a forța funcționarea unei interogări.

Pentru un audit obișnuit, folosește ICANN Lookup, notează registrarul și ID-ul IANA, verifică statusurile, compară nameserverele și confirmă controlul tehnic printr-un token DNS TXT. Pentru cumpărarea sau cesionarea unui domeniu valoros, adaugă verificarea contului de registrar, istoricul plăților, documentele de cesiune și consultanță juridică.

ServerSpan oferă înregistrarea și transferul domeniilor după finalizarea verificărilor tehnice și administrative.

Regula practică este clară. Folosește RDAP pentru verificarea înregistrării publice autoritative. Folosește contul de registrar pentru confirmarea controlului administrativ. Folosește un token DNS pentru confirmarea controlului tehnic. Folosește contractele și documentele contabile atunci când proprietatea juridică trebuie demonstrată.