Skip to content

Knowledgebase

Connect bunny.net DNS and configure an optional vanity nameserver pair

domain-nexus, domains-dns

The bunny.net DNS connection uses the account API key sent to the provider's DNS API. Configure ordinary DNS first, then add vanity nameservers only after the underlying nameserver and registrar host arrangement has been prepared. Entering branded names in a form does not create a working authoritative service.

01 Connect the provider account

  1. Obtain the authorised account API key from the bunny.net dashboard's account API settings. Keep it separate from storage-zone passwords, pull-zone names and customer registrar keys.
  2. In Domain Nexus Servers, add a connection and choose bunny.net DNS.
  3. Paste the secret into API key.
  4. For an initial standard setup, leave both vanity nameserver fields empty. Save and run the connection check.
  5. Use an owned zone to read records and add a temporary TXT value. Verify the completed operation and the provider's authoritative answer.

02 Configure optional branded nameservers

When you have arranged supported vanity nameservers with the provider, enter both Vanity nameserver 1 and Vanity nameserver 2. The adapter expects a pair. Use the actual assigned arrangement and prepare any required host/glue records at the parent registrar. Do not assume a CNAME alone can replace every registrar glue requirement.

Review SOA email when using vanity nameservers. Set an operational contact associated with the DNS service. Confirm the resulting zone NS and SOA data and query both branded nameservers before publishing them in a customer package.

Common questions

Does this also configure bunny.net CDN?

No. DNS records can point a name at a CDN endpoint, but CDN pull zones, hostname authorisation, certificates and application settings have their own configuration. A successful DNS connection does not provision them.

Can every bunny.net record feature be copied to another provider?

Use the record types and metadata supported by the installed adapter and every selected target. Provider-specific redirects, scripts or routing features are not automatically equivalent to portable DNS records. Review the changeset before replication.

For DNSSEC, follow the provider capability shown for the zone and publish the corresponding parent DS through the registrar. Verify the public chain after changing delegation or branded nameservers.

Sources and further reading

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support

Powered by WHMCompleteSolution