Zone Import Methods

When creating a new DNS zone in DNScale, you have several options for importing your existing records. Whether you're migrating from another provider or starting fresh, DNScale makes it easy to get your DNS configuration set up quickly.

Import Methods Overview

DNScale supports four methods for creating and populating DNS zones:

1. Manual Creation -- Start with an empty zone and add records individually
2. BIND Zone File Import -- Upload a standard BIND format zone file
3. Provider Import -- Connect directly to Cloudflare or AWS Route 53
4. DNS Discovery -- Automatically discover records from live DNS

Each method has trade-offs in terms of completeness, convenience, and requirements. The right choice depends on what access you have to your current DNS setup.

Manual Zone Creation

The simplest option is to create an empty zone and add records manually through the dashboard. This is ideal for:

• New domains without existing DNS records
• Small zones with just a few records
• Testing and development environments

Simply enter your domain name, select your region, and start adding records one by one. DNScale automatically creates the SOA record and NS records as system records.

For zones with more than a dozen records, consider one of the automated import methods below. Manual entry becomes error-prone as the number of records grows, and a single typo in a CNAME or MX record can cause service disruptions.

BIND Zone File Import

If you have a BIND-format zone file export from your current DNS provider, you can import it directly. BIND format is the industry standard supported by most DNS providers and is defined in RFC 1035.

Understanding the Zone File Format

A BIND zone file is a plain text file with a specific structure:

$ORIGIN example.com.
$TTL 3600
 
; SOA record (DNScale will replace this with its own)
@       IN  SOA     ns1.old-provider.com. admin.example.com. (
                    2026030901  ; Serial
                    3600        ; Refresh
                    900         ; Retry
                    1209600     ; Expire
                    300         ; Minimum TTL
                    )
 
; NS records (DNScale will replace these)
@       IN  NS      ns1.old-provider.com.
@       IN  NS      ns2.old-provider.com.
 
; A and AAAA records
@       IN  A       93.184.216.34
@       IN  AAAA    2606:2800:220:1:248:1893:25c8:1946
www     IN  CNAME   example.com.
 
; Mail records
@       IN  MX  10  mail.example.com.
mail    IN  A       93.184.216.35
 
; TXT records
@       IN  TXT     "v=spf1 include:_spf.google.com ~all"
 
; SRV records
_sip._tcp   IN  SRV  10 60 5060 sip.example.com.
 
; CAA records
@       IN  CAA  0 issue "letsencrypt.org"

Key formatting rules:

• $ORIGIN sets the base domain (trailing dot required)
• $TTL sets the default TTL for records that don't specify one
• @ represents the zone apex (the domain itself)
• Lines starting with ; are comments
• Hostnames without a trailing dot are relative to $ORIGIN
• Hostnames with a trailing dot are fully qualified (absolute)

Supported Record Types

• A, AAAA (IPv4 and IPv6 addresses)
• CNAME (canonical names)
• MX (mail servers with priority)
• TXT (text records including SPF, DKIM, DMARC)
• NS (nameserver delegation)
• SRV (service records)
• CAA (certificate authority authorisation)
• PTR (reverse DNS)
• TLSA (DANE certificate records)
• SSHFP (SSH fingerprint records)

How to Export from Common Providers

Most DNS providers offer zone file export:

• cPanel/WHM: DNS Zone Editor -> Export Zone File
• Plesk: DNS Settings -> Export
• BIND servers: Copy the zone file from /var/named/ or /etc/bind/zones/
• PowerDNS: Use pdnsutil list-zone example.com to export records

Validating Before Import

Before importing, check your zone file for common issues:

# If you have BIND tools installed, validate the zone file
named-checkzone example.com /path/to/zonefile
 
# Check for syntax errors
# Common issues: missing trailing dots, wrong record format, invalid TTLs

DNScale will skip the SOA and apex NS records from your import file, as it manages these as system records. All other records will be imported as-is.

Provider Import

Connect directly to your existing DNS provider to import zones and records automatically. This is the fastest way to migrate when you have API access, and it's the most complete method since it captures all records exactly as they exist.

Cloudflare

To import from Cloudflare, you need an API token with the following permissions:

• Zone:Read -- Required to list your zones
• DNS:Read -- Required to read DNS records

Creating a Cloudflare API Token

1. Go to dash.cloudflare.com/profile/api-tokens
2. Click "Create Token"
3. Use the "Custom token" template
4. Add permissions:
   • Zone -> Zone -> Read
   • Zone -> DNS -> Read
5. Set zone resources (All zones or specific zones)
6. Create token and copy it

Once connected, you'll see all your Cloudflare zones and can select which ones to import. DNScale will pull in all DNS record types that Cloudflare supports, including proxy status information.

Cloudflare-specific features like orange-cloud proxy settings, page rules, and Workers don't transfer — only the DNS records themselves. If you relied on Cloudflare's proxy for SSL/TLS, you'll need to set up certificates separately. Consider adding CAA records to control certificate issuance.

Amazon Route 53

To import from AWS Route 53, you need IAM credentials with the following permissions:

• route53:ListHostedZones -- Required to list hosted zones
• route53:ListResourceRecordSets -- Required to read DNS records

Required IAM Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "route53:ListHostedZones",
        "route53:ListResourceRecordSets"
      ],
      "Resource": "*"
    }
  ]
}

Creating AWS Access Keys

1. Go to IAM Console
2. Create a new user or use an existing one
3. Attach the policy above
4. Generate access keys under Security credentials

Provide the Access Key ID and Secret Access Key to import your Route 53 zones.

Route 53 alias records (which are AWS-specific) will be imported as standard A or AAAA records where possible. Health check configurations and routing policies don't transfer.

DNS Discovery

DNS Discovery automatically queries the live DNS for a domain and discovers existing records. This is useful when:

• You don't have access to export zone files or provider APIs
• You want to verify what's currently published before migrating
• You're taking over management of an existing domain
• You need a quick audit of a domain's current DNS setup

How It Works

1. Enter the domain name you want to discover
2. DNScale queries the authoritative nameservers
3. Common record types are probed automatically
4. Discovered records are presented for review
5. Select which records to import

Discovered Record Types

DNS Discovery checks for:

• A and AAAA records (root and common subdomains)
• MX records (mail servers)
• TXT records (SPF, DKIM, DMARC, verification)
• NS records (nameservers)
• CNAME records (common aliases like www, mail, ftp)
• CAA records (certificate authority restrictions)
• SRV records (common service patterns)

Limitations

DNS Discovery can only find records that are publicly resolvable. It may not discover:

• Internal/private records
• Wildcard records (unless specifically queried)
• Records for subdomains not in the common discovery list
• Records with very short TTLs that have expired
• TLSA and SSHFP records for specific services

For complete migrations, use BIND file import or provider import when possible.

Choosing the Right Method

Planning a Zero-Downtime Migration

Migrating DNS without downtime requires careful planning:

Before Migration

1. Audit your current records -- Export or discover all existing records and verify they're correct
2. Lower TTL values -- Reduce TTLs to 300 seconds (5 minutes) 24-48 hours before migration so cached records expire quickly
3. Document email records -- MX, SPF, DKIM, and DMARC records are critical and must be exact
4. Note any provider-specific features -- CDN proxying, URL forwarding, health checks

During Migration

1. Import records using your chosen method
2. Verify all records in the DNScale dashboard before switching nameservers
3. Check critical records -- especially MX, A/AAAA, and TXT
4. Update nameservers at your domain registrar to point to DNScale

After Migration

1. Monitor DNS propagation -- changes can take up to 48 hours globally
2. Verify resolution from multiple locations:

   dig example.com @ns1.dnscale.eu
   dig example.com @ns2.dnscale.eu
   dig MX example.com +short
   dig TXT example.com +short

3. Test email delivery -- send and receive test emails
4. Restore TTLs -- once everything is confirmed working, return TTL values to normal
5. Keep the old provider active for a few days as a safety net

Don't delete your zones at the old provider immediately after migration. Keep them for at least a week. If something goes wrong, you can revert the nameserver change at your registrar and be back on the old provider within minutes.

After Import

Once your zone is imported:

1. Review records -- Check that all records imported correctly
2. Update nameservers -- Point your domain to DNScale nameservers
3. Verify propagation -- Use dig to confirm changes are visible
4. Monitor -- Check the dashboard for any resolution issues
5. Set up multi-user access if needed for team management

Conclusion

DNScale provides flexible options for creating and importing DNS zones. Whether you're starting fresh, migrating from another provider, or discovering existing records, you can get your DNS set up quickly and reliably. For the most complete migration, use provider import or BIND file import. For a quick start when you don't have export access, DNS discovery fills the gap. Regardless of method, always verify your records after import and test critical services before decommissioning your old DNS provider.