Import and synchronize forwarder zones with local overrides and promotion

CHANGELOG.md

@@ -8,6 +8,66 @@ Create a passphrase-sealed application backup before upgrading and keep
 mixed-version cluster windows short. Cross-version restore and downgrade
 compatibility are not yet a published contract.
 
+## [1.3.2]
+
+Sable 1.3.2 lets you migrate Technitium forwarder zones with their local overrides,
+keep them synchronized while you test, and move write ownership to Sable when
+you are ready. It also improves zone-file imports and search controls throughout
+the console.
+
+### Migrate forwarder zones without rebuilding overrides
+
+- **Zones → Import… → From catalog** now recognizes supported Technitium
+  forwarder zones and preserves their forwarding rules and local records,
+  instead of rejecting them for an unsupported record type or missing apex NS.
+- Choose **Secondary** to create a read-only **Secondary Forwarder** that keeps
+  receiving source changes. Choose **Primary** to create an independent,
+  editable **Forwarder** after confirming that source writes are paused.
+  Importing does not subscribe Sable to the source catalog's membership.
+- Matching local answers take precedence before forwarding, including TXT and
+  MX as well as A, AAAA, and CNAME. Queries without a matching local answer
+  continue through the forwarding rules. Independent Forwarders allow adding
+  ordinary records alongside FWD records in the console.
+- Supported transfers preserve UDP, TCP, TLS, and QUIC forwarding, priorities,
+  and consistent DNSSEC validation settings. Technitium's `this-server` rule
+  uses Sable's default resolver: configured upstreams in forward mode, or
+  iterative resolution in recursive mode.
+
+### Keep source changes in sync, then take ownership
+
+- Secondary Forwarders refresh by full AXFR on their SOA schedule, authorized
+  NOTIFY, or **Resync**. Updates include changed forwarding rules and added or
+  deleted overrides. Failed or invalid refreshes retain the last valid snapshot
+  until SOA expiry; expired zones return SERVFAIL until synchronization recovers.
+- **Actions → Convert to independent Forwarder** makes Sable the writable
+  owner without deleting and recreating the zone. Pause source edits and
+  automatic writers, review the snapshot, and use **Synchronize, then convert**
+  to capture the final source changes.
+- Conversion retains records, forwarding and validation settings, permissions,
+  and history, advances the SOA serial, and stops source synchronization.
+  A failed final transfer or stale review leaves the Secondary Forwarder
+  unchanged. **Use the stored snapshot** explicitly skips the final transfer
+  and may retain stale or expired data.
+
+Sable catalog-managed members cannot use this conversion; stage independent
+imports for migration. Source-wide resolver and proxy settings are not copied.
+Unsupported forwarding options are reported per zone without creating that
+zone. The separate zone-file importer does not support Technitium's full textual
+FWD syntax. See the [migration guide](docs/guides/technitium-migration.md#forwarder-members)
+for supported settings and the cutover procedure.
+
+### Easier imports and consistent search
+
+- A single **Import…** menu offers **From file or text** and **From catalog**.
+  Zone-file dialogs support drag-and-drop uploads, a selected-file summary,
+  and a separate text editor with **Paste from clipboard**. New-zone imports
+  detect the zone name from the file when possible.
+- Fix zone-file imports whose apex SOA owner is written as the full zone name
+  without a trailing dot, while preserving other relative names.
+- Keep catalog import controls positioned correctly as the dialog opens.
+- Standardize search fields across the console, with consistent search icons
+  and clear buttons for quickly resetting a query or filter.
+
 ## [1.3.1]
 
 - Stack OpenID Connect and passkey sign-in buttons together, with a single

docs/guides/forwarding.md

@@ -41,6 +41,12 @@ forwarders = ["10.2.0.53:53"]
 
 Alternatively create a [Forwarder zone](../reference/zones/forwarder.md) and manage its [FWD records](../reference/records/fwd.md) through Zones. Lower numeric priorities are tried first. Do not create conflicting routing objects unless you have a reason and have verified the resulting query path.
 
+## Keep local overrides
+
+Forwarder zones can contain ordinary local records alongside FWD rules. Matching local answers take precedence, including TXT and MX as well as addresses and CNAMEs; other queries use forwarding. A local TXT answer does not prevent an A query for the same name from using the upstream.
+
+When migrating from Technitium, a [Secondary Forwarder](../reference/zones/forwarder.md#secondary-forwarder-synchronization) keeps those overrides and forwarding rules current by AXFR. Promote it with **Convert to independent Forwarder** when Sable should own edits. The resulting Forwarder keeps the same override and fallback behavior.
+
 ## Encrypt an upstream connection
 
 Forwarder endpoints accept `udp://`, `tcp://`, `tls://`, and `quic://`. TLS and QUIC default to port 853; UDP and TCP default to port 53. Upstream forwarding currently does not accept a `doh://` endpoint. This differs from the built-in DNS client's ability to issue DoH queries.

docs/guides/import-export.md

@@ -4,7 +4,7 @@ Use zone files to move DNS data between systems. Use an application backup to pr
 
 ## Before you begin
 
-Export the destination zone or take a [backup](../backup.md) before replacing live data. Work on a Primary zone and on the writable node of a cluster. Secondary, Alias, and catalog-managed records belong to another source; do not import over them.
+Export the destination zone or take a [backup](../backup.md) before replacing live data. Work on a Primary zone and on the writable node of a cluster. Secondary, Secondary Forwarder, Alias, and catalog-managed records belong to another source; do not import over them.
 
 ## Import a standard zone file
 
@@ -30,6 +30,16 @@ Fully qualified target names end in a dot. Inspect imported relative names caref
 
 Sable validates the complete candidate before activation. An invalid SOA, out-of-zone owner, malformed record, or conflicting CNAME prevents a safe import. Correct the source file instead of bypassing validation.
 
+## Import from a catalog
+
+The catalog importer discovers member zones and imports selected members independently. Choose Primary or Secondary for authoritative zones. Members with an apex forwarder and no apex NS records retain their forwarding behavior, local records, and supported routing settings. Primary mode creates an independent, editable Forwarder. Secondary mode creates a read-only Secondary Forwarder that keeps its source servers and TSIG authentication, refreshes by AXFR on its SOA schedule or authorized NOTIFY, and stops answering when its source expires. Failed or invalid refreshes retain the last valid snapshot until expiry.
+
+To finish a migration, use **Convert to independent Forwarder** on an independently configured Secondary Forwarder. Pause source edits and choose a final synchronization (the default), or explicitly use the stored snapshot. Conversion preserves forwarding and DNSSEC validation settings, advances the SOA serial, stops source synchronization, and enables record editing. Sable catalog-managed members cannot use this action, and there is no general catalog-detachment action. Stage independent imports for this workflow. See [Forwarder conversion](../reference/zones/forwarder.md#convert-to-an-independent-forwarder) for the full cutover procedure.
+
+Technitium forwarder transfers support UDP, TCP, TLS, and QUIC, including priority and consistent DNSSEC validation settings. `this-server` uses Sable's default resolver path: configured upstreams in forward mode, or iterative resolution in recursive mode. Matching local records take precedence; other queries follow the forwarding rule. The source server's global resolver and proxy configuration is not transferred.
+
+Unsupported transports, explicit proxies, pinned-host address syntax, and mixed per-record DNSSEC validation settings produce an error without creating the affected zone. Review each result and test both local overrides and forwarded answers before moving clients.
+
 ## Export for review or migration
 
 Use the zone export action and keep the original file until the migration is verified. Compare critical records at the receiving server, not just the file size. Sable-specific ANAME and FWD behavior may not have an equivalent in another server's zone-file importer; migrate those deliberately.

docs/guides/technitium-migration.md

@@ -9,7 +9,7 @@ Build Sable alongside your current DNS service, move one test zone, and verify i
 | Export a zone file and import it | A few zones and a planned change freeze | Sable after the final import |
 | Retrieve AXFR into a file, then import | Standard authoritative zones with transfer access | Sable after the final snapshot |
 | Run Sable as a Secondary first | Testing with current data while Technitium remains live | Technitium until conversion to Primary |
-| [Import from Catalog](#3d-import-catalog-members-in-bulk) | Discover and import many authoritative zones together | Technitium for Secondary imports; Sable for Primary imports |
+| [Import from Catalog](#3d-import-catalog-members-in-bulk) | Discover and import authoritative and forwarder zones together | Technitium for Secondary imports; Sable for Primary imports |
 
 A **Secondary zone** follows another DNS server through AXFR/IXFR. A **Sable cluster replica** follows a Sable primary's application state. Technitium cannot enroll as a Sable cluster member. You can migrate into either a standalone Sable server or the writable primary of a Sable cluster.
 
@@ -21,8 +21,8 @@ Technitium uses a special `cluster-catalog.<cluster-domain>` to distribute membe
 
 For a replacement Sable deployment:
 
-- Use **Zones → Import from Catalog** to discover authoritative member zones and import them as independent Secondaries or Primaries. Alternatively, export zones or create Secondaries individually. Source-side catalog membership does not make that Sable zone catalog-managed.
-- Recreate Forwarder and Stub zones with their intended upstreams and behavior.
+- Use **Zones → Import from Catalog** to discover member zones and import them independently. Authoritative zones become Secondaries or Primaries; forwarder zones become Secondary Forwarders or editable Forwarders. Alternatively, export zones or create Secondaries individually. Source-side catalog membership does not make that Sable zone catalog-managed.
+- Review imported forwarding rules and local overrides against the source. Recreate unsupported forwarding configurations and Stub zones separately.
 - Review imported SOA/NS records and their address dependencies before retiring the old cluster.
 - Inspect the cluster-domain zone for service names you still need. Preserve those deliberately; do not copy its cluster authentication records as Sable cluster configuration.
 - Check signing status per zone. Catalog membership alone does not mean a zone is signed. Any signed zone you retain needs the DNSSEC review below, including whether a parent DS or private trust anchor exists.
@@ -41,7 +41,8 @@ List each forward and reverse zone, its type, serial, signing status, update wri
 | --- | --- |
 | Primary authoritative records | Import a complete zone file or transfer a snapshot |
 | Secondary zone | Recreate it against the original authoritative primary if that ownership is staying elsewhere |
-| Conditional forwarding or Stub zone | Recreate the [Forwarder](../reference/zones/forwarder.md) or [Stub](../reference/zones/stub.md), including upstreams and validation policy |
+| Conditional forwarding | Import supported members through the catalog wizard, or create a [Forwarder](../reference/zones/forwarder.md) manually; verify local overrides, upstreams, and validation policy |
+| Stub zone | Recreate the [Stub](../reference/zones/stub.md) against its intended source |
 | Cluster catalog | Use it to identify member zones; normally omit the catalog from the Sable deployment |
 | Cluster-domain zone | Review useful names, SOA/NS dependencies, and signing separately from Technitium's node-authentication records |
 | APP records and DNS apps | Replace the behavior explicitly; Sable's text importer skips Technitium APP records and reports their names |
@@ -160,11 +161,26 @@ per zone and do not undo successful imports.
 
 Signed zones can be staged as Secondaries but are blocked from Primary import
 until a DNSSEC transition has been completed.
-Recreate Forwarder settings separately. Review and convert eligible zones
+Review and convert eligible zones
 individually after pausing source writes, then verify answers and cluster replicas
 before changing clients or retiring the old servers. Bulk conversion is not yet
 part of this workflow.
 
+### Forwarder members
+
+A transferred member with an apex FWD record and no apex NS records is imported as a forwarder zone:
+
+| Import mode | Result | Subsequent edits |
+| --- | --- | --- |
+| **Secondary** (default) | **Secondary Forwarder** | Edit Technitium; Sable synchronizes forwarding rules and overrides by AXFR |
+| **Primary** | Independent **Forwarder** | Edit Sable after confirming source writes are paused |
+
+Supported Technitium transfers preserve UDP, TCP, TLS, and QUIC forwarding, priorities, and consistent per-record DNSSEC validation settings. `this-server` uses Sable's configured default upstreams in forward mode or iterative resolution in recursive mode. Technitium's global resolver and proxy settings are not transferred. Unsupported transports, explicit proxies, pinned-host address syntax, mixed validation settings, or malformed records fail the affected import without creating a zone.
+
+Local answers take precedence for all supported record types, including TXT and MX as well as A, AAAA, and CNAME. Queries without a matching local answer follow the forwarding rule. Verify both paths. This transfer support does not make Technitium's full textual FWD export syntax compatible with the separate zone-file importer.
+
+Secondary Forwarders retain source transfer settings and refresh through full AXFR on the SOA schedule, authorized NOTIFY, or **Resync**, carrying additions, changes, and deletions. Failed refreshes retain the last valid snapshot until SOA expiry, after which local and forwarded queries return SERVFAIL. See [Secondary Forwarder synchronization](../reference/zones/forwarder.md#secondary-forwarder-synchronization).
+
 If a selected zone already exists in Sable, import will not replace it, change its type, or detach it from a Sable catalog. Zone lists and detail pages identify the managing catalog; the detail page links to it. Plan ownership changes separately for subscribed members. A source-side Technitium catalog does not impose this restriction on independently imported zones.
 
 The wizard allows up to two minutes for an import, with a 30-second timeout per transfer. Review every result before retrying; successfully imported zones remain and are skipped on a later attempt. A warning after a signed Secondary import means it was synchronized successfully but cannot yet become Primary. A failed signed Primary import creates no zone.
@@ -189,6 +205,14 @@ Conversion preserves zone identity, permissions, records, and revision history w
 
 Signed zones and Sable catalog members are rejected with an explanation. Transferred signatures do not supply private signing keys. A Technitium catalog membership alone does not block an individually configured Sable Secondary; leave that source catalog behind as described above. Catalog detachment and seamless key migration are separate work.
 
+### Promote staged forwarder zones
+
+For an independent **Secondary Forwarder**, pause source edits and automatic writers, then choose **Actions → Convert to independent Forwarder**. Review the snapshot and use **Synchronize, then convert** for a final AXFR. The resulting type is **Forwarder**: Sable becomes the writable owner of the forwarding rules and local overrides, while unanswered queries continue to use those forwarding rules.
+
+Conversion preserves forwarding and DNSSEC validation settings, records and metadata, permissions, and history; it advances the SOA serial and removes source server/transport settings. Source refresh, NOTIFY-driven synchronization, and secondary expiry tracking stop. The shared TSIG key and outgoing transfer/NOTIFY settings remain. A failed final synchronization or stale review leaves the zone unchanged. **Use the stored snapshot** is an explicit alternative that may retain stale or expired data.
+
+Sable catalog-managed members cannot be promoted through this action, and there is no general catalog-detachment action. Stage independent members through **Import from Catalog** for this workflow. Verify local TXT/MX and address overrides, CNAME behavior, and a forwarded answer on every serving node before retiring Technitium. See [the Forwarder conversion reference](../reference/zones/forwarder.md#convert-to-an-independent-forwarder).
+
 ### Sable 1.1.0 and earlier: export, remove, and import
 
 Sable 1.1.0 does not provide in-place Secondary-to-Primary conversion. For that version, use the following maintenance procedure.

docs/guides/zone-transfers.md

@@ -30,6 +30,12 @@ Query the SOA on both nodes. Change a harmless test record on the primary and co
 
 An empty new Secondary is not ready to serve the intended records until its first transfer completes. If the primary remains unavailable beyond the SOA expiry interval, the Secondary cannot continue treating its copy as current indefinitely.
 
+## Synchronize forwarding rules and overrides
+
+A [Secondary Forwarder](../reference/zones/forwarder.md#secondary-forwarder-synchronization) uses full AXFR to copy forwarding rules and local records from its source. Import a supported forwarder member through **Import from Catalog → Secondary** to stage it this way. The transfer protocol and TSIG settings authenticate synchronization separately from the protocols used by FWD records to resolve queries.
+
+SOA timers, authorized NOTIFY, and **Resync** drive refreshes. Test both an added and a deleted override to confirm complete snapshots arrive. Records remain read-only until **Convert to independent Forwarder** ends source synchronization and makes Sable writable. An ordinary independent Forwarder does not poll another server just because it has forwarding rules.
+
 ## Troubleshoot refusals
 
 Check the exact key name, algorithm, secret, time synchronization, transfer ACL, source address after NAT, protocol, and primary reachability. For TLS, check certificate names and trust. Never solve an authentication failure by making the whole zone publicly transferable.

docs/reference/records/fwd.md

@@ -15,6 +15,10 @@ quic 20 dns.example.net:853
 
 Priority is an unsigned 16-bit number; lower values are preferred. The address is a host or IP with an optional port. UDP/TCP default to 53, TLS/QUIC to 853. Explicit IPv6 ports use bracketed address syntax.
 
+The special value `udp 0 this-server` selects Sable's default resolver path: configured upstreams in forward mode, or iterative resolution in recursive mode. It is not a network hostname. Only UDP syntax is supported for this marker; the actual default upstream configuration controls forwarding transport.
+
+Technitium catalog transfers decode its private FWD wire records into Sable's format. This is separate from parsing Technitium's textual zone exports. See [forwarder migration](../../guides/technitium-migration.md#forwarder-members) for supported settings and limitations.
+
 ## Console and parser support
 
 The console offers UDP, TCP, and TLS in its FWD picker. The underlying parser also accepts `quic`. Do not interpret parser support as a visible console option. `doh` is not accepted as a forwarding protocol.