How to use a third-party secondary (e.g. Hetzner)

This walkthrough points a managed DNS provider's secondary service at your Everlock as the hidden primary. You keep editing the zone on Everlock; the provider's nameservers pull it over AXFR and answer the public. No second Everlock instance required.

Everlock is the primary: you edit records here, it authorises transfers and emits NOTIFY. It does not need to be in the public NS set.
The provider (Hetzner in this example) runs the secondary nameservers that the world actually queries.

If you'd rather run both ends yourself, see the home-primary + VPS-secondary guide. If you want a single public server with no secondary at all, the single-instance static guide is simpler.

Everlock authorises every transfer with TSIG, not by source IP, so the whole thing hinges on the TSIG key name and secret matching on both sides. That's the part that trips people up; the rest is mechanical.

What you need

A registered domain (example.com in this walkthrough).
Everlock reachable from the internet on TCP 53 (the provider connects in to AXFR). Outbound UDP 53 for NOTIFY. You do not need to publish Everlock as a nameserver.
A secondary-DNS provider that supports AXFR with TSIG. This guide uses Hetzner's secondary DNS; its nameservers are:

hostname IPv4 IPv6

ns1.first-ns.de 213.239.242.238 2a01:4f8:0:a101::a:1

robotns2.second-ns.de 213.133.100.103 2a01:4f8:0:1::5ddc:2

robotns3.second-ns.com 193.47.99.3 2001:67c:192c::add:a3

Confirm the exact names/IPs in your provider's console — they change over time and differ per provider.

hostname	IPv4	IPv6
`ns1.first-ns.de`	`213.239.242.238`	`2a01:4f8:0:a101::a:1`
`robotns2.second-ns.de`	`213.133.100.103`	`2a01:4f8:0:1::5ddc:2`
`robotns3.second-ns.com`	`193.47.99.3`	`2001:67c:192c::add:a3`

1. Open the port

Everlock only needs to answer AXFR (inbound TCP 53 from the provider) and send NOTIFY (outbound UDP, no inbound rule):

sudo ufw allow 53/tcp

Plus the same in any cloud firewall. Binding port 53 needs root or the capability:

sudo setcap CAP_NET_BIND_SERVICE=+eip ./everlock

You don't need inbound UDP 53 unless Everlock is also answering public queries directly — in a pure hidden-primary setup it isn't.

2. Agree on a TSIG key

The provider and Everlock must share one HMAC-SHA256 key — same name, same secret on both sides. Either generate it on Everlock:

ssh -p 2222 admin@<your-server>
/dns peer keygen

…and paste it into the provider's TSIG configuration, or create the key in the provider's console and copy its name + secret onto Everlock.

The name matters as much as the secret: Everlock matches an incoming transfer to a peer by the TSIG key name on the wire. Whatever name the provider uses for the key is the name you must give the peer in step 4. (Some providers auto-name it, e.g. example.com.<your-ip> — your server log will show the exact string a rejected transfer presented.)

3. Create the zone and point its NS at the provider

On Everlock, create the zone (primary is the default) and grant yourself access:

/users grant admin ssh/dns/* owner
/dns zones create example.com

Now replace the auto-generated self-referential nameservers with the provider's nameservers. Adding explicit apex NS records overrides Everlock's derived ns1/ns2.example.com:

/dns records create example.com name=@ type=NS value=ns1.first-ns.de
/dns records create example.com name=@ type=NS value=robotns2.second-ns.de
/dns records create example.com name=@ type=NS value=robotns3.second-ns.com

This is required: every secondary provider validates that its own nameservers appear in the zone's NS set, and the registry won't accept the delegation otherwise (see troubleshooting). Everlock's SOA MNAME stays ns1.example.com — that's the hidden primary, which is fine (RFC 2182); it doesn't need to be a published NS.

Add your real records as usual:

/dns records create example.com name=@ type=A value=203.0.113.10 ttl=300
/dns records create example.com name=www type=CNAME value=example.com ttl=300

4. Add the provider as a peer

The provider answers from several nameserver IPs under one key. Give them all to a single peer, comma-separated, so each receives the NOTIFY. name= must equal the TSIG key name from step 2; secret= must be the matching secret:

/dns peer create example.com name=<tsig-key-name> \
    address=213.239.242.238,213.133.100.103,193.47.99.3 \
    secret=<base64-secret>

Verify:

/dns peer list example.com

  name              algorithm    notify addresses
  <tsig-key-name>   hmac-sha256  213.239.242.238, 213.133.100.103, 193.47.99.3

/dns peer create already fires the first NOTIFY to all three. Managing peers requires the owner role on the zone (granted by /dns zones create).

5. Configure the secondary zone at the provider

In the provider's console, add example.com as a secondary zone:

Primary nameserver IP: your Everlock's public IP.
TSIG key: the same name + secret + hmac-sha256 you used in step 4.

Save. The provider's servers will connect in and AXFR the zone.

6. Trigger and verify the transfer

/dns peer create already poked the provider, but you can force a fresh transfer any time by making a content change — the SOA serial only advances on a real change, so a bare /dns reload won't NOTIFY:

/dns records create example.com name=_t type=TXT value=ping ttl=60
/dns records delete example.com _t TXT

Watch the Everlock log:

IXFR answered with full transfer: zone=example.com, peer=<key>, records=N
NOTIFY sent (zone=example.com, peer=<key>, serial=…)

Then confirm every provider nameserver agrees — DENIC and other registries reject a delegation if the listed servers disagree:

dig @213.239.242.238 example.com SOA +short   # ns1
dig @213.133.100.103 example.com SOA +short   # robotns2
dig @193.47.99.3     example.com SOA +short    # robotns3
dig @213.239.242.238 example.com NS  +short    # → the three provider names

All three SOAs must show the same serial.

7. Delegate at the registrar

At the registrar for example.com, set the domain's nameservers to the provider's three names (ns1.first-ns.de, robotns2.second-ns.de, robotns3.second-ns.com). For .de, DENIC runs a predelegation check that queries those servers and only activates the delegation once they all answer authoritatively and consistently.

Verify the public path once propagated:

dig +trace example.com NS

From here on, every record change on Everlock NOTIFYs all of the provider's servers at once, and they re-transfer the full zone within seconds.

Troubleshooting

`AXFR rejected: no peer named "X" on zone "example.com"`

The TSIG key name on the wire (X in the log) doesn't match any peer's name. Set the peer's name= to exactly that string (or rename the key in the provider's console to match). Name and secret must be identical on both sides.

The provider transfers, but its console says "not set up correctly"

Almost always the zone's NS set doesn't list the provider's nameservers. Check /dns records list example.com — the apex NS records must be the provider's names (step 3), not ns1.example.com.

Registry rejects the delegation: "Inconsistent set of NS RRs"

The provider's servers disagree because some are still serving an old copy. This happens if only one was NOTIFIED and the others hadn't re-polled. Make sure all the provider's IPs are on the peer (address=a,b,c), re-run /dns peer set to re-NOTIFY them, and confirm all return the same serial (step 6) before resubmitting.

Registry warns: "Retry value out of range"

Registries bound the SOA retry relative to refresh. DENIC's window for refresh=3600 is effectively [900..1200]; Everlock ships retry=1000, inside it. If you see this against a stale server, it's serving an old SOA — get it to re-transfer (above) and the warning clears.

A provider server stays on an old serial

Only the servers on the peer's address list get NOTIFY; any not listed wait for their refresh timer. Add every provider IP to the peer. If one still lags after a NOTIFY, use the provider console's "retransfer" action or check your Everlock log for AXFR/IXFR attempts from that IP.