Information Security Best Practices and Recommendations

Information Security Best Practices and Recommendations

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.


NotesRecommended 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.


3. Securing DNS zone transfers using AXFR  

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  


TSIG, or Transaction Signature, helps authenticate DNS zone transfers between your primary DNS server and CloudDNS. TSIG keys can be generated using supported algorithms and configured on both sides of the zone transfer relationship.


NotesBest 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.

 


Info

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.


5. Using CloudDNS as a secondary nameserver  

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.

NotesRecommended configuration steps  

You should:

  1. Add the domain in CloudDNS as a Secondary zone.

  2. Provide your primary nameserver IP address in CloudDNS.

  3. Configure your primary DNS server to allow AXFR only to CloudDNS nameserver IPs.

  4. Configure TSIG keys on both your primary DNS server and CloudDNS.

  5. Verify that the initial zone transfer is successful.

  6. Confirm that zone serial numbers are updated correctly after DNS changes.

  7. Monitor the zone transfer status to ensure CloudDNS has the latest zone copy.


InfoRegistrar 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.



6. Using CloudDNS as a primary nameserver  

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.


NotesRecommended configuration steps  

You should:

  1. Create the domain zone in CloudDNS.

  2. Add all required DNS records.

  3. Validate critical records such as A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, NS, and SRV.

  4. Review TTL values before going live.

  5. Update your domain registrar with the CloudDNS nameservers.

  6. Verify DNS resolution after propagation.

  7. Enable DNSSEC if required.

  8. If DNSSEC is enabled, update the DS record at your registrar.

  9. Monitor DNS resolution and zone health after migration.


NotesMigration 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.



7. DNSSEC recommendations  

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.


NotesBest 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.


InfoCustomer 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.

NotesRecommended 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  


CloudDNS can help maintain DNS availability when your primary nameserver or datacenter becomes unavailable, provided the domain is configured correctly.

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.

NotesRecommended 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.


10. TTL and SOA recommendations  

TTL and SOA values directly affect DNS propagation, failover behavior, and cache duration.


NotesRecommended 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.


11. DNS record security recommendations  

You should regularly review DNS records to reduce security and operational risks.

NotesRecommended 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.


12. Access control recommendations  

DNS changes can directly impact website availability, email delivery, application access, and security. You should restrict CloudDNS access to authorized personnel only.


NotesRecommended 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.


13. Operational monitoring recommendations  

You should continuously monitor DNS health, configuration changes, and zone transfer status.

NotesRecommended 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.


14. Customer responsibility summary  

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


15. Conclusion  

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.

 

                    New to ADSelfService Plus?

                      • Related Articles

                      • Security Audit in ManageEngine CloudDNS

                        Security Audit in ManageEngine CloudDNS The Audit page can be accessed by selecting the Audit menu from the left menu bar.   The Audit page help you to continuously evaluate the overall security posture of your domains using security audit logs to ...
                      • Guide to DNS records

                        The following are the types of resource records supported by ManageEngine CloudDNS: A (IPv4): Address record that maps a domain name to an IPv4 address, allowing a domain to be associated with a physical machine or resource on an IPv4 network. AAAA ...
                      • Creating Filters in ManageEngine CloudDNS

                        Filters in ManageEngine CloudDNS Filters in CloudDNS are essential tools for optimizing and securing network traffic, ensuring users get the best possible experience, and providing businesses with the ability to enforce their operational policies ...
                      • DNS records setup in ManageEngine CloudDNS

                        How to create and update DNS records? What is a DNS record? The DNS records (also known as zone files or resource records) are the constituent files of a Zone or a Domain that carry the essential instructions that help the DNS resolver quickly ...
                      • Getting Started with ManageEngine CloudDNS

                        Introduction to ManageEngine CloudDNS ManageEngine CloudDNS is ManageEngine's first critical DNS infrastructure management product to enrich your experience in the internet landscape. CloudDNS enables you to effortlessly manage DNS records and ...