Documentation

Requirements

• macOS 14.0+ or iOS 17.0+
• A DNS provider account or server:
  • Cloudflare — API token with Zone:Edit permissions
  • AWS Route 53 — IAM credentials with Route 53 access
  • Google Cloud DNS — Service account with DNS Admin role
  • BIND9 — Server with TSIG authentication configured

Adding a Provider

DnsEditor supports multiple DNS providers. To add a provider:

1. Open Settings
2. Tap Add Provider
3. Select your provider type (Cloudflare, Route 53, Google Cloud DNS, or RFC2136/BIND9)
4. Enter your credentials (see Providers for details)
5. Add the zones you want to manage

You can add multiple providers and switch between them from the zone list.

Display Options

• Hide Auto-Generated DNSSEC — Hides RRSIG, NSEC, NSEC3, and NSEC3PARAM records. DS, CDS, CDNSKEY, and DNSKEY records are always shown (read-only).
• Clear Filters on Zone Change — Resets search text and record type filter when switching between zones.
• Sync to iCloud — Syncs your configuration and undo history across all your Apple devices.

Why hide DNSSEC records? RRSIG, NSEC, and NSEC3 records are automatically generated by your nameserver — they're not meant for humans to read or modify. RRSIG records contain cryptographic signatures that verify the authenticity of other records. NSEC/NSEC3 records provide authenticated denial of existence (proof that a name doesn't exist in the zone). For your own sanity, keep them hidden.

Cloudflare

Cloudflare offers a free DNS hosting tier with a powerful API. To connect DnsEditor to Cloudflare:

1. Log in to the Cloudflare dashboard
2. Go to My Profile → API Tokens
3. Click Create Token
4. Use the Edit zone DNS template, or create a custom token with:
   • Permissions: Zone → DNS → Edit
   • Zone Resources: Select the zones you want to manage
5. Copy the token and paste it into DnsEditor

Tip: Cloudflare's free tier includes unlimited DNS queries, making it ideal for testing and personal use.

AWS Route 53

Amazon Route 53 is AWS's scalable DNS service. To connect DnsEditor to Route 53:

1. Log in to the AWS IAM Console
2. Create a new IAM user or use an existing one
3. Attach a policy with Route 53 permissions. Minimum required:

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

4. Generate an Access Key ID and Secret Access Key
5. Enter these credentials in DnsEditor along with your AWS region (e.g., us-east-1)

Note: Route 53 does not have a free tier. Hosted zones cost $0.50/month plus query charges.

Google Cloud DNS

Google Cloud DNS is a scalable, reliable DNS service. To connect DnsEditor to Google Cloud DNS:

1. Go to the Google Cloud Console → IAM → Service Accounts
2. Create a new service account
3. Grant the DNS Administrator role (or a custom role with dns.changes.create, dns.resourceRecordSets.*, dns.managedZones.get)
4. Create a JSON key for the service account
5. In DnsEditor, enter your Project ID and paste the JSON key contents

Note: Google Cloud DNS does not have a free tier, but new accounts receive $300 in credits.

RFC2136 (BIND9)

For self-hosted BIND9 servers, DnsEditor uses RFC2136 Dynamic DNS Updates with TSIG authentication:

1. Enter your DNS server address (IP or hostname) and port (default: 53)
2. Paste your TSIG key contents into the key field

The key should be in BIND format:

key "keyname" { algorithm hmac-sha256; secret "base64secret..."; };

After pasting the key, click Parse Key to validate. A green "Key Configured" indicator confirms success, showing the key name and algorithm.

See BIND9 Setup for detailed server configuration instructions.

Zone List Server

We provide a lightweight Python script that runs on your nameserver and returns a JSON list of your primary zones. The script queries BIND9's named-checkconf to enumerate zones.

Download the server files:

• zone_server.py — The zone list server script
• zone-server.service — Systemd service file
• install.sh — Installation script

Installation (Debian/Ubuntu)

1. Download the server files to your nameserver:

   mkdir -p /opt/zone-server && cd /opt/zone-server
   curl -O https://dnsedit.au/server/zone_server.py
   curl -O https://dnsedit.au/server/zone-server.service
   curl -O https://dnsedit.au/server/install.sh
   chmod +x install.sh zone_server.py

2. Edit the service file to use HTTP (recommended):

   nano zone-server.service

   The default configuration uses HTTP on port 8053. This is the recommended setup since the zone list server is typically only used occasionally to populate your zone list.

3. Run the installer:

   sudo ./install.sh

4. Verify the service is running:

   curl http://your-nameserver.example.com:8053/zones

Manual Installation

If you prefer not to use the install script:

1. Copy the script to /usr/local/bin/:

   sudo cp zone_server.py /usr/local/bin/
   sudo chmod +x /usr/local/bin/zone_server.py

2. Copy the service file:

   sudo cp zone-server.service /etc/systemd/system/

3. Enable and start the service:

   sudo systemctl daemon-reload
   sudo systemctl enable zone-server
   sudo systemctl start zone-server

Disable After Use

Since you'll likely only use the zone list server occasionally to populate your zone list, you can disable it after fetching your zones to avoid having the endpoint exposed:

sudo systemctl stop zone-server
sudo systemctl disable zone-server

When you need to add new zones later, simply re-enable and start the service temporarily:

sudo systemctl enable zone-server
sudo systemctl start zone-server

Your zone list is saved in DnsEditor, so you only need to run the server when adding new zones or refreshing the list.

HTTPS Configuration (Optional)

If you prefer to use HTTPS, the zone server supports Let's Encrypt certificates:

1. Edit the service file and comment out the HTTP line
2. Uncomment the HTTPS line and set your certificate path:

   --cert-dir /etc/letsencrypt/live/nameserver.example.com

3. Restart the service:

   sudo systemctl restart zone-server

Using in DnsEditor

1. Open DnsEditor Settings
2. In the Zone List URL field, enter your server URL:

   https://nameserver.example.com/

3. Tap Fetch Zones to retrieve your zone list

The zones will appear in the "Configured Zones" list. You can still add or remove zones manually.

API Response Format

The zone server returns JSON in this format:

{
  "forward": ["example.com", "example.org"],
  "reverse": ["168.192.in-addr.arpa"]
}

If you have your own zone management system, you can implement this endpoint yourself.

TSIG Key Generation

DnsEditor authenticates with BIND9 using TSIG (Transaction Signature) keys. Generate a key on your nameserver using tsig-keygen:

tsig-keygen -a hmac-sha256 dnsedit-key

This outputs a key block you can paste directly into named.conf:

key "dnsedit-key" {
    algorithm hmac-sha256;
    secret "BASE64_SECRET_HERE";
};

Copy the entire key block (including the secret) — you'll need it in both named.conf and in DnsEditor's provider settings.

Zone Definition

Add a zone block to your named.conf (or an included file such as named.conf.local). This example shows a primary zone with TSIG authentication for dynamic updates and zone transfers:

zone "example.com" {
    type master;
    file "/var/cache/bind/example.com.db";
    key-directory "/var/cache/bind/keys/example.com";
    allow-update { key dnsedit-key; };
    allow-query { any; };
    allow-transfer {
        key dnsedit-key;    // DnsEditor
        198.51.100.2;       // secondary-ns1
        203.0.113.5;        // secondary-ns2
    };
    inline-signing yes;
    dnssec-policy dnsedit;
};

Key points:

• allow-update — Lists the TSIG key(s) authorised to send DNS UPDATE requests. This is what DnsEditor uses to add, modify, and delete records.
• allow-transfer — Controls who can perform zone transfers (AXFR). Include the same TSIG key so DnsEditor can fetch the full zone, plus IP addresses of any secondary nameservers.
• key-directory — Where BIND stores the DNSSEC key files. You'll create this directory as part of the setup procedure below.
• inline-signing yes — BIND maintains a separate signed version of the zone automatically. Your zone file stays unsigned and human-readable.
• dnssec-policy — References the DNSSEC policy (see below). Remove this line and inline-signing if you don't want DNSSEC.

DNSSEC Policy

Add a dnssec-policy block to named.conf (outside any zone block). This policy uses ECDSA P-256 keys with a KSK that never expires, so there is no need for parental agents or DS record rotation scripts:

dnssec-policy "dnsedit" {
    dnskey-ttl 2d;
    keys {
        ksk lifetime unlimited algorithm ecdsap256sha256;
        zsk lifetime 60d algorithm ecdsap256sha256;
    };
    max-zone-ttl 86400;
    parent-ds-ttl 600;
    parent-propagation-delay 2h;
    publish-safety 2h;
    retire-safety 2h;
    purge-keys 90d;
    signatures-refresh 15d;
    signatures-validity 25d;
    signatures-validity-dnskey 60d;
    zone-propagation-delay 2h;
};

• ksk lifetime unlimited — The Key Signing Key never rolls over. Once you publish the DS record at your registrar, it stays valid indefinitely. This is the simplest approach and eliminates the need for parental agents or scripts to monitor KSK changes.
• zsk lifetime 60d — The Zone Signing Key rotates every 60 days. BIND handles this automatically — no manual intervention required.
• ecdsap256sha256 — ECDSA P-256 produces compact keys and signatures, keeping DNS responses small. It is widely supported by all major resolvers.
• signatures-validity 25d — Signatures are valid for 25 days and refreshed every 15 days, providing a 10-day window to recover from signing failures.

Why unlimited KSK lifetime? Rolling a KSK requires updating the DS record at your domain registrar — a process that varies by registrar and is often manual. With an unlimited KSK lifetime, you set the DS record once and never touch it again. The ZSK still rotates regularly, maintaining cryptographic freshness where it matters.

Recommended Setup Procedure

Here is a step-by-step procedure for adding a new DNSSEC-signed zone:

1. Add the zone definition to named.conf (or named.conf.local) with the dnssec-policy and inline-signing directives as shown above. Make sure the zone file exists — even a minimal one with just an SOA and NS record is enough.
2. Create the key directory for the zone and set ownership so BIND can write the key files:

   mkdir -p /var/cache/bind/keys/example.com
   chown bind:bind /var/cache/bind/keys/example.com

3. Validate the configuration to catch any syntax errors:

   named-checkconf

4. Load the new zone — use rndc reconfigure to pick up the new zone definition without disrupting existing zones:

   rndc reconfigure

   BIND will load the zone, generate the initial KSK and ZSK, and begin signing automatically. You can verify the keys were created:

   ls /var/cache/bind/keys/example.com/

5. Get the DS record from DnsEditor — open the zone in the app. The DNSKEY records will appear in the record list. Find the KSK (flag 257) and tap it to open QuickLook, then tap "Copy DS Record (SHA-256)".
6. Publish the DS record at your domain registrar's DNSSEC settings. This establishes the chain of trust from the parent zone down to yours.
7. Verify the chain — back in DnsEditor, tap the chain icon (🔗) in the zone toolbar to run DS Chain Validation. All links should show as valid.

With the unlimited KSK lifetime policy, this is a one-time setup. BIND handles ZSK rotation, re-signing, and all other DNSSEC maintenance in the background — you can add and edit records through DnsEditor without ever thinking about DNSSEC again.

Zone List Toolbar

The toolbar above the zone list provides quick access to zone management:

• + — Add a new zone manually
• ↻ — Refresh the zone list
• ⧉ — Toggle the sidebar view

Zone List

The zone list displays all configured zones, organized into forward zones and reverse zones. Each zone shows its serial number and record count. A green checkmark indicates the zone loaded successfully.

• Select Zone — Click a zone to fetch and display its records
• Remove Zone — Swipe left or right-click to remove a zone from the list

Zone Hierarchy

Parent zones with subdomains display a disclosure chevron. Click to expand and reveal child zones indented beneath the parent. In the screenshot, a02.au contains two subdomains: test.a02.au and unsigned.a02.au.

Record List Toolbar

The toolbar above the record list provides these controls:

• Zone name — Shows the current zone with a lock icon and "DNSSEC signed" badge for signed zones
• + — Add a new DNS record
• Filter (⊖▾) — Filter records by type (A, AAAA, MX, etc.)
• Refresh (↻) — Reload the zone from the DNS server
• Zone Scanners — Scan all hosts for TLSA or SSHFP records (see Zone Scanners)
• Chain (🔗) — Validate DNSSEC DS chain (only shown for signed zones)
• Search (🔍) — Search records by name or value

iOS: On iPhone and iPad, less frequently used tools (refresh, undo history, zone scanners, DS chain validation) are grouped in the overflow menu (⋯) to keep the toolbar clean.

Viewing Records

Records are displayed with their name, type, value, and TTL. Use the filter menu to show specific record types, or search to find records by name or value. Click a record type below for details:

Provider Compatibility

Not all DNS providers support every record type. DnsEditor automatically shows only the types available for your active provider. The table below shows which editable record types are supported by each provider:

BIND9 (RFC2136) supports all record types. DNAME, HINFO, and RP are only available with BIND9. LOC records are supported by BIND9 and Cloudflare.

Adding Records

1. Tap the + button in the zone detail view
2. Select the record type
3. Enter the record name (use @ for the zone apex)
4. Fill in the type-specific fields
5. Set the TTL (time-to-live in seconds)
6. Tap Save to push the change to your DNS server

Editing Records

Tap any record to open the editor. Modify the fields as needed and save. The original record is deleted and replaced with the updated version via DNS UPDATE.

SOA records and DNSSEC records (DNSKEY, RRSIG, NSEC) are read-only and cannot be edited directly.

Deleting Records

• Single record — Swipe left or use the context menu
• Multiple records — Enter selection mode, select records, then tap Delete

Deleted records can be restored from the Undo History.

Signed Zones

Zones signed with DNSSEC display an indicator in the toolbar showing a lock icon and "DNSSEC signed" badge. DnsEditor automatically detects signed zones by the presence of DNSKEY or RRSIG records.

For zones hosted on cloud providers (Cloudflare, Route 53, Google Cloud DNS), DnsEditor queries public DNS to detect DNSSEC status, ensuring the DNSSEC badge displays correctly even when provider APIs don't return DNSKEY records.

DS Chain Validation

For DNSSEC-signed zones, tap the chain icon (🔗) to validate the DS record chain from your zone up to the root. This verifies that your zone's delegation signer records are correctly published in the parent zone.

The validation dialog shows:

• Chain Status — Overall validation result (e.g., "Full Chain Valid - 2 of 2 links valid")
• KSK Rollover Detection — Alerts when CDS records differ from published DS records, indicating a key rollover is in progress
• Link Details — Each delegation link (e.g., test.a02.au → a02.au → au) with key tags and algorithm info
• Key Validation — Individual key status showing algorithm (e.g., ECDSA P-256/SHA-256) and validity

Read-Only DNSSEC Records

DNSSEC operational records are protected from editing:

• DNSKEY — Zone signing keys
• RRSIG — Record signatures
• NSEC/NSEC3 — Authenticated denial of existence

You can still manage DS, TLSA, and SSHFP records which are used for trust anchors and certificate pinning.

Opening QuickLook

• macOS — Select a record and press Space, or right-click and choose "View"
• iPad — Select a record and press Space on an external keyboard, or long press and choose "View"
• iPhone — Long press a record and choose "View", or tap a read-only record

Navigating Records

While QuickLook is open, you can move between records without closing and reopening:

• Arrow buttons — Use the up/down chevron buttons in the QuickLook toolbar (all platforms)
• Keyboard — Press ↑ and ↓ arrow keys (macOS and iPad with external keyboard)

The record list scrolls automatically to keep the selected record visible.

Closing QuickLook

• macOS — Press Space or Escape, or close the panel
• iPad — Press Space or Escape, or tap "Done"
• iPhone — Tap "Done" or swipe down

DS Record Generation

When viewing a KSK (Key Signing Key) DNSKEY record in QuickLook, a "Copy DS Record (SHA-256)" button appears. This computes the DS digest from the DNSKEY and copies it to your clipboard in standard format:

keyTag algorithm digestType HEXDIGEST

Paste this directly into your domain registrar's DNSSEC settings to establish the chain of trust for your zone.

TLSA Scanner

The TLSA scanner connects to port 443 on each host, fetches the TLS certificate, and computes DANE-EE (3 1 1) TLSA records using the SPKI SHA-256 hash. Results are categorized as:

• Add — New TLSA records for hosts without existing records
• Update — Existing TLSA records where the certificate hash has changed
• Unchanged — Existing TLSA records that match the current certificate
• Unreachable — Hosts that did not respond on port 443

The scanner also checks Subject Alternative Names (SANs) and warns if the hostname is not covered by the certificate. Review the results and use the checkboxes to select which changes to apply.

SSHFP Scanner

The SSHFP scanner connects to port 22 on each host, fetches all SSH host keys, and computes both SHA-1 and SHA-256 fingerprints for each key type. Results include:

• Add — New SSHFP records for hosts or key types not yet in DNS
• Fingerprint Changed — Existing SSHFP records where the fingerprint differs from the scanned key. These are highlighted in red with a man-in-the-middle warning. You must explicitly confirm the key change is intentional before the change can be selected for application
• Remove Orphaned — SSHFP records for hostnames that no longer have A/AAAA records in the zone
• Unchanged — Existing SSHFP records that match the current host keys
• Unreachable — Hosts that did not respond on port 22

Using the Scanners

1. Open a zone and tap the scanner button (shield icon on macOS, or via the ⋯ menu on iOS)
2. Select "Scan TLSA Records" or "Scan SSHFP Records"
3. Wait for the scan to complete — progress is shown for each host
4. Review the results. Use the checkboxes to select or deselect individual changes
5. Tap Apply to push the selected changes to your DNS server

Note: Wildcard records (*.example.com) are skipped during scanning. If both A and AAAA records exist for the same hostname, the host is scanned only once.

Enable DNS Verification (All Hosts)

Create a global SSH config snippet that enables SSHFP lookups for every host you connect to. On macOS, drop-in config files go in /etc/ssh/ssh_config.d/:

# /etc/ssh/ssh_config.d/10-dns-verify.conf
# Enable DNSSEC-based SSHFP host key verification
Host *
    VerifyHostKeyDNS yes

With this setting, OpenSSH will look up SSHFP records for every host you connect to. If a matching DNSSEC-validated record is found, the host key is accepted automatically. If no SSHFP record exists or DNSSEC validation fails, SSH falls back to normal known_hosts behaviour — so this is safe to enable globally.

Skip known_hosts for Your Domains

For domains you control and have fully deployed SSHFP records on, you can go a step further and disable known_hosts entirely. This means DNSSEC becomes the sole source of trust for host key verification — there is no stale known_hosts entry to conflict when you rotate keys or rebuild a server:

# /etc/ssh/ssh_config.d/90-owned-domains.conf
# Domains with SSHFP records: trust DNS, skip known_hosts
Host *.example.com *.example.org
    VerifyHostKeyDNS yes
    StrictHostKeyChecking yes
    UserKnownHostsFile /dev/null
    GlobalKnownHostsFile /dev/null

Replace the host patterns with your own domains. You can list multiple patterns separated by spaces.

• VerifyHostKeyDNS yes — Look up SSHFP records in DNS and verify via DNSSEC
• StrictHostKeyChecking yes — Reject the connection if the host key does not match (no interactive prompt)
• UserKnownHostsFile /dev/null — Do not read or write the per-user known_hosts file
• GlobalKnownHostsFile /dev/null — Do not read the system-wide known_hosts file

Important: Only use this configuration for domains where every SSH host has SSHFP records published in a DNSSEC-signed zone. If SSHFP records are missing or the zone is not signed, connections to those hosts will be rejected.

Prerequisites

• Your zone must be DNSSEC-signed — SSHFP records without DNSSEC offer no security benefit, and OpenSSH will only trust DNSSEC-validated responses
• Your local DNS resolver must support DNSSEC validation (e.g., Unbound, systemd-resolved with DNSSEC=yes, or a validating forwarder like Cloudflare 1.1.1.1 or Google 8.8.8.8)
• SSHFP records must be published for all key types offered by the server — use the SSHFP Scanner in DnsEditor to generate them automatically
• macOS users: You must install OpenSSH from Homebrew (see the known issue below)

macOS Known Issue

The version of OpenSSH bundled with macOS does not perform DNSSEC validation, even when your DNS resolver supports it. When VerifyHostKeyDNS is set to yes, Apple's SSH will find SSHFP records in DNS but treat them as unverified — it will prompt you to confirm the fingerprint manually rather than accepting it automatically. This defeats the purpose of SSHFP.

The workaround is to install OpenSSH via Homebrew, which builds against a DNS library that performs proper DNSSEC validation:

brew install openssh

After installation, Homebrew's ssh is placed in /opt/homebrew/bin/ssh (Apple Silicon) or /usr/local/bin/ssh (Intel). Make sure this path appears before /usr/bin in your $PATH, or invoke it explicitly:

# Verify you're using Homebrew's version
which ssh        # should show /opt/homebrew/bin/ssh
ssh -V            # should show a newer version than Apple's

Homebrew's OpenSSH uses its own config file at /opt/homebrew/etc/ssh/ssh_config and does not read the system drop-in directory by default. To pick up the config files described above, add an Include directive at the top of Homebrew's config:

# /opt/homebrew/etc/ssh/ssh_config — add this line at the top
Include /etc/ssh/ssh_config.d/*.conf

How to tell: Run ssh -v server.example.com and look at the fingerprint line. Apple's SSH will say "found 6 insecure fingerprints in DNS" and reject the connection. Homebrew's SSH will say "found 6 secure fingerprints in DNS" and connect successfully.

Verifying It Works

Connect with verbose output to confirm SSHFP verification:

ssh -v server.example.com 2>&1 | grep -i dns

A working setup (Homebrew's OpenSSH) will show:

debug1: found 6 secure fingerprints in DNS
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2
debug1: matching host key fingerprint found in DNS

A broken setup (Apple's built-in SSH) will show insecure instead of secure and fail with "Host key verification failed":

debug1: found 6 insecure fingerprints in DNS
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 1
debug1: verify_host_key_dns: matched SSHFP type 4 fptype 2
debug1: matching host key fingerprint found in DNS
No ED25519 host key is known for server.example.com and you have requested strict checking.
Host key verification failed.

If you see "No matching host key found in DNS", check that the SSHFP records are published and your resolver validates DNSSEC.

Internationalized Domain Names (IDN)

DnsEditor fully supports Internationalized Domain Names with automatic Punycode encoding and decoding:

• Unicode display — Punycode domains like "xn--hsteng-bya.no" are displayed as "høsteng.no" throughout the interface
• Automatic encoding — Enter domain names in your native language; DnsEditor automatically encodes them to Punycode for DNS operations
• Copy Punycode — The record editor shows the encoded DNS name for easy copy/paste into configuration files like named.conf
• Proper sorting — Zones and records are sorted by their Unicode names, not their Punycode representation
• Unicode search — Search works with both Unicode characters and Punycode strings

Example: Add a zone "høsteng.no" or "xn--hsteng-bya.no" — both will display as "høsteng.no" and work identically. When editing records, the Punycode version is shown below the input field for reference.

General

Records Not Loading

• Ensure the zone name is correct and exists on the provider
• Try refreshing the zone using the reload button in the toolbar
• Check for network connectivity issues
• Verify your credentials have not expired or been revoked

Cloudflare

Authentication Failed

• Verify your API token is correct and has not expired
• Ensure the token has Zone → DNS → Edit permissions
• Check that the token's zone resources include the zones you want to manage
• If using a restricted token, ensure it covers all required zones

Cloudflare Update Errors

• Cloudflare does not allow CNAME records at the zone apex unless "CNAME Flattening" is enabled
• Proxied records (orange cloud) may have restrictions on TTL values
• Some record types (e.g., SOA, NS at apex) are managed by Cloudflare and cannot be modified via the API

AWS Route 53

Access Denied

• Verify your Access Key ID and Secret Access Key are correct
• Ensure the IAM user/role has the required Route 53 permissions (route53:ListHostedZones, route53:ListResourceRecordSets, route53:ChangeResourceRecordSets)
• Check the AWS region setting matches your account configuration
• If using temporary credentials (STS), ensure they have not expired

Route 53 Update Errors

• Route 53 requires record changes to be submitted as change batches — DnsEditor handles this automatically, but conflicts can occur if the zone was modified externally between loading and saving
• Alias records are specific to Route 53 and may not appear as expected when viewed as standard DNS records
• NS and SOA records at the zone apex cannot be deleted
• If you get a "PriorRequestNotComplete" error, wait a moment and try again — Route 53 processes changes sequentially

Google Cloud DNS

Permission Denied

• Verify the Project ID matches the project containing your DNS zones
• Ensure the service account JSON key is complete and valid (it should start with {"type": "service_account")
• Check that the service account has the DNS Administrator role or equivalent custom permissions
• The Cloud DNS API must be enabled in your Google Cloud project

Google Cloud DNS Update Errors

• Google Cloud DNS uses a Changes API that requires specifying both the old and new record values — if the zone was modified externally, reload the zone before making changes
• Record sets with the same name and type are grouped — adding a duplicate may result in an error
• SOA and NS records at the zone apex are managed by Google and have restrictions on modification

RFC2136 (BIND9)

Connection Failed

• Verify the DNS server address and port (default: 53) are correct
• Check that the DNS port is accessible from your network (not blocked by a firewall)
• Ensure your TSIG key name and secret match the server's named.conf configuration exactly
• Confirm the TSIG algorithm matches (HMAC-SHA256 is recommended)

Zone Not Loading

• DnsEditor loads zones via AXFR (zone transfer). If a zone appears in the list but fails to load its records, check that allow-transfer in named.conf includes your TSIG key:

  zone "example.com" {
      type master;
      allow-transfer { key "keyname"; };
      allow-update { key "keyname"; };
  };

• Without the TSIG key in allow-transfer, BIND9 will silently refuse the zone transfer and DnsEditor will show an empty or failed zone
• If you have secondary nameservers, list both the TSIG key and the secondary IPs in allow-transfer

Update Refused

• Verify your TSIG key has update permissions for the zone
• Check the BIND9 allow-update directive includes your TSIG key:

  zone "example.com" {
      type master;
      allow-update { key "keyname"; };
  };

• Some record types (SOA, DNSSEC operational records) may be restricted by server policy
• If the server log shows "update denied", check the BIND9 logs for the specific reason: journalctl -u named

TSIG Key Issues

• The key must be in BIND format: key "keyname" { algorithm hmac-sha256; secret "base64..."; };
• Ensure there are no extra whitespace or line break issues when pasting the key
• After pasting, click "Parse Key" to validate — a green indicator confirms the key was parsed successfully
• The key name in DnsEditor must match the key name configured on the server exactly (case-sensitive)