Résumé
- L'aut-num AS214789 (as-name nova-cloud-kz) porte deux mainteneurs : RIPE-NCC-END-MNT et kz-novacloud-mnt ; il a été créé le 31 mai 2024 à 07:40:06 UTC et modifié pour la dernière fois le 2 juillet 2024 [https://whois.ipip.net/AS214789].
- kz-novacloud-mnt figure également en mnt-by et mnt-ref de l'organisation ORG-NC138-RIPE (Nova Cloud LLP, Almaty, reg-nr 240440015497) et protège l'objet personne MV16118-RIPE (Malinovsky Vladimir, créé le 30 mai 2024, jamais modifié) [https://whois.ipip.net/AS214789][https://ip.cc/topic/asn/AS214789/].
- En revanche, l'objet de route pour 78.109.18.0/24 (origine AS214789) est maintenu par mnt-kz-anna-1, créé le 24 octobre 2025 : une chaîne d'autorisation distincte de celle de NovaCloud [https://bgp.he.net/net/78.109.18.0/24].
- Les trois /24 annoncés par l'AS portent des attributions contradictoires selon les sources : « Nova-Cloud », « Nova Cloud LLP » et « Anna Revenko trading as Ip.Rent » [https://bgp.he.net/net/78.109.18.0/24][https://ipv4.bgp.he.net/AS214789][https://whois.ipip.net/AS214789].
- L'objet mntner kz-novacloud-mnt lui-même (mécanisme d'authentification, date de création, ensemble complet des objets protégés) n'a pas été récupéré directement ; toutes les observations proviennent de miroirs tiers dont les instantanés divergent [https://apps.db.ripe.net/search?q=kz-novacloud-mnt].
Ce qu'un mainteneur autorise
Dans le modèle RIPE, un mainteneur n'est pas une description : c'est le mécanisme qui valide la création et la modification des objets enregistrés. Quand l'aut-num AS214789 liste « mnt-by: RIPE-NCC-END-MNT » et « mnt-by: kz-novacloud-mnt » [https://whois.ipip.net/AS214789], cela signifie que toute modification de l'enregistrement de l'AS — ses contacts, son organisation de parrainage, ses import/export — doit passer par une des deux clés. La clé institutionnelle du RIPE NCC est l'une ; l'autre, kz-novacloud-mnt, appartient à l'opérateur.
La même clé contrôle l'identité organisationnelle. L'objet ORG-NC138-RIPE — Nova Cloud LLP, pays KZ, numéro d'immatriculation 240440015497, adresse Mynbaeva street 46, Bostandyk district, Almaty 050046 — liste kz-novacloud-mnt à la fois en mnt-by et en mnt-ref [https://whois.ipip.net/AS214789]. Et l'objet personne MV16118-RIPE, Malinovsky Vladimir, créé le 30 mai 2024 à 05:50:14 UTC et jamais modifié depuis, est protégé par le même mainteneur [https://whois.ipip.net/AS214789][https://ip.cc/topic/asn/AS214789/]. En termes de surface de contrôle : qui tient kz-novacloud-mnt peut redéfinir qui parle au nom de l'organisation, qui reçoit les rôles admin-c et tech-c, et quelles coordonnées l'annuaire affiche.
La route qui échappe au mainteneur
Le point décisif est ailleurs. L'AS214789 annonce trois préfixes /24 — 78.109.18.0/24, 91.147.110.0/24 et 194.164.115.0/24, soit 768 adresses IPv4 [https://bgp.he.net/AS214789][https://ipv4.bgp.he.net/AS214789]. Or l'objet de route du premier, 78.109.18.0/24 avec origine AS214789, est maintenu par mnt-kz-anna-1 et a été créé le 24 octobre 2025 à 17:52:49 UTC, soit plus d'un an après l'aut-num [https://bgp.he.net/net/78.109.18.0/24]. Dans le modèle RIPE, l'autorisation d'annonce d'une route dépend du mainteneur de l'objet de route, pas de celui de l'AS. La chaîne qui garde l'identité enregistrée de Nova Cloud LLP ne garde donc pas, pour ce préfixe, la clé qui autorise son annonce.
Ce découplage a une conséquence pratique : la capacité de modifier l'identité de l'AS et la capacité d'autoriser l'annonce d'un préfixe résident dans des chaînes d'identifiants séparées. Un lecteur qui cherche « qui contrôle NovaCloud Kazakhstan » obtient ainsi deux réponses différentes selon la couche interrogée — l'annuaire ou la table de routage.
Des attributions qui ne s'accordent pas
Les trois préfixes ne portent pas non plus la même étiquette selon les sources. La vue IPv4 de bgp.he.net liste « Nova-Cloud » pour 78.109.18.0/24, « Nova Cloud LLP » pour 91.147.110.0/24 et « Anna Revenko trading as Ip.Rent » pour 194.164.115.0/24 [https://ipv4.bgp.he.net/AS214789]. Le miroir ipip.net attribue les trois blocs, en termes d'enregistrement d'adresses, à l'entité Ip.Rent, tandis que l'AS d'origine reste Nova Cloud LLP [https://whois.ipip.net/AS214789]. Ces libellés sont dérivés et non faisant autorité, mais leur incohérence interne — sur les trois /24 d'un même AS — confirme que l'attribution descriptive du préfixe n'est pas unifiée autour de l'organisation que kz-novacloud-mnt protège.
Un profil d'origine pure
Les vues de routage indépendantes décrivent un réseau d'origine pure : deux liaisons amont (AS43994 SMARTNET-AS et AS35104 KTC-AS, ce dernier opéré par Jusan Mobile), zéro aval, trois /24 annoncés, aucun espace IPv6, et une validation d'origine RPKI rapportée valide pour les trois préfixes [https://www.cidr-report.org/cgi-bin/as-report?as=AS214789&view=2.0][https://bgp.he.net/AS214789][https://ipv4.bgp.he.net/AS214789]. Le caractère modeste du footprint est cohérent avec ce que la couverture antérieure de BTW avait établi pour le label NovaCloud ; ce qui est nouveau ici, c'est la structure d'autorisation derrière ce footprint. Les classements d'AS indépendants et la vue de routage de Cloudflare Radar confirment ce profil (classement bgp.tools, Cloudflare Radar AS214789).
Ce que les sources ne disent pas
L'objet mntner kz-novacloud-mnt lui-même — son attribut auth, sa date de création, l'ensemble complet des objets qu'il protège — n'a pas été récupéré lors de cette recherche [https://apps.db.ripe.net/search?q=kz-novacloud-mnt]. Toutes les observations du mainteneur proviennent de miroirs tiers reproduisant l'aut-num, l'organisation et l'objet personne, et ces miroirs divergent entre eux : la date last-modified de ORG-NC138-RIPE apparaît tour à tour comme le 31 mai 2024, le 29 avril 2026 et le 13 mai 2026 selon la source [https://whois.ipip.net/AS214789][https://ip.cc/topic/asn/AS214789/][https://www.cidr-report.org/cgi-bin/as-report?as=AS214789&view=2.0]. Chaque différence d'instantané rappelle qu'un miroir est une copie datée, pas une lecture vivante de la base. L'existence et l'étendue exactes de l'autorité de kz-novacloud-mnt restent donc documentées par ses effets — les mnt-by d'autrui — plutôt que par son propre objet.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
