Un seul tableau de bord pour chaque domaine client
Arrêtez de vous connecter à 20 bureaux d’enregistrement et panneaux DNS différents. Gérez le DNS de chaque client depuis un seul compte NexDNS, avec des clés API à portée définie, des opérations en masse et une API qui s’adapte à votre automatisation.
Le goulot d’étranglement DNS du travail en agence
Quand le DNS de vos clients est réparti chez 20 fournisseurs différents, les changements simples deviennent des tâches de plusieurs heures.
DNS dispersé chez les bureaux d’enregistrement
Le DNS de chaque client se trouve là où le domaine a été enregistré – GoDaddy, Namecheap, le bureau d’enregistrement du mois – avec des interfaces incompatibles.
Aucune piste d’audit pour les changements clients
Un enregistrement DNS a cassé quelque chose et personne ne se souvient qui a modifié quoi. Les panneaux de bureau d’enregistrement ne gardent pas un véritable historique.
Les changements DNS en masse prennent plusieurs heures
Mettre à jour SPF / DKIM pour 50 clients signifie 50 connexions distinctes sur 50 panneaux différents.
Le départ d’un client est compliqué
Un client part et veut son DNS, mais il est sous des identifiants de registrar partagés – impossible de remettre seulement le sien sans donner accès à tout.
Ce que NexDNS apporte à une agence
Une gestion DNS centralisée, pensée pour les workflows multi-clients.
- Tous les clients dans un seul tableau de bord
- Toutes les zones clients dans un seul compte NexDNS. Recherchez et filtrez parmi toutes les zones depuis une seule connexion.
- API REST pour les opérations en masse
- Mettez à jour SPF sur 50 zones clientes via un script. Ajoutez un enregistrement CAA partout.
nexdns applyavec un fichier YAML traite toute la flotte en une seule commande. - Clés API à portée définie par intégration
- Votre playbook Ansible obtient une clé API à portée définie sur
records.write. Votre supervision en obtient une à portéerecords.read. Révocables par intégration. - Journal d’audit complet
- Chaque changement de zone et d’enregistrement est journalisé avec qui/quand/quoi. Responsabilité client simple à établir quand quelque chose casse.
- Export de zone lorsqu’un client part
- Exportez n’importe quelle zone au format BIND à tout moment et remettez les fichiers au client ou à son nouveau prestataire – pas de verrouillage.
- Plugins Terraform, OctoDNS, ACME
- Si vous gérez l’infrastructure client en tant que code, NexDNS dispose de l’outillage. Provider Terraform, synchronisation OctoDNS, plugin Certbot DNS-01 inclus.
Comment les agences démarrent en général
Du premier import client à l’automatisation standardisée.
-
1
Créer un seul compte NexDNS pour l’agence
Starter convient jusqu’à 10 zones – c’est souvent suffisant pour démarrer avec quelques clients avant de passer à Pro ou Business.
-
2
Importer les zones clients existantes
Exportez la zone de chaque client depuis son fournisseur DNS actuel au format BIND, puis importez en lot via
nexdns zone importou depuis le tableau de bord. OctoDNS peut synchroniser plusieurs sources simultanément. -
3
Mettre à jour les enregistrements NS chez les bureaux d’enregistrement des clients
Pour chaque client, mettez à jour les enregistrements NS pour qu’ils pointent vers NexDNS. Les zones secondaires vous permettent de préparer et de vérifier la propagation avant la bascule. À partir du plan Business, vous pouvez utiliser vos propres noms de serveurs en marque blanche au lieu de ceux de NexDNS.
-
4
Mettre en place l’automatisation
Terraform pour le provisionnement de nouvelles zones. La CI/CD exécute des commandes CLI
nexdnspour les changements d’enregistrements. Le plugin Certbot gère automatiquement les certificats wildcard. -
5
Construire un outillage interne
Ajoutez des commandes
nexdnsau runbook de votre agence. Documentez les conventions par client (groupe NS, politique DNSSEC, TTL par défaut) dans des fichiers YAML versionnés dans git.
Questions fréquemment posées
Les questions les plus courantes, avec des réponses.
Parcourir la documentation-
Non, et c’est voulu. NexDNS est le backend de votre agence : vos clients ne se connectent jamais à NexDNS. Vous gérez chaque zone client depuis votre compte unique et fournissez ce dont un client a besoin via vos propres outils. Les clés API couvrent tout le compte et sont conçues pour votre automatisation ; elles ne peuvent donc pas être remises à un client en particulier.
-
Oui, de deux façons. Clonez une zone entièrement configurée (par exemple MX + SPF + DKIM + DMARC par défaut pour une stack e-mail managée) vers chaque nouveau domaine, ou conservez un YAML déclaratif des enregistrements standard et déployez-le sur de nombreuses zones avec
nexdns applyou OctoDNS. Relancer apply maintient les zones correspondantes synchronisées. -
Le chemin le plus rapide passe par OctoDNS avec un provider source pour chaque fournisseur. Pointez-le sur NexDNS comme cible et laissez la synchronisation s’opérer. Pour les fournisseurs sans prise en charge OctoDNS, l’export BIND suivi de
nexdns zone importdans une boucle shell couvre la plupart des cas. -
C’est exactement à cela que servent le provider Terraform et les workflows YAML OctoDNS. Décrivez la structure des zones en code, committez dans git, relisez en pull request, appliquez via la CI. Même workflow que l’Infrastructure-as-Code pour le reste de votre stack.
-
Exportez ses zones au format BIND, remettez les fichiers au client ou à son nouveau fournisseur. S’il migre vers un autre compte NexDNS, l’export/import tient en une seule commande CLI. Aucun verrouillage de plateforme.
Regroupez le DNS de vos clients dans un seul tableau de bord
Conservez les hooks d’automatisation que vous utilisez déjà.