A Hidden Primary on a Changing IP Address

Run your primary nameserver at home or on a connection without a fixed IP address. We follow the new address from your signed NOTIFY, with no dynamic DNS service and no update script.

The problem

A secondary pulls your zone from a fixed address. On a home connection, the provider changes that address from time to time. Then the secondary asks an address that is no longer yours, the transfers fail, and after some days the zone expires on every public nameserver.

The usual workaround is a dynamic DNS name plus a script that updates the secondary. hiddenprimary.ch does without both: when the address changes, your primary sends a NOTIFY signed with your TSIG key. We check the signature and take the new address from that message.

What you need

  • A TSIG key. With a changing address, the key is the only proof that a message comes from you. We do not accept this setting without one.
  • A public IPv4 or IPv6 address that reaches your primary on port 53. Behind a router, forward TCP and UDP port 53 to it. Transfers come from 159.69.29.118 and 45.131.252.44, or over IPv6 from 2a01:4f8:1c0c:63c4::118 and 2a11:8b80:1000:1::18. If your router can filter by source, allow only those.
  • No carrier-grade NAT for the address you use. Many home connections share one public IPv4 address between customers (CGNAT or DS-Lite). We cannot reach a primary behind it. If you have native IPv6, use the IPv6 address of your primary instead.

1. Create the zone

In the portal, go to Zones → Add Zone. Enter the TSIG key name, algorithm, and secret, and check My primary is on an address that changes. You can leave the primary IP empty: we take it from your first signed NOTIFY. With the API:

terminal
$ curl -X POST https://hiddenprimary.ch/v1/zones \
  -H "Authorization: Bearer $HP_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "example.ch",
    "primary_ips": [],
    "tsig_key_name": "example-transfer",
    "tsig_algorithm": "hmac-sha256",
    "tsig_secret": "<secret>",
    "dynamic_primary": true
  }'

For an existing zone, send "dynamic_primary": true with PUT /v1/zones/{id}. The zone must already have a TSIG key.

2. Sign transfers and NOTIFY with the key

Your primary must accept transfers by key, not by address, and it must sign its NOTIFY messages. In BIND, also-notify takes the key name after each address:

named.conf
zone "example.ch" {
  type primary;
  file "/etc/bind/zones/example.ch";
  allow-transfer { key "example-transfer"; };
  notify explicit;
  also-notify {
    159.69.29.118 key "example-transfer";
    45.131.252.44 key "example-transfer";
  };
};

Both addresses are ours: the transfer node and the standby that takes over when the transfer node is unavailable. Other servers work the same way: send the NOTIFY with the key. See the TSIG guide for Knot DNS and NSD.

3. Send a NOTIFY when the address changes

Your primary sends a NOTIFY on every zone change, and we follow the address it comes from. A new IP address alone does not change the zone, so it triggers no NOTIFY. Send one on a schedule. A NOTIFY from an address we already know changes nothing, so a short interval does no harm:

/etc/cron.d/notify-secondary
*/5 * * * * root /usr/sbin/rndc notify example.ch

If your router can run a script when the address changes, call the same command there instead. The secondary then follows the new address within seconds.

Why this is not the default

For a primary with a fixed address and a TSIG key, we accept a NOTIFY only if it comes from that address and carries the key, and we never change the address on our own. Then a stolen key alone cannot point your zone at another server. With a changing address, the key is the only check left. That is why you have to turn this on per zone, and why it requires a key. Keep the secret safe, and change it if it may have leaked.

Check that it works

  • The zone page in the portal shows the primary address we use now.
  • After you change a record, ask one of our nameservers for it: dig +short TXT example.ch @ns1.hiddenprimary.ch.
  • If nothing arrives, see zone transfer errors. On a home connection, the usual cause is a missing port forward for TCP port 53.

Next Steps