DNSControl parity

DNSControl feature parity in DNSMigrator maps dnscontrol get-zones, dnscontrol preview, and dnscontrol push to provider imports, live managed-zone plans, and typed-confirmation pushes. The tables below identify the exact UI, CLI command, implementation, or documented gap for each DNSControl surface.

DNSControl feature parity scope and implementation map#

Only paths reachable from the current web app or dnsmigrator CLI are marked supported here.

Status terms: Supported means the construct changes the imported canonical model or a reachable plan. Import-only means script logic runs while converting but has no independent UI control. Preserved-only means metadata round-trips but does not cause a provider operation. Unavailable means the browser runtime rejects it or there is no matching operation.

Providers#

The generated table is the catalog source of truth for DNS and registrar roles, status and capabilities. Provider-specific setup pages use the catalog slug.

Hurricane Electric is cataloged but planned because DNSControl automates its web UI with account credentials and a TOTP seed rather than an official API. GoDaddy remains available even though current DNSControl no longer includes it. DNSMigrator also has providers beyond DNSControl, including NextDNS rewrites.

DNSControl get-zones, preview, and push#

DNSControl’s removed ppreview and ppush aliases do not need equivalents. DNSMigrator does not expose DNSControl’s --cmode modes; managed-zone provider writes run sequentially.

Top-level JavaScript functions#

Standard record functions#

All rows below are accepted by the browser importer and represented in the canonical zone model. The managed record editor uses structured forms for provider-supported types. A later provider plan can still mark a record unsupported.

The canonical model also understands obsolete SPF record sets from BIND/provider input. The importer’s DNSControl-style DSL creates SPF policy data through TXT or SPF_BUILDER, and exports obsolete SPF as TXT with a warning.

Provider-specific record functions#

Supported provider features are not portable DNS. During migration, translateZone blocks one when the destination catalog does not advertise the same type and explains that it must be recreated manually. The Bunny and Porkbun compatibility-only functions above are skipped before they reach translation.

Domain modifiers and nameservers#

Managed-zone planning combines explicit nameservers with provider nameservers returned when a destination zone is created, honoring each configured nameserver count. Existing provider-managed apex NS records are otherwise excluded from ordinary plans. See Multi-provider DNS and Import transforms.

Builders#

Each builder is available under Records → Use a builder and through dnsconfig.js import.

Browser config import has no DNS resolver, so imported SPF flattening remains unflattened with a warning. The managed-zone SPF builder calls the app’s TXT resolver and can flatten there.

Record modifiers and compatibility constants#

Arbitrary metadata objects are accepted, but unrecognized record metadata produces a warning and is dropped from the canonical record. Unrecognized domain metadata is retained as strings and re-exported as a JavaScript object.

Export behavior#

The Config as code tab exports the saved zone, not unsaved edits. It generates provider and registrar declarations, domain modifiers, records, ignores, transforms and supported metadata. CLI export --format dnsconfig uses the same generator for one BIND file.

Export deliberately warns about lossy cases:

• non-weighted routing has no emitted DNSControl modifier and is dropped;
• Hurricane Electric DDNS keys are redacted by default;
• obsolete SPF record types become TXT;
• unsupported record types become comments;
• records outside the zone are skipped;
• SOA serial is provider-managed and is dropped;

Generated JavaScript should be reviewed before dnscontrol push. See dnsconfig.js import and export.

Known deviations#

• Glob matching follows DNSControl’s implementation where older documentation differs.
• DMARC and CAA builders reject invalid policy, URI, tag, range and flag input instead of retaining it.
• Names are lowercased but are not converted to IDNA; use ASCII or already-punycode names.
• Provider declarations resolve known DNSControl IDs, catalog IDs, slugs and recognizable key names. An inferred type is reported as a warning so you can verify the mapping.
• D_EXTEND and INCLUDE require the source declaration to appear earlier in the script.
• The browser importer preserves JavaScript-generated desired state, not arbitrary JavaScript source formatting or comments.
• Provider capability checks happen after import. A valid DSL function can still be unsupported by an attached provider and will appear in Changes rather than being sent silently.

Features beyond DNSControl#

DNSMigrator adds a separate migration lifecycle with destination snapshots, live destination re-planning, authoritative record verification, operation-scoped rollback, guided or automatic registrar cutover, DNSSEC sequencing, bulk CSV migrations and shareable reports. Managed zones add scheduled backups, restore, drift monitoring, workspace roles and signed notification webhooks. These features are documented by their app workflows rather than represented as extra dnsconfig.js functions.