How to host a root domain from a NAT line (GoDaddy)

This walkthrough hosts a root domain like jens.dev directly from Everlock running at home behind a Fritzbox-style NAT line, with the domain registered at GoDaddy. The home line has a regular dynamic public IP — every reconnect can hand you a new one.

This is the simplest topology in terms of moving parts (one Everlock instance, no VPS) and the hardest in terms of operations: when the home IP changes, the glue records at GoDaddy need to follow. Everlock detects the new IP automatically; updating GoDaddy is currently a manual step. The companion walkthroughs cover the easier setups:

Public static IP — one Everlock on a fixed IP.
Primary at home + secondary on a VPS — the residential-friendly setup that hides your home IP from the world.

If you want to avoid touching GoDaddy by hand on every IP change, jump to the replication guide instead.

What you need

A registered domain at GoDaddy (jens.dev in this walkthrough).
A box at home that can run Everlock and answer on UDP/TCP 53. Any Linux/BSD/macOS host works; a Raspberry Pi 4 or better is enough.
A Fritzbox (or equivalent) with the ability to port-forward UDP/TCP 53 inbound to the Everlock host.
The home line's current public IPv4. If you also have a routable IPv6 (most German DSL lines do), Everlock will pick it up from the interface automatically — no port-forward needed for v6.

1. Port-forward DNS to the Everlock host on the Fritzbox

In the Fritzbox admin UI:

Internet → Permit Access → Port Sharing.
Add a new sharing rule for the Everlock host:
- Protocol: UDP, external port 53 → internal 53.
- Repeat for TCP, external port 53 → internal 53.
Save. Reconnect the line once so the rules take effect.

For IPv6, allow inbound DNS to the Everlock host in the Fritzbox firewall config (Internet → Filters → IPv6 if your firmware shows it). Most DSL contracts give each device its own GUA; the Fritzbox just needs to stop blocking inbound 53.

2. Start Everlock with DNS enabled

A minimal production-shaped invocation, binding DNS on all interfaces so the port-forwarded traffic lands:

everlock serve \
  --frontend-ssh \
  --backend-admin-ssh \
  --frontend-dns \
  --frontend-dns-listen-udp 0.0.0.0:53,[::]:53 \
  --frontend-dns-listen-tcp 0.0.0.0:53,[::]:53 \
  --backend-dns-dns \
  --admin-user admin \
  --admin-password change-me

This gives you:

admin SSH on port 2222
authoritative DNS on UDP and TCP port 53

Binding port 53 needs root or CAP_NET_BIND_SERVICE. On a Pi: sudo setcap CAP_NET_BIND_SERVICE=+eip ./everlock.

3. Switch the DNS backend into `discover` mode

The home line's public IP isn't visible from the LAN interface (behind NAT). Tell Everlock to learn it by probing public DNS services.

Edit data/everlock-system/config/dns.toml to read:

enabled = true
listen_udp = "0.0.0.0:53,[::]:53"
listen_tcp = "0.0.0.0:53,[::]:53"
address_mode = "discover"

Connect to the admin shell and reload:

ssh -p 2222 admin@<home-ip>

/dns reload
/dns info

/dns info should now show address mode = discover and, after a few seconds, your current public IPv4 next to public ipv4.

If public ipv4 shows (none) after a minute, your line might be on CGNAT — Everlock detects this and refuses to publish the address. A NAT line with a CGNAT IP cannot host authoritative DNS from home; the replication guide or a paid static IP are your options.

4. Create the zone

/users grant admin ssh/dns/* owner
/dns zones create jens.dev

That creates data/everlock-dns/jens.dev.toml and reloads the DNS view. The backend will now synthesise:

SOA jens.dev
NS jens.dev → ns1.jens.dev, NS jens.dev → ns2.jens.dev
A ns1.jens.dev → <your public IPv4>
A ns2.jens.dev → <your public IPv4> (same IP — see below)
AAAA ns1.jens.dev → <your GUA> (if you have IPv6)
AAAA ns2.jens.dev → <your GUA>

Both ns1 and ns2 point at the same IP because you only have one Everlock instance. Most TLD registries (including .dev via Google Domains/Squarespace and others) require two distinct NS hostnames in the delegation but don't actually require them to live on different addresses.

Inspect the zone:

/dns records list jens.dev

5. Verify Everlock answers locally

From any machine that can reach your home IP (e.g. a phone on mobile data, or a friend's house):

dig @<home-ip> jens.dev SOA
dig @<home-ip> jens.dev NS
dig @<home-ip> ns1.jens.dev A

You should see authoritative answers (AA flag set in the dig output) with the records Everlock synthesised.

6. Register the delegation at GoDaddy

a) Set the nameservers

Under Nameservers, switch from GoDaddy's defaults to "Custom" and enter:

ns1.jens.dev
ns2.jens.dev

GoDaddy will warn that nameserver hostnames inside the same domain need glue. That's the next step.

b) Register glue records

Still in the GoDaddy DNS panel, find the section called Hosts (GoDaddy's name for glue records — the registry-level A records for your in-bailiwick nameservers).

Add:

Host	IP
`ns1`	`<your home IPv4>`
`ns2`	`<your home IPv4>`

If you have IPv6, GoDaddy also lets you add AAAA glue under the same Hosts section.

Save. GoDaddy propagates glue to the .dev registry within a few minutes to a few hours.

7. Verify the public path

Once the registry has the glue, public resolvers should be able to find your zone end-to-end:

dig @8.8.8.8 jens.dev SOA
dig @1.1.1.1 jens.dev NS

The first time this works, you've published a public authoritative zone from your living room. Add records as you like:

/users grant admin ssh/dns/jens.dev writer
/dns records create jens.dev name=@ type=A value=<your home IPv4> ttl=300
/dns records create jens.dev name=www type=CNAME value=jens.dev ttl=300

8. Handling IP changes

This is the operational catch with this topology. When the home line reconnects with a new public IP:

Everlock's hourly discovery probe (or you, running /dns ip refresh) picks up the new IP within minutes.
The synthesised A records for ns1.jens.dev / ns2.jens.dev inside Everlock's view update automatically, and SOA bumps.
The glue records at GoDaddy still point at the old IP. That glue is the only thing the rest of the internet uses to find your nameservers — until you update it, your zone is effectively offline.

You have to go back to step 6b in the GoDaddy UI and replace the IPs on the ns1 / ns2 hosts. GoDaddy doesn't expose an API path for this that Everlock can drive on your behalf today.

Mitigations:

Watch your home IP. /dns info shows the current value; compare to the glue at GoDaddy when you suspect a reconnect.
Pick a long DSL contract that rarely reconnects. Many German ISPs let you opt out of the daily forced reconnect.
Switch topology. If you'll be doing this for any length of time, the replication setup removes the manual step entirely: your home IP becomes private, and the glue points at a small static-IP node that never changes.