We do not limit how many records can be created and managed per domain (zone). Create as many as you need without restrictions from our infrastructure. This gives you the freedom to implement detailed DNS setups that include numerous subdomains, service records for APIs, verification strings for third-party services, failover configurations, and specialized email routing rules all within the same zone file.

Unlimited records per zone supports agile infrastructure management. As your application scales, you can add new records for microservices, multiple A records for load balancing, or numerous TXT records for various email authentication methods without hesitation. This removes the need to delete old records to stay under a quota or split configurations across extra domains.

#DNS Zone Fundamentals

A DNS zone is an administrative segment of the Domain Name System. It contains a collection of resource records that define how queries for the domain and its subdomains should be handled. The zone file begins with an SOA record that includes the primary nameserver, the responsible person's email address, serial number, and timing parameters for zone transfers and caching. Subsequent records provide the actual mappings. Because there are no artificial limits on the number of additional records, you can treat the zone as a complete directory of all network resources associated with the domain.

#Common Record Types

  • A and AAAA Records: Map hostnames to IPv4 or IPv6 addresses. These are essential for directing web traffic and other IP-based services to the correct servers.
  • MX Records: Specify mail servers responsible for accepting email. Multiple MX records with different priority values enable failover and load distribution.
  • TXT Records: Store arbitrary text strings. Primarily used for SPF policies to prevent email spoofing, DKIM keys for authentication, and domain verification challenges.
  • CNAME Records: Create aliases so one name points to another. Commonly used to map www to the apex domain or to reference external services without hard-coding IPs.
  • NS Records: Identify the authoritative nameservers for the zone. These must be consistent with the delegation set at your domain registrar.

#Example DNS Zone File

Zone files follow a standardized text format. The example below demonstrates a functional configuration with multiple record types. Adjust values to match your IPs, mail servers, and verification tokens. When editing through a control panel, equivalent records are usually added via form fields rather than raw text.

ini 
$ORIGIN example.com.
$TTL 3600

@ IN SOA ns1.example.com. admin.example.com. (
    2024010101 ; serial
    7200       ; refresh
    3600       ; retry
    1209600    ; expire
    3600       ; minimum
)

@ IN NS ns1.example.com.
@ IN NS ns2.example.com.

@ IN A 192.0.2.1
www IN A 192.0.2.1
mail IN MX 10 mail.example.com.
@ IN TXT "v=spf1 include:_spf.google.com ~all"
api IN CNAME api-endpoint.example.net.

#Best Practices and Common Pitfalls

Even without record limits, thoughtful DNS management improves reliability and performance. Use the minimum TTL necessary for your change frequency. Group related records under logical subdomains. Monitor query logs to identify heavily used records. Keep the zone file clean by removing stale entries that point to decommissioned services. Test every change with command-line tools such as dig or nslookup before considering the update complete.

  • Always increment the SOA serial number when manually editing zone files so secondary nameservers detect the update.
  • Avoid placing a CNAME record at the zone apex, as it conflicts with other record types required there.
  • Ensure SPF TXT records do not exceed the maximum number of DNS lookups to prevent delivery problems.
  • Double-check fully qualified names end with a trailing dot in zone files; omission can cause incorrect name appending.

#Practical Takeaway

The absence of restrictions on DNS record counts empowers you to design precisely the internet presence your applications demand. Start with the minimum records required for basic operation and expand the zone as requirements grow. Keep zones organized, documented, and regularly audited. Consult the control panel DNS editor documentation or open a support request when implementing advanced configurations involving multiple record types or custom TTL strategies.