Move from Technitium to kudurru

Inventory Technitium dependencies, migrate primary zones through BIND export/import, recreate forwarders and blocking, and validate before a DNS cutover.

Technitium combines authoritative DNS, recursive resolution, blocking, DHCP, clustering and DNS Apps. kudurru v0.1.0 covers primary zones, forwarding, filtering and a dashboard, with native Kubernetes objects. Start by deciding which Technitium responsibilities can move and which need to stay elsewhere.

Before you start: complete preparation and CLI setup. Keep Technitium serving the network. Its server backups, cluster state and DNS Apps are not importable. Standard primary-zone files are the supported interchange format.

Compare the features you use

Technitium already offers clustering, OIDC and advanced authoritative DNS. Moving to kudurru trades some of that breadth for its object model, Kubernetes integration and operating workflow. Compare against your actual dependencies; the presence of a field in a CRD does not make a deferred feature operational. See the full comparison and Technitium's feature list.

1. Back up and classify the workload

1. Use Technitium's backup function to save the server configuration, zones, allowed/blocked data, app settings and any DHCP data you need. Retain certificates and TSIG material securely for recovery.
2. List every zone with its type, records, query/transfer/update ACLs, NOTIFY destinations, DNSSEC state and dependent clients or secondaries.
3. Export each primary zone in standard zone-file format from the web console. Keep the original exports unchanged and work on copies.
4. List DNS Apps and records that invoke them. Record the behavior each app provides, including blocking, split-horizon answers, aliases or DNS64.
5. Record forwarders, recursive settings, blocked-list URLs, allowed/blocked zones, client subnets, encrypted endpoints, users and cluster membership.

Classify each item as move now, retain as a separate service or defer the migration. Do not change a public delegation or a signed zone until you have a plan for DNSSEC and all authoritative dependencies.

2. Import an unsigned primary zone

Start with a private, unsigned primary zone such as home.arpa.. An export must be a standard zone file, not Technitium's binary backup or internal zone files. If your installed version cannot export the required zone in that format, recreate its records through the dashboard or API instead.

Inspect a working copy of the export. Standard records such as A, AAAA, CNAME, MX, TXT, SRV and PTR are portable. APP, FWD, ANAME and other Technitium-specific records need explicit replacements; they do not become working app behavior when placed in a zone file. Preserve unsupported data in your source backup and resolve the dependency before omitting it.

A minimal test file, home.arpa.zone, looks like this. Substitute your real records and addresses; the server address is a documentation placeholder.

$ORIGIN home.arpa.
$TTL 300
@ IN SOA ns.home.arpa. hostmaster.home.arpa. (
  2026101501 3600 600 86400 300
)
@     IN NS    ns.home.arpa.
ns    IN A     192.0.2.54
nas   IN A     192.168.1.10
files IN CNAME nas.home.arpa.

Import into a new object name, allowing the CLI to create the primary zone with --origin:

kudurru import bind home-arpa -f home.arpa.zone --origin home.arpa.
kudurru zones get home-arpa
kudurru records list home-arpa
kudurru zones export home-arpa --out home.arpa.kudurru.zone
kudurru query nas.home.arpa A
kudurru query files.home.arpa A

Read the import summary and every warning. The Technitium export API documents the standard zone-file export format. Compare the exported result against your source by owner name, type, targets, TTL, apex SOA and NS; text order and serial formatting may differ. A re-import replaces that import's record-set chunks, but leaves records owned by other record sets in place and does not update an existing zone's SOA/NS configuration. Review existing records before importing again. There must be only one active zone object for each apex.

Set the zone's query/transfer/NOTIFY policy separately in the dashboard or manifest. An imported zone file does not carry Technitium ACLs, permissions, TSIG secrets, app settings or DNSSEC key state. Configure a valid NS address and serial/NOTIFY behavior before using kudurru as a replacement primary for existing secondaries. Test transfers from those real secondary clients.

Reverse zones migrate as primary zones too: export the existing in-addr.arpa. or ip6.arpa. zone with its PTR records and import it using its real apex. A local A/AAAA record does not automatically create a PTR.

Signed and public zones

kudurru v0.1.0 cannot sign a zone or maintain a DNSSEC key lifecycle. Zone import skips DNSSEC records with warnings; it does not migrate signing state. Keep signed authority on a signer, or plan a separate DNSSEC transition that accounts for parent DS records and cached signatures before changing authority. A public move also requires reachable UDP/TCP port 53, correct NS/glue, delegation and tested transfers; a LAN DHCP change alone does not move a public authoritative zone.

3. Recreate conditional forwarding

Create the upstream group first. For file configuration, merge this into the installed kudurru.yaml before startup, retaining its other settings; or use DNS > Upstreams in the dashboard:

upstreams:
  groups:
    default:
      servers: ["9.9.9.9:53", "1.1.1.1:53"]
      strategy: parallel_best
    corp:
      servers: ["192.168.50.10:53", "192.168.50.11:53"]
      strategy: strict

Replace these with your approved resolvers. If you depended on Technitium for full recursion, point default at a resolver that still provides it. An upstream validator can enforce its own DNSSEC policy, but kudurru does not validate the returned chain itself.

Save this as technitium-forward.yaml for a private corporate suffix:

apiVersion: kudurru.io/v1alpha1
kind: DNSZone
metadata: {name: corp-example}
spec:
  zoneName: corp.example.
  type: forward
  forward:
    upstreamGroup: corp

kudurru apply -f technitium-forward.yaml
kudurru query host.corp.example A

Alternatively, use upstreams.conditional for suffix-to-group rules. Recreate reverse-DNS suffix routes as needed. A Technitium FWD record with special proxy, DNSSEC or app behavior needs separate evaluation; a forward zone only recreates the supported forwarding path. Avoid loops through the old server. See upstreams.

4. Move allowed and blocked names

Allowed/blocked zones are filtering rules, not authoritative DNS zone exports. Recreate them as list entries. The wildcard form below covers the apex and descendants; use type: exact for a single name.

Save as technitium-filtering.yaml and add your existing enabled list URLs as additional sources on migrated-blocked:

apiVersion: kudurru.io/v1alpha1
kind: BlockList
metadata: {name: migrated-blocked, namespace: default}
spec:
  mode: block
  sources:
    - name: blocked-zones
      entries:
        - {value: '*.tracker.example', type: wildcard, origin: migrated}
---
apiVersion: kudurru.io/v1alpha1
kind: BlockList
metadata: {name: migrated-allowed, namespace: default}
spec:
  mode: allow
  sources:
    - name: allowed-zones
      entries:
        - {value: '*.needed.tracker.example', type: wildcard, origin: migrated}
---
apiVersion: kudurru.io/v1alpha1
kind: Policy
metadata: {name: default, namespace: default}
spec:
  clientGroupRefs: [default]
  blockListRefs: [migrated-blocked]
  allowListRefs: [migrated-allowed]
  blockMode: zeroIP

kudurru apply -f technitium-filtering.yaml
kudurru get blocklists -o yaml
kudurru query tracker.example A --client 192.0.2.10
kudurru query needed.tracker.example A --client 192.0.2.10

The first query must block; the second must show an allow-list decision. Its upstream can still return NXDOMAIN because .example names have no public records. Check real allowed names too. Match Technitium's configured block response deliberately instead of assuming the default is identical.

These examples replace the seeded default policy's starter references. Use the actual namespace and ownership path for your installation. Authoritative answers from primary zones precede filtering; check any overlap between local authority and blocked names.

For Advanced Blocking app profiles, create an IP/CIDR ClientGroup and Policy for each supported profile, following the group example. Install a suitable key before adding policies. Include all baseline lists explicitly: custom policies do not inherit the default policy. Translate regular expressions to RE2 and inspect skipped rules. Rebuild service blocks and safe search with the policy catalog; do not copy DNS App configuration.

5. Rebuild operating dependencies

• DHCP: move service, active leases, reservations and dynamic local-name behavior using the DHCP handoff. Keep DNS running throughout the handoff.
• Access: create new users/tokens and least-privilege grants. Configure OIDC if needed; LDAP requires an external identity-provider bridge. Source credentials and grants do not migrate from the backup.
• Encrypted clients: configure listeners and certificates using encrypted transports, then test the actual client hostname, path, trust and protocol.
• Multiple servers: choose Helm for shared CRDs or Compose HA for file-managed independent nodes. Do not expect automatic synchronization between independent SQLite nodes.
• Automation: replace Technitium-specific API calls with the kudurru API/CLI. Retain existing services for deferred dynamic-update, app and secondary-zone responsibilities.

6. Validate and switch

Complete the validation checklist. In addition, compare SOA/NS, every record type in use, wildcard answers, negative answers, PTR zones, conditional forwarding and authorized/unauthorized query access. Test transfers and NOTIFY if secondaries depend on this primary. Confirm there is a working replacement for each DNS App and other retained service.

For LAN resolver clients, use the cutover procedure and keep Technitium and its backup available for rollback. Move public authority separately, using your delegation and DNSSEC plan. Retire Technitium only when its remaining authoritative, recursive, DHCP and app responsibilities have all been accounted for.