Résumé
- NZ TLD Anycast Cloud B a une forte identité publique en tant qu'AS38064, un enregistrement réseau d'InternetNZ décrit par APNIC comme l'ASN pour le peering anycast des serveurs de noms du TLD NZ. Il s'agit d'une preuve réelle de ressource réseau, mais ce n'est pas la même chose qu'un produit cloud de détail, une garantie de disponibilité universelle ou la preuve que chaque requête.nz est traitée par ce seul ASN.
- La preuve de service est plus large que le nom PeeringDB. IANA liste InternetNZ comme gestionnaire du ccTLD.NZ et liste sept serveurs de noms.nz. InternetNZ indique qu'il exploite le DNS faisant autorité pour.nz et les domaines de second niveau, utilise des serveurs de noms néo-zélandais plus deux fournisseurs internationaux, utilise l'anycast sur certains serveurs de noms, surveille localement et à distance, et publie des références DNSMON externes.
- La meilleure lecture opérationnelle sépare le registre, le DNS, la DNSSEC, le routage, le statut, le support et la gouvernance. Le système de registre d'InternetNZ est entré en service le 1er novembre 2022; l'inventaire DNS public liste les serveurs de noms unicast et anycast; PeeringDB liste les points d'échange et installations de Cloud B; APNIC et BGP.tools montrent la couche de routage AS38064; les notifications de statut montrent le comportement de maintenance et de distribution de zone; les pages de support des registraires définissent les heures ouvrées et les canaux d'escalade urgents.
- Les zones à sources limitées sont importantes. Les preuves publiques ne prouvent pas la couverture par requête, les résultats d'incidents au niveau client, toute la télémétrie interne, ou que l'étiquette Cloud B porte à elle seule tout le service.nz. Elle montre suffisamment pour prendre des décisions de service répétables si les acheteurs et les opérateurs maintiennent les preuves liées à leur couche.
Le nom est un indice de routage, pas le service
NZ TLD Anycast Cloud B ressemble à un service cloud, mais les archives publiques pointent vers quelque chose de plus étroit et plus utile. Il s'agit d'une entrée réseau nommée pour AS38064 au sein du parc opérationnel.nz d'InternetNZ. PeeringDB identifie le réseau comme NZ TLD Anycast Cloud B, le rattache à InternetNZ, donne le site web d'InternetNZ, étiquette le type de réseau comme non lucratif, et liste les enregistrements de peering public et d'installations. APNIC donne la description technique la plus directe: AS38064 est l'ASN pour le peering anycast des serveurs de noms du TLD NZ.
Il s'agit d'un enregistrement concret, et il ne doit pas être rejeté comme une simple marque. Un ASN, un détenteur de ressource, des points de peering, des installations, des enregistrements de politique de routage et des préfixes originés sont le genre de faits que les ingénieurs peuvent vérifier dans le temps. Ils aident à répondre si l'étiquette est attribuable, si la ressource de routage a un opérateur connu, si la piste de contact publique mène à la même institution, et si le nom s'inscrit dans un contexte d'infrastructure DNS plausible.
La première erreur est de traiter cet indice de routage comme s'il était l'ensemble du service. Un domaine de premier niveau de code pays ne devient pas fiable parce qu'un répertoire de peering a un nom rassurant. Il devient fiable grâce aux enregistrements de délégation, à la conception des serveurs de noms faisant autorité, à l'exploitation du registre, à la signature DNSSEC, à la surveillance, à la réponse aux incidents, à l'escalade du support, à la séparation de la gouvernance et à la maintenance de routine. L'anycast fait partie de ce service. Il ne remplace pas ces autres enregistrements.
La deuxième erreur est de traiter Cloud B comme un produit cloud commercial normal. Les preuves ne montrent pas un acheteur choisissant un abonnement à AS38064 comme il choisirait du calcul, du stockage ou un DNS géré auprès d'un fournisseur cloud. L'enregistrement est plus proche d'une infrastructure Internet publique critique. Pour la plupart des organisations, la question commerciale n'est pas de savoir si elles doivent acheter « Cloud B ».
C'est de savoir si la dépendance aux noms.nz, aux registraires, à la délégation faisant autorité, aux flux de travail du registre et à la disponibilité du DNS est acceptable pour le risque que l'organisation prend.
La troisième erreur est d'aplatir tous les enregistrements d'InternetNZ en un seul résultat. InternetNZ exploite l'espace de domaine.nz et est le gestionnaire du ccTLD.NZ dans l'enregistrement de délégation de l'IANA. Il exploite le registre.nz et l'infrastructure DNS faisant autorité. Il publie des canaux de support et un état de service. Il a des relations de gouvernance avec la Domain Name Commission. Il a AS38064 et des enregistrements de réseau anycast frères. Ces faits se renforcent mutuellement, mais chacun répond à une question opérationnelle différente.
La manière utile de lire NZ TLD Anycast Cloud B est donc par couches. Au niveau de l'identité, c'est InternetNZ. Au niveau de la délégation, l'IANA pointe vers InternetNZ et l'ensemble des serveurs de noms.nz. Au niveau du registre, InternetNZ tient le registre définitif.nz via le système de registre InternetNZ. Au niveau DNS, InternetNZ publie une architecture de serveurs de noms avec diversité locale et internationale. Au niveau du routage, AS38064 est l'enregistrement de peering anycast pour une partie de cette surface.
Au niveau du support, le support du registre et les contacts publics définissent qui peut demander de l'aide et comment l'escalade fonctionne. Au niveau de la reprise, les notifications de statut et les éléments d'incident montrent comment le changement et l'échec sont communiqués.
Cette séparation n'est pas du pédantisme. C'est ainsi que l'assurance devient répétable. Lorsqu'un registraire, une entreprise, une agence publique ou un exploitant de service critique examine la dépendance à.nz, la réponse ne doit pas être « le nom semble local » ou « l'ASN existe ». La réponse doit être un ensemble actuel d'enregistrements qui peut survivre à un examen opérationnel des mois plus tard.
La délégation donne l'enregistrement d'identité le plus fort
L'enregistrement d'identité le plus faisant autorité pour.nz commence par l'IANA, pas PeeringDB. L'IANA liste InternetNZ comme gestionnaire du ccTLD.NZ, donne les contacts administratifs et techniques d'InternetNZ, liste sept serveurs de noms, identifie whois.irs.net.nz comme serveur WHOIS, et enregistre la délégation.NZ comme mise à jour pour la dernière fois le 15 décembre 2025. Il s'agit de l'enregistrement faisant face à la zone racine qui rend le reste des preuves intelligible.
La liste des serveurs de noms de l'IANA est importante car elle empêche de sur-interpréter AS38064. L'enregistrement de délégation nomme ns1 à ns7 sous dns.net.nz. La propre page DNS d'InternetNZ ajoute l'interprétation opérationnelle: ns1 est un serveur de noms unicast néo-zélandais d'InternetNZ; ns2, ns3 et ns4 sont des serveurs de noms anycast néo-zélandais d'InternetNZ; ns5 et ns6 sont des serveurs de noms anycast internationaux de CIRA; ns7 est un serveur de noms anycast international de Netnod. L'architecture n'est pas un chemin Cloud B unique.
C'est un ensemble de fournisseurs et de techniques DNS faisant autorité locaux et internationaux.
La page DNS d'InternetNZ est exceptionnellement explicite sur les raisons de cette conception. Elle indique que l'organisation exploite l'infrastructure DNS faisant autorité pour.nz et les domaines de second niveau, et que cette infrastructure doit être disponible 100% du temps afin qu'il n'y ait jamais de moment où les noms de domaine.nz ne peuvent pas être utilisés. Elle décrit ensuite un réseau de serveurs de noms en Nouvelle-Zélande plus deux fournisseurs internationaux d'un réseau mondial de serveurs de noms.
La page indique que le DNS peut contourner les pannes et que l'anycast sur certains serveurs de noms fait apparaître plusieurs serveurs comme un seul.
Il s'agit du dossier de preuve de service public le plus solide. Il lie le nom.nz, le gestionnaire, le rôle DNS faisant autorité, les serveurs de noms locaux, les fournisseurs internationaux, l'anycast, la diversité et la surveillance en une seule source. Il fixe également une limite. Un inventaire des serveurs de noms n'est pas une trace en direct d'un résolveur. Une déclaration sur la disponibilité à 100% en tant que nécessité opérationnelle n'est pas la même chose qu'un recours universel pour le client. Mais c'est beaucoup plus fort qu'une simple étiquette lâche.
Les détails architecturaux sont importants commercialement car ils indiquent à un acheteur quel type de dépendance.nz crée. Si une entreprise utilise un domaine.nz pour l'accès client, le courrier électronique, l'identité, les paiements ou les communications d'incident, elle dépend de la délégation racine, de la couche faisant autorité.nz, de la chaîne registraire et registre, du propre fournisseur DNS faisant autorité de l'organisation et de ses pratiques de reprise internes. AS38064 est pertinent pour la couche faisant autorité.nz. Ce n'est pas la chaîne entière.
La scission locale et internationale modifie également la question de localité. Les serveurs de noms exploités par InternetNZ sont listés en Nouvelle-Zélande, tandis que CIRA et Netnod apparaissent comme des fournisseurs anycast internationaux. Il s'agit d'une conception de résilience, pas d'une conception de pure localité. Elle peut améliorer l'accessibilité et la diversité, mais elle signifie aussi que le service.nz ne doit pas être décrit comme uniquement local simplement parce que le ccTLD est celui de la Nouvelle-Zélande.
L'affirmation correcte est plus étroite: InternetNZ publie des nœuds DNS faisant autorité en Nouvelle-Zélande et utilise des fournisseurs anycast internationaux pour une diversité géographique et topologique supplémentaire.
La page DNS décrit également la surveillance. InternetNZ indique que tous les serveurs de noms sont surveillés localement et à distance, que le trafic est capturé, agrégé et analysé pour comprendre les caractéristiques de réponse et l'utilisation client, et qu'une surveillance externe des performances des serveurs de noms secondaires.nz est disponible via RIPE NCC DNSMON. Cela compte car l'anycast peut rendre l'observation locale trompeuse. Une requête depuis un réseau peut atteindre un nœud; une requête depuis un autre réseau peut en atteindre un autre.
La surveillance doit être suffisamment distribuée pour voir le service depuis plusieurs endroits.
L'enregistrement de délégation et l'inventaire DNS rendent donc Cloud B utile, mais seulement comme une pièce. Ils montrent pourquoi un enregistrement AS38064 existe et pourquoi les preuves de peering comptent. Ils montrent aussi pourquoi un examen sérieux doit inclure l'inventaire des serveurs de noms, les fournisseurs internationaux, la surveillance et l'actualité de la délégation, plutôt que de s'arrêter au nom du réseau.
Le registre est une surface opérationnelle distincte
L'enregistrement du registre n'est pas le même que l'enregistrement de routage, mais il est inséparable de l'assurance opérationnelle. InternetNZ indique qu'il exploite le registre pour.nz et tient le registre définitif des noms de domaine.nz. Il appelle la plateforme actuelle le système de registre InternetNZ, développé avec l'Association canadienne des registres Internet et mis en service le 1er novembre 2022. Il a remplacé un système de registre partagé sur mesure initialement développé en 2002. InternetNZ indique également que le registre fournit un accès aux protocoles EPP et WHOIS pour les registraires autorisés.
Cette surface de registre est là où résident de nombreuses décisions de service pratiques. Les registraires doivent créer, renouveler, mettre à jour et gérer les noms de domaine. Les titulaires de domaine dépendent des flux de travail des registraires et de l'état du registre pour rester précis. La distribution DNS dépend des processus de registre et de génération de zone. La disponibilité WHOIS est importante pour les vérifications opérationnelles et la responsabilité.
Un enregistrement de routage peut montrer où un préfixe de serveur de noms anycast est visible, mais il ne montre pas si une mise à jour de domaine a traversé le registre et est entrée dans la zone.
Le matériel public d'InternetNZ donne un certain contexte commercial ici. La page du registre indique des frais de nom de domaine en gros de 18 NZD par domaine par an, hors TVA, tandis que les registraires fixent les prix de détail. Cela ne tarife pas Cloud B comme un service séparé. Cela montre l'économie sous-jacente du domaine: InternetNZ exploite le registre, les registraires vendent aux titulaires de domaine, et le coût de l'infrastructure est intégré dans le système de domaine.nz plutôt que d'être exposé comme un poste anycast distinct.
Pour un acheteur, cette distinction est importante. Une entreprise ne peut généralement pas remplacer la couche faisant autorité du TLD.nz pour son domaine.nz. Elle peut choisir d'utiliser un domaine.nz, quel registraire utiliser, quel fournisseur DNS faisant autorité utiliser pour sa propre zone, comment concevoir des serveurs de noms redondants, comment surveiller la résolution et comment préparer des communications alternatives si la résolution de domaine échoue. Le registre.nz et le DNS du TLD font partie de la limite d'infrastructure partagée.
L'enregistrement du système de registre InternetNZ explique également pourquoi les enregistrements obsolètes sont une préoccupation opérationnelle réaliste. Les données du registre, la génération de zone, la signature DNSSEC et la distribution des serveurs de noms sont des processus liés. Lorsqu'un registraire met à jour des données, la question n'est pas seulement de savoir si une route existe.
La question est de savoir si la mise à jour entre correctement dans le registre, apparaît dans le matériel de zone approprié, est signée correctement, se distribue à l'infrastructure faisant autorité et est visible par les résolveurs après la prise en compte du TTL et du comportement du cache.
Le bulletin de statut d'InternetNZ du 13 juillet 2026 rend cela visible. Il décrivait une maintenance de distribution de zone DNS et indiquait que les mises à jour des primaires de distribution DNS seraient suspendues pendant la fenêtre de maintenance. Il indiquait également que le DNS continuerait à servir le contenu de zone d'avant la maintenance. C'est exactement le genre d'enregistrement qui transforme un nom « cloud » abstrait en un flux de travail opérationnel. La disponibilité peut continuer tandis que la fraîcheur est temporairement suspendue.
Si une organisation attend une mise à jour DNS pendant cette fenêtre, sa question concerne le moment de la distribution, pas l'existence d'AS38064.
La surface du registre porte également des implications de gouvernance. La Domain Name Commission indique qu'InternetNZ l'a nommée en vertu d'un accord d'exploitation pour superviser et réglementer l'espace de nom de domaine.nz. Les fonctions de la DNC incluent l'application des règles.nz, l'autorisation et le retrait des autorisations de registraire, le règlement des litiges, les services à la clientèle, l'enquête sur les plaintes des registraires et les rapports.
Les propres principes TLD d'InternetNZ indiquent que les opérations de registre et de registraire au sein d'un TLD doivent être séparées et que la politique du TLD doit être déterminée par des processus ouverts multipartites.
Ces enregistrements comptent car un registre n'est pas seulement un logiciel. C'est un ensemble de rôles. InternetNZ exploite le registre et le DNS. Les registraires interagissent avec le registre. La DNC supervise le marché et les règles. Les titulaires de domaine interagissent principalement via les registraires. Les opérateurs réseau et les résolveurs voient le comportement DNS. Tout article ou note d'approvisionnement qui transforme Cloud B en un service autonome efface ce modèle opérationnel.
La preuve AS38064 est réelle, mais limitée
AS38064 est la preuve de ressource réseau la plus claire pour NZ TLD Anycast Cloud B. APNIC liste AS38064 comme NZ-AS-NS1-AP et le décrit comme l'ASN pour le peering anycast des serveurs de noms du TLD NZ. Le pays est la Nouvelle-Zélande. L'enregistrement d'organisation est InternetNZ. L'enregistrement APNIC inclut les coordonnées de maintenance, de notification et d'abus d'InternetNZ, avec la boîte aux lettres[email protected]validée le 26 mai 2026. C'est une preuve plus forte qu'une mention de marque car elle provient de l'enregistrement régional du registre Internet pour la ressource numérique.
PeeringDB ajoute la vue d'interconnexion. L'entrée NZ TLD Anycast Cloud B liste InternetNZ comme organisation, donne AS38064, identifie le type de réseau comme non lucratif, liste quatre préfixes IPv4 et quatre préfixes IPv6, montre le statut RIR ok, et enregistre une dernière mise à jour le 28 janvier 2026. Sa politique de peering est ouverte, sans exigence de ratio ou de contrat. Il liste le peering public à AKL-IX et APE avec des ports 1G, et des installations incluant DataCentre220 et ICONZ House à Auckland plus Umbrellar CHC1 à Christchurch.
BGP.tools ajoute une vue de routage observationnelle. Il identifie AS38064 comme InternetNZ (.nz tld), le montre actif et alloué sous APNIC, donne une date d'enregistrement du 25 juillet 2008, liste trois /24 IPv4 et sept /48 IPv6 originés, et montre des upstreams et pairs à travers la Nouvelle-Zélande et d'autres pays. Ses préfixes originés incluent 202.46.189.0/24 et 2001:dce:d454::/48, des plages qui correspondent à l'inventaire DNS d'InternetNZ pour ns4.dns.net.nz.
Cette correspondance soutient l'idée qu'AS38064 est attaché à une adresse DNS faisant autorité.nz réelle, tout en nécessitant encore de la prudence quant à l'affectation exacte des nœuds et à l'état de routage en direct.
Les preuves montrent également une structure frère. PeeringDB liste NZ TLD Anycast Cloud A comme un réseau InternetNZ distinct sous AS45285, avec ses propres installations. Cela compte car Cloud B n'est pas l'ensemble du parc anycast. C'est l'un des enregistrements de réseau public nommé autour du service.nz. Un examinateur ne doit pas déduire qu'une liste d'installations Cloud B équivaut à l'empreinte DNS.nz complète, car l'inventaire DNS inclut plusieurs serveurs de noms et fournisseurs internationaux.
L'anycast lui-même impose une limite à ce qui peut être affirmé. La RFC 4786 décrit l'anycast comme une adresse de service stable annoncée depuis plusieurs nœuds de service indépendants. C'est particulièrement courant pour la redondance DNS, mais le système de routage choisit le nœud pour une requête. Le même guide avertit que la surveillance est plus difficile car la disponibilité observée varie selon l'emplacement du client et l'ensemble des clients utilisant un nœud anycast particulier n'est ni statique ni déterministe de manière fiable.
C'est pourquoi un point d'échange PeeringDB ne peut pas prouver un chemin de résolveur. Les entrées AKL-IX et APE montrent où AS38064 se connecte publiquement. Elles ne montrent pas quel nœud a répondu à un résolveur récursif particulier, si le fournisseur d'un résolveur a choisi un chemin plutôt qu'un autre, ce qui s'est passé lors d'un flap de route, ou si la latence des requêtes s'est améliorée pour un groupe d'utilisateurs spécifique. L'anycast peut localiser le trafic et améliorer l'accessibilité, mais la preuve pour une décision de service est la mesure depuis les réseaux pertinents.
L'enregistrement public AS38064 est donc précieux car il permet de meilleures questions. Quelles adresses de serveurs de noms faisant autorité d'InternetNZ sont originées par quels ASN? Quels pairs et upstreams sont importants pour les réseaux d'accès néo-zélandais? Quels résolveurs internationaux voient quel bassin? Les annonces de routes et la surveillance DNS sont-elles alignées? Pendant la maintenance, les réponses faisant autorité sont-elles restées disponibles pendant que les mises à jour étaient suspendues?
Ces questions utilisent l'enregistrement réseau sans lui demander de répondre à des questions d'application, de registre ou de support.
Pour une équipe infrastructure, l'enregistrement doit être conservé comme preuve d'attribution et de surface de routage. Il ne doit pas être utilisé comme preuve de résilience complète par lui-même. Une bonne diligence garde la limite de couche: APNIC pour l'identité de la ressource, PeeringDB pour les indices d'interconnexion, les outils BGP pour les routes et préfixes observés, l'inventaire DNS pour la conception du service faisant autorité, et des tests de résolveur réels pour le comportement côté utilisateur.
La localité est mixte par conception
L'enregistrement.nz a un centre de gravité néo-zélandais, mais pas une empreinte technique exclusivement néo-zélandaise. InternetNZ est le gestionnaire du ccTLD. L'IANA liste ses contacts à Wellington. InternetNZ indique qu'il exploite l'espace de domaine.nz et le registre définitif.nz. APNIC place AS38064 en Nouvelle-Zélande et le lie au peering anycast des serveurs de noms du TLD NZ. PeeringDB liste les installations Cloud B à Auckland et Christchurch. InternetNZ publie des contacts de bureau local, de compte et de support registraire. Ce sont des signaux de localité forts.
Dans le même temps, la page DNS d'InternetNZ indique qu'elle utilise deux fournisseurs internationaux d'un réseau mondial de serveurs de noms. Le tableau des serveurs de noms liste CIRA pour ns5 et ns6 et Netnod pour ns7, chacun comme anycast international multiple. Ce n'est pas une note de bas de page accidentelle. Cela fait partie de l'architecture de disponibilité. Un TLD national doit être accessible de l'intérieur et de l'extérieur du pays; la diversité DNS faisant autorité internationale peut réduire le risque qu'un problème de réseau local ou régional rende le domaine difficile à résoudre ailleurs.
La question, alors, est de savoir quel type de localité est revendiqué. Si la revendication est « InternetNZ est un opérateur néo-zélandais pour.nz », le dossier public est solide. Si la revendication est « AS38064 est une ressource de routage néo-zélandaise pour le peering anycast des serveurs de noms.nz », APNIC et PeeringDB la soutiennent. Si la revendication est « le parc DNS faisant autorité.nz inclut des serveurs de noms exploités en Nouvelle-Zélande », l'inventaire DNS d'InternetNZ la soutient. Si la revendication est « tout le traitement DNS.nz est local à la Nouvelle-Zélande », les preuves ne la soutiennent pas.
Cette distinction est importante pour la souveraineté des données et la localité. Les requêtes DNS sont des signaux opérationnels, pas la même chose que des bases de données clients, mais elles peuvent encore révéler quels noms sont résolus et d'où. Une organisation avec des attentes strictes de localité ne doit pas supposer que chaque interaction DNS faisant autorité reste en Nouvelle-Zélande simplement parce que le TLD est national. Elle doit lire l'architecture des serveurs de noms comme une conception de résilience mixte locale et internationale.
La même chose s'applique aux données du registre. InternetNZ tient le registre définitif et publie des canaux de responsabilité locaux, mais les preuves publiques examinées ici n'exposent pas chaque emplacement de données interne, processus de sauvegarde ou dépendance fournisseur. Le système de registre InternetNZ a été développé avec CIRA, et les pages DNS listent CIRA et Netnod comme fournisseurs internationaux pour les serveurs de noms. Ces faits ne sont pas des problèmes en soi; ce sont des enregistrements qui doivent être traités explicitement lorsque la localité fait partie d'un examen des risques.
Pour un titulaire de domaine.nz, le contrôle pratique de la localité se situe principalement en dessous du TLD. L'organisation peut choisir son registraire, s'assurer que la propriété du compte est à jour, verrouiller les domaines critiques, maintenir des contacts précis, utiliser DNSSEC le cas échéant, sélectionner un fournisseur DNS faisant autorité pour sa propre zone, placer le DNS secondaire délibérément et surveiller depuis les réseaux pertinents. Elle ne peut pas rendre la couche faisant autorité du TLD.nz locale uniquement en configurant son propre domaine.
Cela signifie que « registre néo-zélandais » doit être lu comme un ancrage juridictionnel et opérationnel responsable, pas comme un isolement. Le système.nz est gouverné par des institutions néo-zélandaises et exploité par InternetNZ, avec une empreinte faisant autorité néo-zélandaise publiée. Il est également délibérément connecté à l'infrastructure DNS internationale. La résilience et la localité sont toutes deux présentes, mais elles ne sont pas la même exigence.
Un examen d'entreprise bien mené doit donc documenter la localité par couches. Le gestionnaire du TLD est InternetNZ. Le registre est InternetNZ. Le registraire est celui que le titulaire de domaine a choisi parmi les registraires autorisés. Les serveurs de noms faisant autorité du TLD incluent des nœuds néo-zélandais d'InternetNZ et des fournisseurs anycast internationaux. Le propre DNS faisant autorité du titulaire de domaine peut être chez un autre fournisseur et dans une autre géographie. Le courrier, le web, l'identité et les services d'application peuvent être encore ailleurs. Cloud B aide pour une couche de ce diagramme.
Le support est limité aux rôles
Les preuves de support sont l'un des domaines les plus faciles à exagérer. InternetNZ publie les détails du support du registre, mais le modèle de support est basé sur les rôles. Pour les problèmes de domaine.nz, InternetNZ dit aux titulaires de contacter d'abord leur registraire. En cas de problème avec le registraire, la Domain Name Commission est le régulateur et la voie de recours. Pour les registraires autorisés, InternetNZ publie des informations de support technique, des contacts pendant les heures ouvrées et une escalade urgente en dehors des heures ouvrées.
La page de support du registre donne des détails opérationnels utiles. Les heures ouvrées normales sont du lundi au vendredi, de 08h30 à 17h30. Le contact préféré du registre est[email protected]. InternetNZ indique qu'il répondra aux demandes des registraires dans un délai d'un jour ouvrable dans la mesure du possible. Pour un contact urgent en dehors des heures ouvrées, un opérateur de centre d'appels prend les détails et les transmet au support du registre, avec une réponse attendue à l'appel dans les 15 minutes. Pendant les heures ouvrées, une voie d'escalade existe également si la ligne de support du registre ne peut être jointe après deux tentatives.
C'est une preuve de support local significative. Elle lie l'opération du registre à un numéro de téléphone néo-zélandais, un email, des heures ouvrées et une procédure d'escalade. La page de contact renforce la piste de contact avec le bureau, les contacts généraux, de compte, de presse et de support technique des registraires. APNIC lie également le contact d'abus d'AS38064 à[email protected]et enregistre la validation de la boîte aux lettres le 26 mai 2026.
Mais la portée doit rester intacte. Ce n'est pas une preuve que chaque titulaire de domaine obtient un support d'ingénierie direct du registre. Ce n'est pas une preuve que chaque problème de résolveur sera diagnostiqué via le support du registraire. Ce n'est pas une garantie qu'un problème de routage Internet public peut être résolu via un email de support de domaine. Le modèle de support dépend de si le demandeur est un titulaire, un registraire, un opérateur réseau, un régulateur, un contact presse ou un entité de la communauté technique.
Les preuves de travail local sont également présentes, mais limitées. Le rapport annuel 2024-2025 d'InternetNZ liste 41 employés permanents et des bureaux à Auckland et Wellington. Une présentation DNS-OARC de mai 2023 indiquait qu'InternetNZ avait une équipe d'exploitation de cinq personnes gérant l'infrastructure, le réseau, la virtualisation, les applications, le registre, le DNS et la signature DNSSEC.
Une page de poste de responsable de l'infrastructure produit décrivait la responsabilité de l'exploitation continue du registre.nz dépendant au niveau national et du service DNS associé, de la gestion de l'équipe derrière l'infrastructure et les systèmes de.nz, de la réalisation des attentes de niveau de service et de l'évitement de la dette technique.
Ces enregistrements soutiennent le sujet du travail et du support local mieux qu'un langage d'entreprise générique ne le ferait. Ils montrent que l'opération.nz est attachée à des fonctions organisationnelles nommées, des bureaux, des rapports d'employés et des contacts publiés. Néanmoins, une page de poste et une présentation de conférence ne sont pas des listes d'effectifs en direct. Elles doivent être utilisées pour montrer la responsabilité opérationnelle publique, pas pour revendiquer un nombre fixe d'ingénieurs actuels ou une couverture nommée pour chaque incident.
L'enregistrement de la Domain Name Commission ajoute une autre limite de support. La DNC indique que ses fonctions incluent les services à la clientèle pour aider à résoudre les demandes du public, l'enquête sur les plaintes des registraires et le règlement des litiges. Cela signifie que l'écosystème de support.nz est délibérément divisé: le registraire d'abord pour les titulaires, la DNC pour la supervision et les litiges, le support du registre d'InternetNZ pour les registraires autorisés et l'exploitation de l'infrastructure. Un titulaire de domaine qui ignore ces rôles peut perdre du temps lors d'un incident.
Pour les utilisateurs opérationnels, le bon test de support est simple. Le registraire peut-il prouver qui contrôle le compte de domaine? Les contacts du registre sont-ils à jour? L'organisation sait-elle quand contacter son registraire, quand soulever un problème auprès de la DNC, et quand un opérateur réseau doit contacter InternetNZ à propos de preuves techniques? Les communications d'incident sont-elles indépendantes du domaine.nz protégé? L'organisation a-t-elle testé WHOIS, la connexion au registraire, les changements DNS et les voies d'escalade avant une crise?
La valeur du support vient de cette chorégraphie. NZ TLD Anycast Cloud B donne un indice réseau. Les enregistrements de support d'InternetNZ donnent des indices de contact et d'escalade. La DNC donne des indices de gouvernance et de litige. Aucun de ces enregistrements ne doit être substitué au propre manuel d'exploitation de l'organisation.
Le statut et la reprise sont le test pratique
La page de statut publique est l'une des sources de preuve les plus utiles car elle montre le comportement opérationnel en mouvement. Le 13 juillet 2026, la page de statut d'InternetNZ a enregistré un élément de maintenance de distribution de zone DNS. L'avis indiquait que les mises à jour des primaires de distribution DNS seraient suspendues pendant la fenêtre de maintenance, que les modifications du système de registre InternetNZ ne seraient pas reflétées dans le DNS jusqu'à la fin de la fenêtre, et que le DNS continuerait à servir le contenu de zone d'avant la maintenance.
Il listait les zones affectées incluant nz, co.nz, org.nz, net.nz et d'autres, et dirigeait les questions vers la boîte aux lettres du registre.
Ce seul avis contient plusieurs leçons. Premièrement, la disponibilité et la fraîcheur peuvent se séparer. Le DNS peut continuer à servir le contenu de zone existant tandis que les nouvelles modifications du registre attendent. Deuxièmement, le processus de registre et de distribution DNS est une chaîne. Un changement dans l'IRS doit atteindre les primaires de distribution puis le parc DNS faisant autorité. Troisièmement, la transparence de la maintenance compte.
Un titulaire de domaine qui surveille un changement a besoin de savoir si le retard est une faute, une mise en cache, une maintenance, un retard du registraire ou un comportement du résolveur local.
Le matériel de statut de juillet incluait également des avis de danger de reconfiguration réseau et des notifications de danger des systèmes DNS sans impact attendu. Ces avis ne doivent pas être gonflés en preuves de défaillance. Ce sont des preuves que le contrôle des changements est rendu visible. Pour une infrastructure qui doit être disponible en continu, les avis de danger font partie du dossier d'assurance car ils montrent que le changement de routine peut être séparé de la réponse aux incidents et que les parties prenantes peuvent vérifier si un retard est attendu.
Les rapports annuels et trimestriels ajoutent une vue à plus long terme. Le rapport annuel 2024-2025 d'InternetNZ indique une disponibilité DNS de 100% sur l'année et une disponibilité de 100% pour les opérations DNSSEC incluant les transitions de roulement sécurisées. Il rapporte 750 909 noms de domaine.nz sous gestion au 31 mars 2025, une disponibilité EPP de 99,997% contre un objectif de 99,9%, et une disponibilité WHOIS de 99,99% contre un objectif de 99,9%. Le rapport d'activité T1 2025-2026 liste 100% pour le DNS, le registre EPP, le portail du registre et le WHOIS port 43 sur avril, mai et juin 2025.
Ces métriques sont utiles, mais ce sont des métriques agrégées. Elles ne prouvent pas un chemin de résolveur particulier, un flux de travail de registraire ou un résultat au moment du changement. Elles ne remplacent pas la surveillance en direct. Elles montrent qu'InternetNZ rend compte de la disponibilité du DNS, du registre et du WHOIS comme services distincts, ce qui est exactement la séparation qu'un examinateur sérieux doit préserver.
Les preuves de reprise sont plus solides car InternetNZ a du matériel public d'apprentissage des incidents. Une présentation DNS-OARC sur l'incident DNSSEC.nz de 2023 décrivait le remplacement du registre, le processus modifié de génération de zone et l'intégration avec l'infrastructure DNS existante utilisant un modèle multi-signataire DNSSEC. Elle décrivait un problème causé par une inadéquation entre le comportement TTL des anciens enregistrements DS et le nouveau comportement du registre, conduisant à la suppression précoce d'une ancienne clé DNSSEC pour les résolveurs avec des enregistrements en cache.
Elle décrivait ensuite les options de réponse, l'engagement de la communauté technique, l'attente tout en communiquant et en conseillant les vidages de cache, la suspension ultérieure de la distribution de zone, la vérification manuelle de chaque zone DS et DNSKEY, et la reprise de la distribution sans problèmes signalés.
Cet enregistrement ne doit pas être utilisé pour rouvrir un ancien incident. Sa valeur est qu'il montre le genre de questions de reprise que toute dépendance à.nz doit poser. Les TTL sont-ils alignés avec les roulements de clés? L'opérateur peut-il reproduire les symptômes de résolveur rapportés en externe? Les canaux communautaires sont-ils prêts? La distribution de zone peut-elle être suspendue? Chaque zone affectée peut-elle être vérifiée manuellement? Les plans de réponse aux incidents sont-ils pratiqués et révisés?
La présentation elle-même listait des leçons autour de la pratique de la réponse aux incidents et de la révision des processus même après des tests approfondis.
Pour NZ TLD Anycast Cloud B, c'est le cœur de la question technique. L'enregistrement reste-t-il frais, gouverné, attribuable, interrogeable et récupérable sous une utilisation répétée? La fraîcheur provient des mises à jour de l'IANA, des notifications de statut, de la validation RIR et de l'inventaire DNS actuel. La gouvernance provient d'InternetNZ, de la DNC et des principes TLD. L'attribution provient d'APNIC, de PeeringDB et des contacts publiés. L'interrogeabilité provient de la surveillance DNS, de la diversité des serveurs de noms et de l'observation des résolveurs.
La récupérabilité provient de la maintenance, de l'apprentissage des incidents et de l'escalade du support.
Une organisation qui dépend de.nz doit refléter cette structure en interne. Elle doit surveiller ses propres noms depuis des points de vue néo-zélandais et étrangers. Elle doit suivre le statut du registraire et du registre. Elle doit savoir quand les enregistrements faisant autorité ont changé et quand les caches récursifs peuvent être en retard. Elle doit garder des canaux de communication alternatifs en dehors du domaine protégé. Elle doit tester DNSSEC et la récupération du compte registraire avant qu'un problème de clé ou de contact ne survienne.
Elle doit enregistrer quels faits proviennent de l'IANA, d'InternetNZ, d'APNIC, de PeeringDB, de l'observation BGP et de sa propre surveillance.
L'anycast ne supprime pas le besoin de ce travail. Il rend certaines défaillances moins visibles depuis un seul endroit et certaines résiliences plus fortes sur de nombreux endroits. Le travail de l'acheteur est de mesurer depuis les endroits qui comptent.
Le cas commercial est la dépendance, pas l'achat
Parce que NZ TLD Anycast Cloud B n'est pas présenté comme un produit cloud normal, la question commerciale doit être recadrée. Il n'y a aucune preuve publique qu'une entreprise achète Cloud B comme un service séparé avec une liste de fonctionnalités, un niveau d'abonnement et une équipe de compte. La décision économique concerne la dépendance à.nz et les coûts d'exploitation sécurisée autour de cette dépendance.
Pour une entreprise néo-zélandaise, un domaine.nz peut être commercialement précieux car il signale une identité locale et la confiance. Il peut également être attendu par les clients, les régulateurs, les partenaires ou le public. Le rapport annuel d'InternetNZ montre l'ampleur de cet écosystème, avec plus de 750 000 noms de domaine.nz sous gestion en mars 2025. Le coût de la couche registre apparaît indirectement à travers les prix de gros et les prix de détail des registraires, pas à travers l'ASN anycast.
Les alternatives directes sont rarement simples. Une entreprise peut choisir un autre TLD, maintenir un portefeuille défensif sur plusieurs TLD, utiliser un domaine global comme sauvegarde, ou concevoir des communications critiques qui ne reposent pas sur un seul domaine. Mais si elle veut l'identité.nz, elle dépend du registre.nz et du DNS faisant autorité, qu'elle étudie ou non AS38064. Le choix n'est pas « Cloud B ou TLD auto-géré ». Le choix est la quantité de gouvernance, de surveillance et de repli qu'elle construit autour de la dépendance à.nz.
Le coût de la fiabilité commence par l'hygiène du registraire. L'organisation a besoin de contacts à jour, de verrous de domaine le cas échéant, d'un processus de renouvellement testé, de contrôles d'accès multipersonnes, de reprise hors bande et d'une responsabilité claire pour DNSSEC. Un prix de domaine annuel bas ne signifie pas un faible risque opérationnel. Une défaillance de nom de domaine peut perturber les sites web, les courriels, l'identité, les flux de paiement et la réponse aux incidents.
Le coût de la localité commence par l'architecture. Si l'organisation utilise.nz pour un signal de confiance local mais héberge le DNS faisant autorité, les courriels et les services web à l'étranger, le TLD ne rend pas l'ensemble du service local. Si elle a besoin d'une résilience face à la Nouvelle-Zélande, elle doit surveiller la résolution depuis les réseaux d'accès néo-zélandais et les résolveurs internationaux. Si elle a besoin d'une portée mondiale, elle doit également tester la résolution à l'étranger. La couche TLD.nz n'est qu'une partie du chemin.
Le coût du support commence par la clarté des rôles. Le registraire gère le titulaire du domaine en premier. Le support du registre d'InternetNZ est principalement pour les registraires autorisés, avec des voies d'escalade urgentes. La DNC gère la supervision, les litiges et les plaintes. Les preuves au niveau du réseau peuvent nécessiter un opérateur réseau ou un canal de la communauté technique. Une organisation mature doit savoir quelle voie s'applique avant une urgence.
Le coût de migration est plus subtil. Quitter.nz peut être coûteux car les noms sont intégrés dans les habitudes des clients, les certificats, la réputation des courriels, les fournisseurs d'identité, le matériel imprimé, les contrats et la visibilité dans la recherche. Changer de registraire peut être plus facile mais nécessite toujours des verrous de domaine, des codes d'autorisation, une précision des contacts et un timing. Changer de DNS faisant autorité pour un domaine de second niveau peut être fait, mais nécessite une gestion minutieuse du TTL, une gestion DNSSEC et une validation.
Aucun de ces mouvements ne modifie la couche faisant autorité du TLD.
C'est pourquoi la valeur commerciale du dossier public d'InternetNZ est la transparence plutôt qu'une garantie de vente conventionnelle. Un titulaire de domaine peut voir le gestionnaire.nz, les serveurs de noms, le système de registre, la page de statut, les contacts de support, la répartition de la gouvernance, les enregistrements AS anycast et les rapports de disponibilité. Il peut construire un cas de risque autour de preuves publiques au lieu de prendre le TLD national pour acquis.
Le point faible est la preuve de résultat au niveau client. Les archives publiques ne montrent pas comment un registraire particulier a géré une crise, comment une entreprise particulière s'est remise d'une mauvaise configuration, ou comment chaque résolveur s'est comporté lors d'un changement de route. Cette preuve doit venir des propres tests et incidents de l'organisation. Le dossier public établit la base de référence; l'acceptation opérationnelle doit être générée par l'utilisateur.
Une décision de service répétable
Une décision répétable autour de NZ TLD Anycast Cloud B doit commencer par nommer la couche sous examen. Si la question est l'identité, utiliser l'IANA, InternetNZ et APNIC. Si la question est la conception DNS faisant autorité, utiliser l'inventaire DNS d'InternetNZ et les déclarations de surveillance. Si la question est le routage, utiliser APNIC, PeeringDB, l'observation BGP et des tests de résolveur directs. Si la question est le flux de travail du registre, utiliser le système de registre InternetNZ, la documentation du registraire et les notifications de statut.
Si la question est le support, utiliser les limites de rôles du registraire, d'InternetNZ et de la DNC. Si la question est la reprise, utiliser l'historique des statuts, l'apprentissage des incidents et les tests internes.
Le premier contrôle est la fraîcheur des preuves. L'enregistrement de délégation de l'IANA a une date de dernière mise à jour. PeeringDB a des dates de dernière mise à jour et de statut RIR. APNIC a des dates de validation des contacts. Les pages de statut ont des dates d'événements. Les rapports annuels et d'activité d'InternetNZ ont des périodes de rapport. Une copie obsolète d'un enregistrement ne doit pas décider d'une limite de service actuelle. Le dossier de preuve doit avoir des dates de révision et des propriétaires.
Le deuxième contrôle est l'attribution. AS38064 doit pointer vers InternetNZ dans APNIC et dans les répertoires de routage publics. Les adresses des serveurs de noms doivent correspondre à l'inventaire DNS publié. Le support du registraire doit pointer vers les contacts d'InternetNZ pour les registraires autorisés et la DNC pour les plaintes et litiges publics. Si l'un de ces enregistrements diverge, la différence doit être investiguée avant qu'elle ne devienne un incident.
Le troisième contrôle est l'interrogeabilité. L'organisation doit tester ses propres noms.nz depuis plusieurs réseaux, incluant les réseaux d'accès néo-zélandais, les résolveurs publics et les emplacements étrangers pertinents pour les clients. Elle doit vérifier les réponses faisant autorité, la validation DNSSEC, le comportement TTL et la propagation après des changements planifiés.
Si une panne ou un retard se produit, elle doit savoir si le problème se situe dans sa propre zone, son propre fournisseur DNS faisant autorité, le registraire, le registre.nz, la couche de serveurs de noms TLD, les résolveurs récursifs ou les réseaux d'accès locaux.
Le quatrième contrôle est la discipline du changement. L'avis de maintenance de distribution DNS du 13 juillet 2026 est un rappel que le DNS peut continuer à servir d'anciennes données pendant que les mises à jour sont suspendues. Ce n'est pas un échec lorsqu'il est divulgué et planifié. Cela devient un risque lorsqu'une entreprise planifie des changements DNS urgents sans vérifier le statut du registre ou du DNS. Les changements de domaine critiques doivent être planifiés autour des fenêtres de maintenance, des TTL, de DNSSEC et de la disponibilité du support du registraire.
Le cinquième contrôle est la reprise. Gardez une voie de reprise du registraire, un accès au compte de domaine, des contacts secondaires, des procédures DNSSEC, une propriété de renouvellement de certificat, des communications de sauvegarde et des alertes de surveillance en dehors du domaine qui pourrait échouer. Révisez les leçons de l'incident DNSSEC comme guide pratique: testez extensivement, mais supposez que des problèmes peuvent encore survenir; pratiquez la réponse aux incidents; soyez prêt à communiquer; et gardez les étapes de vérification explicites.
Le sixième contrôle est la gouvernance. Les principes TLD d'InternetNZ et le dossier de supervision de la DNC montrent que.nz n'est pas gouverné seulement par des ingénieurs. Les règles, les litiges, l'autorisation des registraires, la confiance publique et les processus multipartites façonnent l'environnement opérationnel. Pour les utilisateurs réglementés ou d'intérêt public, les preuves de gouvernance doivent siéger à côté des preuves de routage.
Ce cadre mène à un jugement équilibré. NZ TLD Anycast Cloud B n'est pas un nom vide. AS38064 est lié à InternetNZ, au peering anycast des serveurs de noms du TLD NZ, à des enregistrements d'échange et d'installations publics, et à des données de routage observées. Il se trouve à l'intérieur d'un dossier.nz plus solide qui inclut la délégation IANA, les opérations DNS et de registre d'InternetNZ, les rapports de statut, les métriques de performance, les contacts de support, la supervision de la DNC et l'apprentissage des incidents.
Le dossier n'est pas non plus suffisant pour soutenir des affirmations larges par lui-même. Il ne prouve pas chaque chemin de requête.nz. Il ne transforme pas un ASN anycast en une plateforme cloud. Il ne rend pas tout le traitement DNS local à la Nouvelle-Zélande. Il ne garantit pas le flux de travail du registraire d'un titulaire de domaine ou le résultat de la reprise. Il ne remplace pas les tests depuis les réseaux et services qui comptent pour l'utilisateur.
La meilleure conclusion est donc étroite et utile. Traitez NZ TLD Anycast Cloud B comme un point de preuve de routage public et d'anycast pour le parc DNS faisant autorité.nz. Traitez les enregistrements DNS, de registre, de support, de statut et de gouvernance d'InternetNZ comme le cadre opérationnel autour de lui. Traitez la fiabilité, la localité, le support et le coût de migration comme des questions qui doivent être répondues sur l'ensemble de la chaîne du nom de domaine, pas par le seul nom Cloud B. Lorsque les enregistrements sont alignés et restent frais, l'enregistrement anycast fait partie de l'assurance.
Lorsqu'ils sont lus hors couche, le même enregistrement devient un raccourci vers une confiance non fondée.