Gandi LiveDNS uses a personal access token scoped to the organisation and resources you intend to manage. The current Domain Nexus field expects that token. Gandi's older API-key authentication is deprecated, so do not reuse an old key merely because an earlier script accepted it.
01 Prepare the personal access token
In Gandi's organisation settings, select the organisation that owns the DNS resources and use its sharing/token workflow to create the token. Grant the LiveDNS permissions required by your deployment and select the intended resources. Review its expiration and store the secret when issued.
A token for the wrong organisation can authenticate without exposing the zones you expected. Write down the organisation identity and connection purpose before leaving the provider console. This makes future rotation and customer migrations easier to verify.
02 Connect the DNS service
- In Domain Nexus Servers, add a connection and choose Gandi LiveDNS.
- Paste the complete value into Personal Access Token.
- Save and run the connection check, which reads the available LiveDNS domains.
- Inspect an owned zone and its assigned nameservers. Use a temporary TXT change to prove write access, then read the provider record back.
- Add the verified connection to the intended package. Review existing customer records before applying defaults or broad record-set changes.
Common questions
Why is a domain registered at Gandi missing from LiveDNS?
Registration and DNS service are separate. The domain may use another DNS provider, belong to a different organisation or fall outside the token's resource scope. Confirm the intended LiveDNS zone rather than assuming every registration appears automatically.
Can I publish Gandi's generic nameservers for every zone?
Use the nameserver set that applies to the actual zone and account arrangement. Check the provider's returned zone information and the current registrar delegation, especially where custom NS records or an existing migration are involved.
If an update is refused, review token scope and expiry before changing DNS. If the provider accepted it but public answers differ, investigate delegation and caching. Keep provider-specific features separate from portable record data when planning replication to another DNS service.
Related articles
- Discover existing DNS zones and link only verified customer ownership
- Rotate a DNS provider credential across all connections that use it
- Synchronize a DNS package across multiple servers and select its master
- Connect Cloudflare with a scoped token and the correct account
- Connect ClouDNS with a master API user or a scoped sub-user