DNS Processing Rules

Configure how DNS changes are calculated and applied

DNS Processing Rules control how DNSDone calculates and applies DNS changes when creating execution plans for your requests. These workspace-level settings define the default behavior for all new DNS requests.

Understanding DNS Processing Rules

When you create a DNS request, DNSDone compares your target records with the domain's existing DNS configuration to generate a step-by-step execution plan. Processing rules help the system make intelligent decisions about what changes are actually needed.

These rules are especially important when:

  • Working with domains that have complex DNS configurations
  • Migrating between different hosting providers
  • Dealing with mixed IPv4 and IPv6 records
  • Preserving existing CNAME records that work correctly

Available Processing Rules

Resolve CNAME records

When this option is enabled, DNSDone checks whether existing CNAME records ultimately resolve to the same IP addresses as your target A or AAAA records.

How it works:

  1. You specify target A/AAAA records (e.g., example.com → 192.0.2.1)
  2. The system detects an existing CNAME record (e.g., example.com → cdn.provider.com)
  3. DNSDone resolves the CNAME to its final IP address
  4. If the IP matches your target, the CNAME is preserved
  5. If it doesn't match, the execution plan includes replacing the CNAME with your A/AAAA records

Why use it:

  • Reduces unnecessary changes when CNAMEs already point to the correct destination
  • Preserves CDN and load balancer configurations that work correctly
  • Minimizes disruption to existing DNS architecture
  • Keeps execution plans focused on actual changes needed

Example scenario:

You want app.example.com to point to 192.0.2.1. The domain currently has:

app.example.com → CNAME → lb.hosting.com
lb.hosting.com → A → 192.0.2.1

With "Resolve CNAME records" enabled, DNSDone detects that the CNAME already resolves to 192.0.2.1 and leaves it unchanged rather than replacing it with an A record.

Avoid IP conflicts

When this option is enabled, DNSDone automatically prevents mixed IPv4 and IPv6 configurations that could cause connectivity issues.

How it works:

  1. You specify A records (IPv4) for a hostname
  2. The system checks if the hostname has existing AAAA records (IPv6)
  3. If you haven't specified any AAAA targets, DNSDone removes the existing AAAA records
  4. This ensures clients don't attempt IPv6 connections when only IPv4 is configured

The same logic applies in reverse: if you specify AAAA records without A records, existing A records are removed.

Why use it:

  • Prevents connectivity failures from incomplete dual-stack configurations
  • Avoids scenarios where some users can't reach your service
  • Ensures consistent behavior across IPv4 and IPv6 clients
  • Simplifies DNS configurations by removing unused record types

Example scenario:

You want www.example.com to point to IPv4 address 192.0.2.1. The domain currently has:

www.example.com → A → 198.51.100.1
www.example.com → AAAA → 2001:db8::1

With "Avoid IP conflicts" enabled, the execution plan includes:

  • Update the A record to 192.0.2.1
  • Remove the AAAA record (since you didn't specify IPv6 targets)

This prevents clients with IPv6 connectivity from trying to use the outdated IPv6 address.

Configuring Processing Rules

  1. Go to Workspace → Settings
  2. Scroll to the DNS Processing Rules section
  3. Enable or disable each option based on your needs:
    • Check Resolve CNAME records to preserve CNAMEs that already resolve correctly
    • Check Avoid IP conflicts to prevent mixed IPv4/IPv6 configurations
  4. Click Save to apply the settings

Important: These settings apply to new DNS requests created after you save them. Existing requests are not affected by changes to workspace processing rules.

Best Practices

  • Start with both enabled – These settings provide sensible defaults for most scenarios
  • Review execution plans – Always check the generated execution plan before sharing with clients
  • Test with examples – Create test requests to see how rules affect execution plans
  • Override when needed – Use per-request overrides for special cases rather than changing workspace defaults