Should we close gaps in HickoryDNS for use as alternative to PowerDNS?

[brian-toresdahl-datum]

Summary

• Datum’s long-term direction seems to be Rust-native infrastructure for Authoritative DNS, and we already have HickoryDNS running in production for a subset of records. Today, Datum’s public authoritative DNS is rolling out on PowerDNS primarily because of (a) API-driven zone lifecycle and (b) an LMDB + Lightning Stream replication architecture for fast edge rollouts. This request proposes a concrete path to migrate authoritative DNS back to HickoryDNS by closing the remaining gaps and executing an incremental cutover.

Current state (as understood)

• HickoryDNS serves records for addresses provisioned to gateway resources. Deployment is managed under https://github.com/datum-cloud/infra/tree/main/apps/datum-auth-dns. 
• The reason for PowerDNS is not “defects in Hickory,” but feature gaps, especially the ability to add/remove arbitrary zones on the fly without manipulating a filesystem. 
• PowerDNS also enables an architecture using LMDB + PowerDNS/lightningstream for propagation from a primary (in GKE, operator-controlled) to edge secondaries.

Motivation

• Align Datum’s authoritative DNS with a Rust-native stack and reduce dependency on PowerDNS-specific operational patterns.
• Enable deeper integration with Datum control-plane patterns (operator, CRDs, datumctl) while preserving the rollout agility of today’s LMDB/Lightning Stream approach.
• Make space for upstream collaboration with HickoryDNS on features that enable large-scale authoritative deployments.

Goals / Success criteria

1. AXFR/TSIG interoperability is production-safe at Datum scale (no timeouts / signing failures on large zones).
2. A staged migration plan exists that keeps production stable and supports mixed deployments during cutover.