Documentation

Enough to get from nothing to three working nameservers. The full command reference and troubleshooting walk ship with the software and are in the panel.

Requirements

Primary	A DirectAdmin server running BIND, with root access. csf is detected and handled if present.
Sites	One or more Proxmox hosts, each with a static, routable public IP and spare capacity for a small Debian container.
Network	tcp/53 and udp/53 reachable in both directions. TCP is not optional — transfers and large responses need it.
Registrar	The ability to create glue records for your nameserver hostnames.
Not needed	A DirectAdmin licence on the secondaries. SSH access from the primary out to the sites.

One nameserver per site. The Proxmox host forwards its single public IP’s port 53 to one container. ns2 at one site, ns3 at another — two secondaries behind one IP buys you nothing.

1. Check compatibility, before buying anything

The Proxmox side is public and unauthenticated — the host it runs on holds no licence and has no way to present one. Its read-only check installs nothing and changes nothing, and it is the one that catches the most common failure: a firewall on the DirectAdmin server blocking port 53 from the site.

# on each Proxmox host
curl -fsSL https://daxfr.com/daxfr-site.sh | bash -s -- --check

Every check reports PASS / WARN / FAIL / SKIP. A non-zero exit means it is not safe to install. The installer calls the same functions, so check mode cannot drift from what actually happens.

The DirectAdmin side is licensed, so there is no public copy to run first. The installer covers it instead: it activates, then runs the full preflight, and stops there if anything fails — before it has changed a single file. Nothing is written until every check passes.

If it turns out not to suit your servers, the 30-day refund below needs no justification. That is deliberately the evaluation route: a read-only check you can run today, and your money back if the real thing disappoints.

2. Install on the DirectAdmin server

curl -fsSL https://daxfr.com/install.sh | bash -s -- init

To install and run the preflight without setting anything up yet, use bash -s -- preflight instead — it installs the CLI and runs the read-only checks, but does not touch named.conf.

You will be prompted for your licence key. It is prompted for rather than passed as an argument on purpose — a secret on a command line ends up in shell history and in ps output.

This backs up named.conf, adds three include lines, generates the catalog zone, installs the DirectAdmin hooks and a 5-minute reconciler, and opens port 53 in csf if csf is present. Every change to named.conf is validated with named-checkconf and rolled back automatically if it fails.

To see the exact changes first:

daxfr init --dry-run

That is not a narration — it copies named.conf into a sandbox, runs the real generation code against it, and validates the result. What you see is what would be installed.

3. Register each site

daxfr add-secondary --name ns2 --host 203.0.113.10 --ns-fqdn ns2.example.com

--host is the site’s public IP. This mints a TSIG key unique to that site, adds the A record to the parent zone, and prints an enrollment token.

If the DirectAdmin server is behind NAT

serverip= in directadmin.conf is then a private address the secondaries can never reach. preflight flags this and add-secondary refuses to issue a token pointing at it. Tell it the public address that forwards in:

daxfr set-primary-ip 203.0.113.9
daxfr token ns2          # reprint — earlier tokens carry the old address

4. Build each Proxmox site

curl -fsSL https://daxfr.com/daxfr-site.sh | bash -s

Paste the token for that site when prompted. The script creates a NAT bridge and an unprivileged Debian container, installs Knot from the upstream CZ.NIC repository, writes the catalog-consumer config, sets up the DNAT, and verifies the catalog actually arrived before it exits.

To reconfigure a site later, use --upgrade — it reads the container id, subnet, bridge, public IP and WAN interface back from /etc/default/daxfr-site, so there is nothing to retype.

5. Publish and delegate

daxfr add-ns-records

Then create the glue records at your registrar. Only once all three nameservers answer correctly, add them to your domains’ delegation.

6. Verify

From a machine outside both sites — a test from the Proxmox host itself can pass or fail for hairpin-NAT reasons that have nothing to do with real traffic:

dig +norec      @<site-public-ip> SOA yourdomain.com   # expect 'aa', serial == ns1
dig +norec +tcp @<site-public-ip> SOA yourdomain.com   # TCP matters

The real test is a round trip: create a throwaway domain in DirectAdmin and confirm it answers on the secondaries within about a minute — then delete it and confirm it disappears. The delete half is what proves the catalog design is working rather than merely the transfer.

Licensing

One licence per DirectAdmin primary. Secondaries are not licensed.

Activating

The installer activates the server for you and asks for the key as it runs. To activate a server later — after a rebuild, or when moving a licence — do it from the shell:

daxfr licence set        # prompts; never pass a key as an argument
daxfr licence status

The key is prompted for rather than accepted as an argument, so it does not end up in shell history or in ps output. Both commands need root: the licence file and the server identity are readable only by root.

The panel shows the licence — state, update window, and whether it was issued for that server — under Admin Level → Plugins → daxfr, in the Versions card. It has no key field on purpose: the CLI owns the licence, and a second thing talking to the licence server is how the two end up disagreeing about it.

What the licence gates

Updates, and nothing else. When your update window ends, daxfr keeps replicating your zones exactly as it did, indefinitely, on whatever version it has. It simply stops being offered newer ones.

If daxfr.com is unreachable

Nothing happens. Activation returns a signed licence file with a 30-day window, refreshed on a daily check-in with jitter. Your server trusts that file offline for the whole window, so an outage at our end — or an egress firewall at yours — never affects DNS and is never treated as a revocation.

If you filter outbound traffic, allow daxfr.com on tcp/443. That is the only host the software contacts.

Moving to another server

Release the old activation under Servers in your account, then activate the new one. If you forget, an activation that stops checking in goes dormant after 45 days and frees its seat by itself. During a migration a licence may briefly run one extra server for 14 days, so you do not have to tear the old one down first.

Updating

Press Update on the Versions card in the panel, or:

daxfr update

The download is checked against a SHA-256 published with the release, must parse and identify itself as this program, and must report the promised version before it is installed at all. The copy it replaces is kept until the new one has demonstrated it works, and goes back automatically if it has not.

Unattended updates are off unless you turn them on, will not cross a major version, and will not run while another job is going.

Uninstalling

# primary
daxfr uninstall

# each site
pct stop <CTID> && pct destroy <CTID>
systemctl disable --now daxfr-nat.timer daxfr-nat.service

NS records already published in your zones, and glue records at the registrar, are left alone by both. Remove those first and give them time to expire from caches before tearing down a nameserver that domains still delegate to.

The full command reference, the changelog and the troubleshooting walk ship with the software: daxfr --help, and the whole of the troubleshooting walk is a single search box in the DirectAdmin panel. Anything else, write to support@daxfr.com.