ManageEngine CloudDNS
Information Security Best Practices and Recommendations
1. Overview
ManageEngine CloudDNS helps you host, manage, and secure authoritative DNS zones with high availability and centralized control.
This document provides recommended security and operational practices for using CloudDNS, especially around user data protection, DNS zone transfers, primary and secondary DNS configuration, DNSSEC, failover readiness, and DNS record hygiene.
These recommendations are intended to help you strengthen your DNS security posture, reduce misconfiguration risks, and maintain reliable DNS resolution.
2. User data handled by CloudDNS
CloudDNS follows a minimal data collection approach. The user information collected is limited to:
First name
Last name
Email address
Password
CloudDNS is currently hosted in the US data center. Therefore, the above user data will be stored in the US data center.
Your data stored in CloudDNS is protected using encryption at rest. Sensitive information such as email address and password is handled securely as part of CloudDNS data protection controls.
Recommended practices You should:
Use unique user accounts for each administrator.
Avoid sharing administrator credentials.
Use strong passwords.
Remove user access when it is no longer required.
Review CloudDNS user access periodically.
Assign access only to authorized DNS administrators.
DNS zone transfers are commonly performed using the AXFR protocol. AXFR allows a secondary DNS server to receive a full copy of the DNS zone from the primary DNS server.
While AXFR is required in secondary DNS configurations, it must be secured properly. If left open or unrestricted, AXFR can expose the complete DNS zone file to unauthorized systems.
To secure zone transfers, CloudDNS strongly recommends using TSIG keys.
4. Recommended control for AXFR: Use TSIG keys
Best practices for AXFR security You should:
Enable AXFR only for zones where secondary DNS is required.
Use TSIG keys for all zone transfers between your primary DNS server and CloudDNS.
Allow zone transfers only to CloudDNS nameserver IPs.
Avoid open or unrestricted AXFR configuration.
Use strong TSIG algorithms supported by your DNS infrastructure.
Use unique TSIG keys wherever possible.
Rotate TSIG keys periodically or whenever compromise is suspected.
Monitor zone transfer logs for failed or unauthorized transfer attempts.
Disable AXFR for zones that do not require zone transfer.

Important: CloudDNS supports secure zone transfer configuration, but you must ensure that AXFR permissions, TSIG keys, and IP-based restrictions are correctly configured on your primary DNS infrastructure.
You can configure CloudDNS as a secondary authoritative DNS service. In this model, your DNS server remains the primary nameserver, and CloudDNS receives zone data through AXFR-based zone transfers.
Recommended configuration steps You should:
Add the domain in CloudDNS as a Secondary zone.
Provide your primary nameserver IP address in CloudDNS.
Configure your primary DNS server to allow AXFR only to CloudDNS nameserver IPs.
Configure TSIG keys on both your primary DNS server and CloudDNS.
Verify that the initial zone transfer is successful.
Confirm that zone serial numbers are updated correctly after DNS changes.
Monitor the zone transfer status to ensure CloudDNS has the latest zone copy.
Registrar recommendation for secondary DNS failover If you expect CloudDNS to provide uninterrupted DNS resolution when your primary nameserver or datacenter becomes unavailable, you should list only CloudDNS nameservers at your domain registrar.
This is because registrars treat all listed NS records equally. They do not distinguish between “primary” and “secondary” nameservers.
You should avoid listing both your own primary nameservers and CloudDNS nameservers together at the registrar when CloudDNS is expected to provide seamless failover. Doing so can cause inconsistent DNS responses or split-brain DNS behavior if both DNS environments are not fully synchronized.
You can also use CloudDNS as the primary authoritative DNS provider for your domains.
In this model, the DNS zone is created and managed directly in CloudDNS, and CloudDNS nameservers are published at your domain registrar.
Recommended configuration steps You should:
Create the domain zone in CloudDNS.
Add all required DNS records.
Validate critical records such as A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, NS, and SRV.
Review TTL values before going live.
Update your domain registrar with the CloudDNS nameservers.
Verify DNS resolution after propagation.
Enable DNSSEC if required.
If DNSSEC is enabled, update the DS record at your registrar.
Monitor DNS resolution and zone health after migration.
Migration recommendations Before moving a domain to CloudDNS as primary, you should:
Export and back up your existing zone file.
Review all DNS records for accuracy.
Reduce TTL values before migration to allow faster propagation.
Validate email, website, VPN, application, API, and third-party service records.
Maintain a rollback plan during the migration window.
CloudDNS supports manual DNSSEC key generation and zone signing operations to help you protect the integrity and authenticity of DNS responses.
CloudDNS uses ECDSA-based DNSSEC key algorithms, including Algorithm 13, which represents ECDSA Curve P-256 paired with the SHA-256 hashing algorithm. This algorithm is used in DNSSEC security records and provides strong cryptographic protection with efficient key sizes.
CloudDNS does not perform automatic DNSSEC key rollover. This is because DNSSEC key updates require corresponding DS record updates at your domain registrar. Incorrect or incomplete DNSSEC rollover can result in DNS validation failures and domain resolution issues.
In CloudDNS, there is no expiry concept for DNSSEC keys. The DNSSEC keys generated in CloudDNS have permanent validity unless you choose to change them. CloudDNS displays the DNSSEC inception timestamp, which indicates when DNSSEC signing was initiated for the domain.
If you suspect that a DNSSEC key may have been exposed, compromised, or if you believe that DNS responses may have been tampered with, you can manually unsign and re-sign the domain in CloudDNS. After re-signing the domain, you must update the corresponding DNSSEC records, such as the DS record, at your domain registrar wherever applicable.
Best practices for DNSSEC You should:
Enable DNSSEC for domains where DNS integrity protection is required.
Use supported DNSSEC algorithms, including ECDSA Algorithm 13: ECDSA Curve P-256 with SHA-256.
Maintain a documented DNSSEC key management process.
Review the DNSSEC status and inception timestamp periodically.
Manually unsign and re-sign the domain if you suspect key exposure, compromise, or DNS response tampering.
Update DS records at your registrar whenever DNSSEC keys are changed or regenerated.
Validate DNSSEC after signing, unsigning, or re-signing a zone.
Restrict DNSSEC signing, unsigning, and re-signing operations to authorized administrators.
Keep a record of DNSSEC changes for audit, validation, and rollback purposes.
Customer responsibility: Since DNSSEC key changes may require registrar-side DS record updates, you are responsible for ensuring that your registrar is updated whenever DNSSEC keys are regenerated or changed in CloudDNS.8. DNSSEC status, inception timestamp, and key validity
CloudDNS displays the DNSSEC status of a signed zone as Current when DNSSEC is active for the domain.
CloudDNS does not define or display an expiry time for DNSSEC keys. Instead, CloudDNS displays the inception timestamp, which indicates when DNSSEC signing was initiated for the domain.
The DNSSEC keys generated in CloudDNS are considered valid permanently within CloudDNS unless you choose to change them. If you want to rotate or refresh the DNSSEC signing state, you can manually unsign and re-sign the domain.
Recommended practices You should:
Periodically verify that the DNSSEC status is shown as Current.
Review the DNSSEC inception timestamp for your signed domains.
Re-sign the domain if you suspect key compromise or DNS response tampering.
Update registrar-side DNSSEC records whenever a key change requires it.
Validate DNSSEC after every signing, unsigning, or re-signing activity.
Maintain an internal review schedule for DNSSEC-enabled critical domains.
9. CloudDNS failover and availability recommendations
When CloudDNS is configured as a secondary DNS provider and zone transfers are enabled from your primary DNS server, CloudDNS serves the latest successfully transferred zone file.
Because CloudDNS is anycast-powered, DNS queries can continue to be answered by CloudDNS nameservers even if your primary datacenter is unavailable.
Recommended configuration for high availability You should:
Configure domains in CloudDNS as secondary zones where required.
Enable AXFR from your primary DNS server to CloudDNS.
Secure AXFR using TSIG keys.
Restrict zone transfers only to CloudDNS nameserver IPs.
Ensure CloudDNS has the latest zone copy.
List only CloudDNS nameservers at the registrar if CloudDNS is expected to provide seamless public DNS availability.
Tune TTL and SOA values based on your availability requirements.
Monitor zone transfer status and serial number updates.
TTL and SOA values directly affect DNS propagation, failover behavior, and cache duration.
Recommended practices You should:
Use lower TTLs before planned DNS migrations or major changes.
Avoid very high TTLs for records that may need emergency updates.
Use appropriate TTLs for stable records to reduce unnecessary DNS query load.
Configure SOA refresh, retry, and expire values carefully.
Ensure SOA serial numbers are incremented after zone changes.
Review TTL and SOA settings as part of your change management process.
You should regularly review DNS records to reduce security and operational risks.
Recommended practices You should:
Remove unused or stale DNS records.
Avoid exposing unnecessary internal hostnames in public DNS.
Maintain accurate SPF, DKIM, and DMARC records for email protection.
Avoid wildcard DNS records unless required.
Review TXT records for outdated verification tokens or sensitive information.
Validate CNAME chains and remove references to retired services.
Ensure MX records point only to authorized mail infrastructure.
Periodically audit DNS records for accuracy and relevance.
DNS changes can directly impact website availability, email delivery, application access, and security. You should restrict CloudDNS access to authorized personnel only.
Recommended practices You should:
Grant CloudDNS access only to authorized DNS administrators.
Avoid shared accounts.
Use least-privilege access wherever applicable.
Remove inactive users.
Review user access periodically.
Maintain internal approval workflows for critical DNS changes.
Restrict DNSSEC and zone transfer configuration changes to senior administrators.
You should continuously monitor DNS health, configuration changes, and zone transfer status.
Recommended practices You should:
Monitor zone transfer success and failure events.
Track SOA serial number changes.
Validate DNS resolution after major updates.
Test failover behavior periodically.
Validate DNSSEC status after DNSSEC changes.
Maintain backups or exports of critical zone files.
Document your primary and secondary DNS architecture.
Keep records of DNS changes for audit and rollback.
Area | Recommendation |
User access | Use unique accounts, strong passwords, and periodic access reviews |
AXFR security | Use TSIG keys and restrict transfers only to CloudDNS IPs |
Secondary DNS | Configure secure AXFR from your primary DNS server to CloudDNS |
Registrar configuration | List only CloudDNS nameservers if CloudDNS is expected to provide seamless failover |
Primary DNS | Validate all records before updating registrar nameservers |
DNSSEC | Use manual signing carefully and update DS records at your registrar after key changes |
DNSSEC key validity | CloudDNS DNSSEC keys do not expire; review the inception timestamp and re-sign if compromise is suspected |
TTL and SOA | Tune values based on your propagation and availability requirements |
DNS records | Remove stale records and avoid exposing unnecessary information |
Monitoring | Monitor zone transfer, DNSSEC status, resolution, and failover behavior |
CloudDNS provides secure and reliable authoritative DNS hosting when configured according to recommended security and operational practices.
You are strongly advised to secure AXFR transfers using TSIG keys, restrict zone transfers to authorized CloudDNS nameserver IPs, follow DNSSEC key management procedures carefully, and configure registrar nameservers based on your availability and failover requirements.
Following these recommendations helps protect your DNS zone data, reduce misconfiguration risks, improve DNS availability, and strengthen the overall security posture of your CloudDNS deployment.