Comment les noms de domaine entrent-ils dans la base de données WHOIS et quelles bases de données sont mises à jour pour chaque domaine?

Question

Le protocole de requête et de réponse WHOIS est largement utilisé pour les bases de données contenant diverses ressources Internet telles que les assignations IPv4, les assignations IPv6, les numéros AS et le RIR (par exemple, ARIN aux États-Unis ou RIPE en Europe). Les membres doivent (les détails dépendent du RIR) pour conserver leurs enregistrements dans ces bases de données.

En outre, de nombreux automatismes dans le monde des fournisseurs de services Internet sont basés sur ces objets dans ces bases de données WHOIS RIR. Par exemple, whois.ripe.net pour la région RIPE ou whois.apnic.net pour la région APNIC.

Dans quelles bases de données WHOIS les noms de domaine sont-ils conservés? Est-il obligatoire pour le registraire de domaine de créer un enregistrement dans cette base de données WHOIS? Je suppose que "oui", sinon les autres registres de domaine ne sauraient pas que le domaine est en cours d'utilisation. Existe-t-il un RFC qui définit quelles informations, en plus du nom de domaine, iront à cette base de données?

Patrick Mevzek · Accepted Answer

whois est un protocole très mal défini (ou plus précisément: bien défini au moment de son utilisation, mais il est maintenant clairement obsolète et manque d'éléments clés nécessaires aujourd'hui, tels que l'accès hiérarchisé et la sortie formatée), avec seulement - RFC 3912 couvrant (obsolète RFC 954 ), qui ne dit généralement rien: vous envoyez une requête sur une ligne, le serveur répond avec une goutte de texte, c'est tout.

Pour situer les noms de domaine dans leur contexte, revenons en arrière et expliquons les choses de manière historique.

Network Solutions, également appelé NSI (et plus tard Verisign), était le registre de tous les noms de domaine .COM/.NET/.ORG. C'était un registre mince, ce qui signifie qu'il ne stockait aucune donnée sur les contacts du nom de domaine, il ne contenait que le nom, les dates et les serveurs de noms (et quelques éléments supplémentaires comme qui est le registraire, quel est le statut, etc. ). Le registre avait un serveur whois, puis un "champ" spécifique dans la sortie donnait le nom du registraire whois serveur à interroger pour accéder aux autres données, principalement des informations de contact (nom , adresse postale, numéros de téléphone et de télécopieur, adresse électronique du titulaire, contacts administratifs, de facturation et techniques du nom de domaine).
Puisque le protocole whois n'a pas de concept de découverte automatique (pour trouver le serveur de registre whois sur la base du nom de domaine, car à cette époque, d'autres registres, comme les ccTLD, avaient également whois serveurs] et " redirection "(car il doit passer du registre whois serveur au registraire whois serveur), les clients whois ont souvent codé en dur les valeurs des serveurs auxquels se connecter (voir par exemple https://github.com/rfc1036/whois/blob/next/tld_serv_list ou https://raw.githubusercontent.com/whois-server-list/whois-server-list/master/whois -server-list.xml ), d'abord pour les registres et parfois pour les bureaux d'enregistrement. Voir mon autre réponse ici: https://unix.stackexchange.com/a/407030/2118 pour plus d'informations sur les autres moyens, en particulier le dernier point. En dehors de cela, ils sont programmés pour lire le registre whois réponse du serveur, extrayez-y le champ approprié pour trouver le registre approprié whois serveur pour aller plus loin, connectez-vous à celui-ci pour refaire la même requête et récupérer davantage d'informations. Les données. Notez que cette dernière étape de la "redirection" est purement sous le contrôle du client (elle peut donc dépendre du logiciel que vous utilisez) car il n'y a rien dans la norme de protocole whois qui le définit. Notez également qu’une modification récente imposée par l’ICANN dans le registre whois est affichée, en particulier sur le champ portant le nom du serveur registrar whois, qui a cassé plusieurs clients whois qui n’avaient pas mis à jour) pour trouver le serveur de registrar whois parmi la sortie de registre whois.
Pour les gTLD, les bureaux d'enregistrement et les registres sont sous contrat avec l'ICANN (voir https://www.icann.org/resources/pages/registries/registries-agreements-en et https://www.icann.org/resources/pages/registrars/registrars-en ); ces contrats les obligent à exécuter un serveur whois, chacun à son niveau pour les noms de domaine qu’il a parrainés (voir spécification technique 4 du contrat de registre et pour les bureaux d’enregistrement: https://www.icann.org/resources/pages/approuve-with-specs-2013-09-17-fr # whois ). Au contraire, dans les ccTLD, très peu de registrars utilisaient à cette époque et, même dans ce cas, le registre disposait de toutes les informations nécessaires pour que registre whois sortie affiche toutes les données nécessaires.
Il a ensuite été décidé de placer .ORG dans un processus d'appel d'offres (voir https://www.icann.org/resources/board-material/prelim-report-2002-03-14-en#orgReassignment ). Il a finalement été délégué à PIR (voir https://www.icann.org/resources/board-material/prelim-report-2002-10-14-en#SuccessorOperatorfororgRegistry ) et a peu après basculé ( de RRP) à EPP (cela faisait partie de la candidature, voir https://archive.icann.org/en/tlds/org/applications/isoc/section5.html#c27A - cela a rendu sens à l'époque, même si EPP n'était pas encore complètement publié en tant que RFC) pour les communications entre registraires et registre, ce qui avait également pour conséquence de passer à un modèle volumineux: le registre stockait toutes les données, y compris pour les contacts et donc un whois la sortie pour .ORG commencerait à tout afficher, sans avoir besoin d'interroger le serveur registraire whois. Toutefois, les contrats en place n’ayant pas changé, les bureaux d’enregistrement ont toujours le mandat d’exécuter un serveur whois pour le nom de domaine qu’ils gèrent dans .ORG, même si le registre contient déjà toutes les données. Par ailleurs, il était également prévu au départ d’inclure également .NET dans un processus d’appel d’offres pour le transmettre à quelqu'un d'autre que Verisign (voir par exemple https://afilias.info/news/2005/01/19/ afilias-bids-rights-run-net-registry ou http://www.core-plusplus.net/faq.do ), mais des changements dans le cours des actions ont abouti à la création de .NET définitivement lié à .COM pour un avenir prévisible.
L'ICANN a commencé à normaliser le format de sortie whois, d'abord au niveau du registre, puis au bureau d'enregistrement. Au début, étant donné que le protocole whois ne définit pas en lui-même la structure de la réponse, chaque serveur whois avait son propre format, du simple format clé-valeur (facile à analyser) à certains très compliqués. les uns (certains serveurs whois ont même changé le format - pour la même requête - d’une réponse à l’autre afin de dissuader toute récupération automatisée de toutes ces données). C’était un problème pour les registraires des gTLD, car ils avaient besoin, en particulier pour les transferts, de connaître les adresses électroniques des contacts du domaine et la meilleure source de données, puis la sortie whois (et si vous suiviez ce qui est écrit). ci-dessus, cela signifiait aller au registraire whois sortie en tant que registre - pour .COM/.NET qui reste le roi - la sortie ne contenait pas les données pertinentes). Mais au même moment, de nombreuses personnes étaient en train de récupérer whois des données à des fins diverses, allant d’activités légales et utiles (comme la protection de la propriété intellectuelle) à des données moins légales et utiles (comme les spams pour offrir des services d’hébergement Web aux noms de domaine qui viennent d’être enregistrés).
.COM/.NET est également passé à EPP parfois plus tard (en 2005-2006, voir http://www.circleid.com/posts/additional_domain_name_transfer_requirement/ et http: // web. archive.org/web/20061017164241/http://www.verisign.com/Resources/Naming_Services_Resources/Registrar_Connections/page_038962.html#01000005 ), mais reste un registre restreint.
Toutefois, un processus est en cours pour convertir le dernier registre fin gTLD (.COM/.NET et .JOBS) en un registre volumineux. Le processus a été un peu retardé, mais le but est toujours là. Voir https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en . Notez que lorsque cela est atteint, il n’ya plus de raison (technique) pour que les bureaux d’enregistrement aient un serveur whois, le registre dispose de toutes les données, mais il n’existe toujours pas de plan spécifique pour empêcher les bureaux d’en faire de le faire (au contraire, leurs mandats qu'ils continuent). Les choses pourraient toutefois changer en 2018 avec l'introduction du GDPR, une nouvelle réglementation européenne sur la vie privée qui a un impact direct sur des services tels que whois, présentant des données privées d'individus.
Le protocole RDAP a été défini par l'IETF (voir RFC 748 , RFC 7481 , RFC 7482 , RFC 748 , RFC 7484 , et RFC 8056 ) pour remplacer whois à l'avenir, car il élimine de nombreuses lacunes dans whois: sortie structurée ( grâce à l'utilisation de JSON), des redirections possibles (grâce à l'utilisation de HTTP) et des fonctionnalités d'authentification (toujours grâce à HTTP), de l'internationalisation (whois protocole par exemple ne définit aucun élément lié au codage, ce qui représente un défi pour les registres non-ASCII et un cauchemar pour l'interopérabilité), les possibilités d'extension et d'adaptation pour tous types de registres, etc. Il a un bootstrap mécanisme pour que RDAP les clients puissent fonctionner sans aucune sorte de valeur codée en dur de RDAP serveur à interroger.
L’ICANN discute actuellement de l’obligation pour tous les registres (et éventuellement les bureaux d’enregistrement) de mettre en œuvre le RDAP et de planifier un plan de temporisation whois. Il n’ya plus de discussions techniques, mais davantage de problèmes politiques pour définir ce qu’il faut afficher exactement à quel public (voir https://www.icann.org/resources/pages/rdap-operational-profile-2016-07- 26-fr ), et cela est à nouveau affecté par les lois et règlements nationaux, comme le nouveau RGPD. Pour l'instant, il n'existe qu'un pilote pour les registres de noms de domaine (RDAP est déjà utilisé par les RIR en production): https://community.icann.org/display/RP/RDAP+Pilot et un tas de données utiles et de liens disponibles sur https://about.rdap.org/

Pour répondre spécifiquement à vos points: les choses fonctionneraient même si les bureaux d'enregistrement ne disposaient pas d'un serveur whois/RDAP. Ce n’est pas là que se trouve l’information faisant autorité qui commandite quel nom de domaine, c’est au niveau du registre, et il n’y aura que le seul besoin technique d’un serveur whois/RDAP pour savoir qui gère tel ou tel domaine. Le fait que les bureaux d’enregistrement en gèrent, en particulier aujourd’hui dans les gTLD, n’est que parce qu’ils sont contractuellement mandatés par leur contrat avec l’ICANN, qui définit également avec précision le format à mettre en œuvre. C’est cependant même parfois une source de confusion, voir mon autre réponse ici: https://serverfault.com/a/885149/396475 pour un exemple.

Aussi, veuillez ne pas utiliser le terme "base de données whois", il est à la fois techniquement incorrect et trompeur. Le registre contient une "base de données" contenant diverses données sur tous les noms de domaine sous le TLD concerné. Le contenu de cette base de données peut être modifié ou interrogé via différents protocoles, pour différents clients et utilisations: les registraires utilisent EPP pour le mettre en service, le registre le rend disponible pour interroger via le protocole whois (notez que dans les gTLD et parfois dans les ccTLD, le serveur whois de registre pour les données autres que les noms de domaine, comme les données de contact ou les données de serveur de noms, ceci est rarement utilisé mais il existe), le registre l'utilise pour publier la zone sur ses serveurs de noms faisant autorité, etc.

nunorbatista · Answer

Je citerai wikipedia à ce sujet, mais je crois que dans ce cas, les informations sont fiables:

Les serveurs WHOIS exploités par les registres Internet régionaux (RIR) peuvent être interrogés directement pour déterminer le fournisseur de services Internet responsable d'une ressource particulière.

Les enregistrements de chacun de ces registres sont référencés, de sorte qu'une requête à ARIN concernant un enregistrement appartenant à RIPE renvoie un espace réservé pointant vers le serveur WHOIS de RIPE. Cela permet à l'utilisateur WHOIS effectuant la requête de savoir que les informations détaillées se trouvent sur le serveur RIPE. Outre les serveurs RIR, il existe des services commerciaux, tels que la base de données de routage utilisée par certains grands réseaux (par exemple, les grands fournisseurs Internet ayant acquis d'autres fournisseurs de services Internet dans plusieurs zones RIR).

À propos de Server Discovery, ils disent ceci:

Il n'existe actuellement aucune norme pour déterminer le serveur WHOIS responsable pour un domaine DNS, bien qu'un certain nombre de méthodes soient couramment utilisées pour les domaines de premier niveau (TLD). Certaines recherches dans le WHOIS nécessitent une recherche dans le registraire de domaine faisant l'acquisition pour afficher les détails du propriétaire du domaine.

Source: Whois